I am making an Android App for marking Attendance of students. I have an SQLite database in the app and a MySql remote database. The app sends and receives data between the two databases and i am thinking of using JSON for parsing data. Is there any other method for parsing data between the databases other than JSON that is more efficient and good. Thanks! Cheers!
There are a plethera of other data choices other than JSON.
JSON has the advantage of being easy to read, which makes debugging the wire protocol easier. It can be kind of verbose though, and there are more compact encodings which will save bandwidth.
I personally really like Avro. However, other good choices are Thrift and Protocol Buffers. All three offer a way to convert POJOs into a compact binary form. Thrift is basically a redo of protocol buffers by guys that were hired away from Google by Facebook. Avro takes a slightly different approach in that it has Schema resolution, which can make some schema evolution tasks easier to accomplish.
Related
In my android application, user need to load about >100 rows populated in a Listview. To update new data everyday without updating app, I store my data in a XML file, put it in server and when user open app, my app load new XML file from server and parse them into my Listview.
Does my practice is a good method? How about it performance compare to JSON? And when I need to use MySQL server?
Your approach is fine but JSON would be a bit better because it is more compact. Refer this answer: JSON and XML comparison
To cache your data use SQLite database, it will be much faster to read data from database on your device than making a network request.
This is a static approach. You must edit the XML yourself every time you want to change the result.
A dynamic approach would make you create a database to store the data (MySQL or any other) and you would write a script that communicates with the database and query for data and then you need there to choose between the formats XML or Json. I think Json is faster and more readable than XML and JSON is also more compact.
You can use Protocol Buffers
According to the site:
Protocol buffers are Google's language-neutral, platform-neutral,
extensible mechanism for serializing structured data – think XML, but
smaller, faster, and simpler. You define how you want your data to be
structured once, then you can use special generated source code to
easily write and read your structured data to and from a variety of
data streams and using a variety of languages.
Benefits of Protocol Buffers:
Protocol buffers have many advantages over XML for serializing
structured data. Protocol buffers:
are simpler
are 3 to 10 times smaller
are 20 to 100 times faster
are less ambiguous
generate data access classes that are easier to use programmatically
We developing an app that will store data locally on phone, on server and share it between users. The access to store and retrieve data will be approximately 20 times a day for each user, it will consist mostly of strings. The app will be cross platform Android/iOS. So before beginning developing DB what you suggest Json vs SQlite or use HTTP Methods: GET, POST.
What are advantages and disadvantages of each, and what do you suggest.
I do not agree that sql is slow. It's not like these devices are using spinning disks. In my app, i've implemented a RESTful API that passes JSON data back. This is easy because on iOS, json can be easily converted to the iOS Native NSDictionary object.
I recommend storing data using sqlite or Core Data because you'll be happy for it later on if you need to query the data. That's what databases are used for, storing and retrieving data easily.
As an alternative, you can also consider building the SQLite database on the server, and actually downloading that file to the devices. This has it's benefits because you won't need to do the actual sqlite processing on device.
I recommend staying away from XML, not because it's bad, but because passing JSON data back has become standard, and a lot of large companies are moving away from XML formats because of the processing power required.
In designing your RESTful API, it's always good practice to use the already available HTTP request methods. Use GET to retrieve data, POST to create new data, PUT to update data and DELETE to remove data. Once you have a beautifully designed REST api, all things things should just fall into place and you'll have an app that's maintainable and scalable on the client and on the server side.
This question really depends on your own area of expertise. If you have good understanding of JSON, then use that. XML is another great way via SOAP (or REST) to distribute data to your platforms, Server -> Device -> Server. My own experience is that JSON with GZIP is small and fast and there exists lots of parsers that is fast. XML has the downside that it gets big quickly but is often easier to maintain over time since the syntax is set in the "namespace" of your XML. SQLite is slow, since its disk based and should only be used for persistent storage of data. Access it as little as possible during runtime. My suggestion: JSON+GZIP, REST-api on server/device, store as much as possible in memory on devices, SQLite for persistent storage on devices and lastly MySQL on server for persistent storage (free, fast enough if done correctly with views and methods).
But as said, this is all up to the implementation.
I have a few years of exp with webdev using .Net and C#... and one feature I really enjoy there is the linq-expressions for quering for data.. is there anything that simulair for Android using to query against JSONs or against the SqlLite database? (I guess im looking for a typed expression/query-framework).
And for my next question.. Which one of the JSON approach and the SQLLite approach am I supposed to use.. and when? I know this has been asked a million times.. but there doesnt seem to be any strict answers..
Is SQLLite for more complex querying and when Im having a bigger ammount of data, while JSON is used while having a smaller ammount of data and not very much querying is needed?
Could I store all my JSON data in the memmory for faster read/write access?..since I have heard that storing it in the storage/on disk might be a slow process.
But on the other hand I also have heard that SQLLite is slow in generall...
And finally.. when we are speaking of "slow" is it slow like, a single read/write looks up the entire application for a few milisecs or is it slow like compared to a in-memory-database that executes queries and stuff fast as lightning
When to use SQLite
SQLite is one form of how to persist your data, how to secure your data. Generally if you want to store larger quantum of data and have quick access to them(and also if these data are "sensitive"), SQLite is great choice. Hence i disagree with your opition that SQLite is slow, definitely not i guess.
I have SQLite database with approximately with 650 000 records and still smart performance(an usage of indexes is sometimes necessary).
When to use JSON
JSON is lightweight data structure designed for human-readable data interchange and what is main is language-independent. It's very good choice(maybe the best) if you want send data via network(send data to remote server etc.) but i think not very good for data persisting also it's not safe as SQLite is.
Generally you should compare JSON with XML but you can't compare SQLite and JSON which are two different things.
General Idea
SqlLite : For Local Storage
JSON : For Server SideStore
It doesn't make sense to compare SQLite and JSON. One is a storage solution, the other one is a data format.
You should probably read the official guide before deciding which storage solution to choose (SQLite, preferences, file system,...): http://developer.android.com/guide/topics/data/data-storage.html
If you want to go for SQLite persistence you can use some third-party ORM to make queries easier (e.g ORMLite is the most popular one)
I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.
I'm writing an Android app that I want to use in conjunction with a band website I've developed. The website uses a SQL database to hold information such as blogs, band member information, tour dates, etc.
What data access method would make the most sense to use? I've looked at Andriod dev on tekpub and JSON data access is incredibly easy, however would it make sense to parse the database into JSON just for Android access?
Is there a good way to hit the SQL database as is? Any advice, tutorial links, or examples would be great.
It's a standard to use JSON or XML to transfer data from a server to an android client.
Giving direct access to the SQL from the devices would be a bad idea as it would
expose a large security hole
make your data base schema more difficult to change (too many clients would rely directly on its structure)
just not work in most cases as database driver are not meant to be used this way, they often use a stable channel to communicate with the database server.