I am working on a e-shop type application with more than 500 cathegories. Cathegory is basically a name-value pair and its not going to change. How should I store this data? Currently I am using string arrays in strings.xml resources file (one for names, one for values). The application now starts like 5 seconds or more, which is very slow. Is this because of too much resources? Do they all get loaded at startup?
Should I use database for this? Basically I need this data only later in the app, when creating a "query" , you select from all the cathegories, certainly not at start up..
If so, where should I put all those strings to have it bulk inserted at first app run? A class? wouldnt this still be slowing down every startup, as the class has to get loaded? Is it possible to load resource string array only in the activity where I will construct the query? (given they all get somehow loaded at startup, which it seems)..
Thanks!
You should use SQLite, and query strings whenever you want, hence it doesn't affect to the performance.
read more at:
http://www.vogella.com/articles/AndroidSQLite/article.html
and
http://developer.android.com/training/basics/data-storage/databases.html
Related
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
My Android app is a client that fetchs datas from a Web Service and show them to the user. I would like to know how to improve performance and avoid continuos connections.
Everytime I click the botton "show" for example I make the connection and get the json string. I know that my string will not change during the day (hopefully).
It's better to get the json string and save it in a text file, save the string on a DB (with "date" and "string" columns for example) and then deserialize it, or directly deserialize the string and save as proper objects in the DB?
Thanks a lot!
If it's a little string, say under 1K, put it in Shared Preferences. Otherwise, if your data is going to remain relevant for a few days, use a database. If your data is going to be pretty much thrown out and refreshed completely each day, and is a few KB, write it in a cache file.
I have one Application which has more then 5 Activity I want to know how much space is needed to store 10 different values to SharedPreference. or I have to user Sqlitequery ?
Simple in One Activity I have 4 Field like FirstName,LastName, Age, City when user Click on th button then new Activity is called and in this activity Full Information is Display, so I can do that in two way. First Way I Store all the Information in the SharedPreference and in Second Activity I get this Stored Values and another way is i only store record id and store it in intent.putextra and get it to another activity and Fire Sqlite Query. so I want to know which one is best for Application .(As per Memory Uses and Speed )
If you do not need persistent storage then you can simply pass the data using intents from one activity to another or maybe even keep some static variables in a separate class say Const.java
If you need persistent storage and if your data is limited, I would always recommend using SP over SQLite which should be used for relational data. DB operations take more time and can hit performance besides there is always chance of DB getting corrupted.
Sqllite is a really good solution if you want to be able to add easily more preferences.
It's a bit heavy to set-up but really powerfull.
http://developer.android.com/guide/topics/data/data-storage.html
For me, database is for storing data, and sharedpreference just app config.
Shared preferenses apereas to be the choise here, it is very good to store simple settings and very fast and flexible.
A database would IMO be overkill here :)
Its an application that is calling the ZXing barcode reader on button push, after scanning in shows you the code and you can put in an amount (how much you want to order from that product), then you go next scan, so on so on...I need to store this data. In my main window under the scan button, i will have a show scanned list, with all the scanned items plus the amount of each. And i will have a send button which sends a this list in a .txt or a .csv file via bluetooth to PC. And after closing the application with exit button, or with the back key, this list needs to be destroyed , so when i start the application again, there is a fresh, new list. First i thought, on using SQLite, but my costumer wants a simple program, without db. I could just need a few ideas on storing, data else how. Like an array list, but i dont know how hard is it to handle such a storing bethod, with editing or deleting and such. Or directly saving it into a .CSV file? Any idea is welcome.
Thanks you.
create a Bean class say Product which contains the attributes which you want to display on your list view.
Take a ArrayList
store the bean objects in arraylist and finally iterate it to do your calculations.
To get the CSV, you can call the to string on the instance of arraylist.
IMO using SQLite would be your best option, it does not add that much complexity to your app. Though if you really do not want to use it, Shared Preferences is an even simpler API for storing data.