I am trying to write an application that retrieves data that the user has stored. Whats the best way to store this data. The data has a large number of rows but each field has very little data. Initially I was thinking of using Sqlite , but the read calls I believe are very slow and need to be implement in a background thread according to Vogella's thread.
I need extremely quick retrieval rate.
Are there any other option for me?
SQLite is not slow. It's practically immediate for my quiz app with thousands of entries.
Read this for the options and details on them.
Related
I am developing a social networking android app. I am currently using parse as my back end. I am using Parse.com to store the text messages and fetch those messages.
The first problem with parse is that it runs very-2 slow.
The second problem is that I have to set limit to 1000 users. How can I access large number of users or data?
How can i fetch the results faster with large number of users?
Should i consider using any other backend like google app engine, etc.
I want to fetch and store results quickly, just like facebook and WhatsApp? I would really appreciate your ideas/feedback/suggestion. Thanks
The problem is not that parse is slow, but more likely that your data model is not optimized for use on a NoSQL database service like parse. You probably have SQL experience and created your data model like you would for a SQL database.
With NoSQL (and especially mobile apps), you need to model for queries; not normalisation and consistency.
When designing your backend, first create a list of the most commonly used queries your app will have. Then design your model around how to minimize the number of queries necessary for retrieving the dataset you need.
Why do you need to get 1000 or more users in one query?
I recommend you take a look at the data model behind the Anypic app on parse.com. The model is very simple, yet extremely versatile.
If you are a SQL-person (like I was), you need to "unlearn" your relation thinking and start thinking about query speed :-)
For a better answer you should probably paste some of your code to know how is the query you are making and how is your data model. That is the only way you can optimize your query because you cannot make Parse itself faster and you cannot remove its limits.
By the way, I work in Backbeam. It is a fast backend as a service and it has support for complex queries such as making joins. Maybe you want to give it a try.
In Twitter Android App, Once the listview is populated with tweets/items downloaded from server, it never again talks to server to fetch them again. Even if you kill the app and start it again, it still retrieves the same old data.How does twitter store this much of data. Is it using database, storing all downloaded data in a file or caching.
In my app , i have a similar requirement.For now i store the downloaded listview data in a file and then read it whenever the app is started afresh.Is there a better approach or a followed patter for this.
Thank You.
There are three ways to save/persist data on clientside. These being:
SharedPreferences (not ideal with requirements)
File I/O
SQLLite database
As far as I know there isn't a big difference is performance between file-I/O and SQLLite. But SQLLite has a lot of other advantages.
You can query the database, this is more easy then writing it yourself with file-I/O
Manipulation of data is for more easy and less painful (delete/update records etc)
Supports relations between data!
Bottom line, go for SQLLite, it seems more work to setup but you will benefit from this in the future.
I'm working on an Android app for homework management. I'm a senior in college, so my experience on larger projects is very limited, but I'd like to design all parts of this app well instead of just throwing something together. This includes the way data is stored.
We have two main objects/entities: Task and Subject. Even if someone uses the app for the whole time they're in college and never deletes anything, I'm guessing there would be a maximum of a few thousand tasks and a couple hundred subjects (not all subjects would be shown at once). The initial version of the app won't sync data with a server, but this is a definite possibility in the future, so I'd like to design with that in mind. We might also have an option for users to send tasks to each other.
Here are my questions:
Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
Thanks for your help!
This question is broad so may comments below may not be 100% correct as I don't have all the information about your system.
SQLite is better suited for storing thousands of records than files (be it JSON or XML). This is especially true if your data is not static, i.e. will be changed during the usage of your app (which is the case for you, I believe). You can take advantage of existing functionality for records inserts, updates, deletions, using indexes, etc.
Yes, you generally create objects similar to your database. But you don't usually need to convert each and every record from the database into your objects. You usually query the database for a limited number of objects, depending on what you want to show in the UI. Of course, if you need to show all, let's say, tasks, you need to get them all.
1. Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
Yes SQlite will be the option for you.It will give you a structured format and in future if you want to access data from remote end the same structure of tables can be used without much change in the code.
2. I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
you can simply execute queries to manipulate data.
But dont forget to encryt your database if you storing it in mobile itself.
In terms of storing data in Android, would it be more efficient to use a large ArrayList or setup an SQLite database? I have ~9000 bus stops and stop names (both in String) that I need to store and I was wondering which method would be the quickest or most efficient.
An ArrayList is probably a very bad idea. I assume you want the data to be persistent, so if your user kills your app your data will be lost if you use an ArrayList. A database is persistent(unless the user clears the cache of the app). So I would highly recommend using a database over an ArrayList.
If your data does not change then you could probably have it read on startup and kept in memory while the App runs. For example, having a .json file with all the stops, read it on startup, put the data in a HashMap or something that is easy to use since you will probably lookup stuff. It would probably work fine with ~9000 entries.
If you are going to add or update information about the stops during usage then the SQLite is the better choice though.
1.) Store and retrieve your data from a SQLite DB since you want persistance. And since you say you have 9k+ rows a simple select will give you everything at once and you can easily filter the data as well if you need to
2.) At startup, put all your data into efficient memory structures like HashMaps(or in your case arraylists) and reference them throughout the app. This way you'll only do one time access.
3.) When in doubt build a DB. No harm, more efficient and easier to handle than files
I have about twenty pages of information that is stored in tables that needs to be stored in my Android application. Each column is a designated stop on a bus route and the column is filled with times that the bus will be at the stop. There is also certain information that needs to be associated with some times, such as if the bus is handicap accessible at a certain time.
Here is an example of one of the tables: Bus Times
I have thought about using a SQL lite as that seems as though it would be able to store these tables quite easily; but when I think of using SQL I think of dynamic data storage and this shouldn't be changing more than once a year.
Is SQL appropriate for this application? Is there a better way to do this?
Thanks,
Rob
I think a database is really the appropriate form for doing this. Data in a database don't have to chance regularly or very often, almost more important is the fact that you can relatively easy extract very specific information from a large data set. So if you need to store the data lcoally I would use a database.
Just a hint for another approach. Did you think about reading this data directly from the website? Judging from the style of this page I don't think they offer a webservice, but maybe you could parse it using HTTP Get? Don't know if the structure changes over time, but this solution would have the advantage that you don't need locale storage and if the data is update you don't have to manually update your database.
Hope could help you