i have a question which i know its answers vary from one app to another.
consider an app like Telegram which you have a noticeably amount of data there like your contacts and chats. when you close the app and later you relaunch that, even if you don't have any connection to internet, app loads your contacts and chats and this is done in fraction of second. i want to know how these works are done and implemented?
for example they store all the data in disk in a file(storing that amount of data on disk can take long time moreover they cache images too), or we save each part of app in different files and we load them whenever user opens them.
You have two commonly used ways to store data in Android. SharedPreferences and local databases.
Before I continue, you should check out other articles regarding storing data on android. There are loads of them explaining it better and in-depth than what I can, I will just give some examples what you can use.
Start here or just google it!
SharedPreferences
SharedPreferences works in a Key -> Value, used for saving basic types of data. Good for storing user tokens, settings and similar things.
See more
Databases
Android uses SQLite for local data storage, and there are many libraries that can help you with this.
More notably Room, but there are other ones as well that are very popular to use. Databases are good for storing large amounts of data, like conversations and contacts in the example you are talking about.
Caching
You also have access to caching data, but keep in mind that it's meant as a temporary storage, and if you want to store something like user information or other complex data, you should stick to a database. Caching is useful for images.
This is called api data caching. It is important that we should know which data to be cached and which data should not be cached.
There is a library from NYtimes you can use it for api level caching with retrofit.
Related
I have started learning Android development and I have a very newbie question. I understand that Android can store data in SQLite for example, but what other approaches are there to the storage of data within your application?
Do Android apps ever have data 'embedded' within the application, in which case what sort of data structure or concept would this use?
I am thinking of a scenario where the data is static but is perhaps not a large enough dataset to warrant a database..e.g. an app with general knowledge questions and answers
Any guidance much appreciated
Rowan
Yes You are correct You can use SqLite Database for storage
other ways to store data is SharedPreferences
But in your case you wanrted to save questions and answers which is static one so you can create a text file and put that in your assets folder and you can read that file as any other text file in java
Refer this link how to read file from assets folder
1.Sqlite Database
2.Shared preferences
3.Internal memory
4.external memory i.e sd card
i would suggest you to go with Database. as it will let you store as much data as your app needed, There are some other option also present like
Sharedpreference i.e. cookies in general term. It let u store only few KB data and not good to store much data. When u retrieve data from cookies. All data will be store into ram and use app memory. that is use less when u do not need all data to retrieve and store into ram and then remove
Store into file and ship that file with your app. Yeah. this could be better idea again. you need to read it byte by byte. and hence reading to mid or last line will store all data into ram and hence will take memory.
Use Web Service to download data. It will let you store Large data and you have to download using Web APi. Hence it could be better idea. But this requires active Internet connection to play game to run app.
There must be some other option also present. You can search. surely you will find them :)
Overall Database it good solution for all app. As it will let you do search store delete and let you do other operation in less amount of memory. In Mobile Development Memory is very Important thing we have to take care of.
Let me know if you have other unclear thought.
item
You could also store info in a server.
Pros :
You can change the content without needing user-side update of the app.
Cons :
Your app (mostly the UI) would need to manage connection problems.
You may need to implement async tasks for querying data from server.
I want to write an android calculator app like the one on my android phone. It saves history for operations and by clicking a button it shows last operations. Now my question is what is the best way to save operations? Is it reasonable to save them to a file in internal storage or what?
There's some options..
1) Include a SQLite Database, as others mentioned. This makes storing lots of information really easy. You can find tutorials on how to include one properly in your project, and don't hvae to care for much more. You can then work with content providers to read and store data.
http://developer.android.com/guide/topics/providers/content-providers.html
2) SharedPreferences. If you just intend to store like the last, or the last 3 Operations, you can just use shared Preferences. This is way less overhead than adding a Database, if it is a small project, albeit you will have to keep your data structured yourself.
http://developer.android.com/reference/android/content/SharedPreferences.html
3) If you just want to store the users current session you can just Keep a Stack of the used operations. On undo, or however you call it, you would just pop the stack.
By implementing onSaveInstanceState and Parcelable you can make sure that no data is lost on rotation / low memory and such.
I personally would advise you without knowing more about your project to use plain java objects and storing the state. A calculater would in most cases not need persistent storage. If you really want to know what the user did 2 weeks ago, you should use a Database.
I would recommend you to use database(SQLite) for storing the data.
If you don't know more about SQLite in android have a look at these
tutorials.
I think database should be handy for history if more than one operations has to be stored else for one operation you can use shared preference.
I'm developing a social photo app that is like instagram and I need to improve the application performance, to do that I need to persist some data, like timeline feed, photos, messages, etc.
I'm already using Shared Preferences to save user informations.
I don't know which is the best way to persist the data, I'm between SQLite or Files, to save the json data or something else.
Which is faster and gives me less trouble?
If somebody could help me I would appreciate it.
take a look at this caching images will provide better solution.
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html
If you need different queries on this data, than i strongly recommend to use SQLite. Cause it's not possible to make select queries on files without storing it to memory.
Even if you use this object as is without any special queries, you can store json objects to base.
SQL:
1) Fast.
2) Possibility to make select queries with different WHERE condition.
3) Easy update.
4) etc
I do not see the advantages to store this data to files...
If you will store data in files, it will slow if there will be a lot of data. Even if you will use sax parser.
But, images you should store as files, and only update link on it in data base.
I am writing a social networking android application. I have create a .Net webservice with a database on Microsoft Azure, and I plan to call that web service to get data from the cloud and display it to the user. Similar to Facebook.
Now, I have two approaches in mind, and I'm not sure which one to implement. The approaches follow:
"Every time an activity loads, call the web service and reload all the data." This, of course, is the easiest approach, but is it right? I mean, I have around 30 activities, and half of them load data, while the other half post. As far as I see, this approach can be a problem, because it might slow down the application. It can also increase my cloud bill with so many requests. And I don't know if it's right to reload everytime.
"Call the webservice every 10 minutes, and store all the data in a SQLite database, and only update the data if it's been over 10 minutes, or possibly even have a refresh button." This approach is probably the better one, but I'm not sure if it is even worth writing so much code.
I need you advice in deciding on the right technique. Number 2 looks good, but what if there is something I don't know, and I'm writing all that extra code for no reason.
Please help me out here. If there is even a better approach, please do tell me.
It really depends on the sort of data, what sort of latency is required for the data and the quantity of data. Also the size of the project and benefit you will get from implementation as complexity will be increased. For a more precise answer provide further information.
Local caching can be a very good idea in this sort of situation. It is fairly common practice and there are multiple mechanisms which could be used. Depending on the format of data retrieved from your web service, you can store in a
Database, when data needs to processed (searched, queried etc) or there is a lot of data.
File(s), sometimes useful if you are working with formatted data such as xml or json as you can maintain the structure. You can use the native android caching to assist in managing the storage.
Preferences, when data is simple types (and strings) and there isn't much of it.
Local caching will reduce bandwidth consumption (will end up saving the user money which is always popular) and if implemented correctly memory and processing consumption. Possibly most important (depending on the data) it could allow for the effective use of the application when the user doesn't have connectivity.
By the way 30 activities sounds like a lot, you should really look at reducing that by sharing functionality across activities, this should improve navigation, code bulk and memory foot print.
UPDATE from comments
From the limited information available about your project I would suggest using the database as your data store (if any) as you don't want to be caching complete SOAP messages in files, and the quantity 40+ records may make preference storage difficult to manage.
However, as I have mentioned previously you need to consider complexity. When using the database you will have to create a method of construction (perhaps some sort of ORM) separate to your de-serialisation of SOAP objects because technically you will 2 separate persisted data formats.
I am not able to get a definitive answer because there is still very limited information but you need to evaluate the cost of adding such a feature to your project and the benefits you will receive.
I few other things worth mentioning when considering this sort of caching.
How you will manage the cache, it's size and data integrity.
When will you cache, as soon as you have de-serialised your SOAP objects? when you have finished with the data? etc..
How will decide when to use the cache and when to hit the network?
I will be making a mobile application in Android. My application is like Google Map's Get Direction feature, but a lot more complex, so I need to store data about points in the map. So I'm worried that SQLite may not be able to handle these large amount of data(or considering the limited storage of the phone). I have no background in SQLite so please bear with me.
SQLite can handle large amount of data, the problem here is the device's limits. If you are going to store 3MB or more you should consider saving that data in an external server and access it via the Internet. In fact, when you are building an application that use large amount of data, usually the application don't use all data all the time, so you can save in cache (in a local database) the data that the app is currently using or is about to use.
I think the best way to find out is to write a simple app that simulates the types of transactions you'll be doing and see how it does.
You might also want to compare how SQLite does to an object database like db4o, which is very performant and used very often as an embedded database (and can easily handle gigs of data).