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.
Related
I know there are some topics and posts about this question, but i want to have an individual feedback.
So in my app i use one shared preferences (file) and gson to store a list of objects, containing big amount of data. So my shared preference file is about 5 MB big and contains ca 1 Mio characters. I know this sounds not really good, but my app works perfectly. No long loading or saving times.
I choose this method, because i ONLY want to store the data, when my app will be closed and between app starts.
I know really good, that shared prefs is not a good way and actually meant for saving small strings for preferences.
So do i have to change this method or is it "okay"? Or does someone know a good solution, which is easy to use and understand, because for me sqlite is difficult and hard to use. Or is there a easy way to store an object into sql? (Maybe a library or a method??)
Thank you in advanced!
Rule of thumb: As long as it works does not necessarily mean it's good. Said that, SQLite is a perfectly valid solution for android applications. There is also a handy developer guide on how to save data with SQLite, but the recommended approach is actually to use the Room Persistence Library.
No, it is not meant for big data objects. For that for example you can use SQLite internal database
for temporary bases it is good for store a data in shared preference. If you want to store a big data then you have to use SqLite to store your data in your device.
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.
In my android application I have to store some application settings and some user information within the phone.
I can go for the shared preference option explained in this DOCUMENTATION.
But wondering if I can store data as objects wise within the phone. I found this Stackoverflow Question regarding saving serialized objects in files and bit not sure of any issues if I go with this way to store persistent data.
Also would like to know what the best way to deal with insert/delete/update and read with XML files in android. Would appreciate any guidance. Thanks in advance...!!!
If it is only a small amount of data you need to store, then go with the built-in shared preferences, that is what the functionality is there for. SQLite and OrmLite are a bit heavyweight in this situation IMO. Even if you want to handle the data as Objects; in which case I would serialise to / deserialise from JSON or XML stored in text files and handle the insert/update/delete on the deserialised objects in your model.
If you want to persist some objects I think you should use SQLiteDatabase, it would be a more cleaner solution than using serialization in files. You will indeed need to write some extra code for your Database but you will end up with a cleaner implementation in my opinion. You could also be using OrmLite for Android which is pretty robust and easy to use if you have some basic orm knowledge.
I am making an application which is saving the values in arrays and I have 7 arrays like this. Now I want to save these values for future use although the application is restarted. I am confused between database and sharedprefrences. Pls tell me what I can use for this approach and why??
And if I use sharedpreferences then is there any way to store multiple rows of data or I can use SQLite only?? Please do tell.. Thanx in advance...
These two are 2 of the methods for saving persistent data. There are both pros and cons.
My opinion is that if you want to save a large amount of data I will go with the database. The preferences are more like saving states or valuable information that require a key-value pair. A simple example is saving the value of an EditText or how many times the user has logged in the application.
Although in your case the database might seem more appropriate, the implementation is a little time consuming and I don't know if it's worth it for your case. If there is a possibility of expanding the dataset that you wish to save then go with the database. It's up to you.
I hope this answer gave you a briefly overview.
One way is discussed here:
StackOverflow - How to Implement Persistent Storage in Android
Here's something that shows three different kinds of storage: Data Storage in Android
My app needs to store data on the phone, but I'm not sure what's the more efficient method. I don't need to search through the data or anything like that. I just need to be able to save the app's current state when it closes and restore when it's back up. There is between 1mb and 10mb worth of data that will need saving.
There are basically a bunch of custom classes with data in them, and right now I have them as Serializable, and just save each class to a file. Is there any reason for me to change that to store it in SQLite?
If you where to use sqlite you could save as you go, and know that whats in the DB is pretty much uptodate if the app/activity holding the data is suddenly killed by the os. Other that that I cant see and obvious reason to use sqlite for your use-case.
Also for the sql approach you have a clear cut way to change the structure of your domain objects at a later time and to migrate the data from a old to a new version of your database. This can be done using serialized objects as-well, but then the objects needs to be duplicated, both new and old at the same time. And that to me sounds very very scary and messy, especially considering that you might need to go from version x to y, so you might end up with some pretty tricky problems if you ever need to update the domain objects.
And I can honestly not see any benefits of using the flat-file/serialized approach.
You mention in your question that the data is only meant to save the state of the app, therefore my initial response would be to keep it on the devices especially since you mention that the file size would not be much more than 10MB, which is quite reasonable.
So my answer to you would be to keep it as is on the device. If your usage of the information changes in the future, you should then reconsider this approach, but for now it's totally logical.
If you're only saving serialized classes, you could use an ORM mapper as discussed in this thread . This saves you the inconvenience of writing your own mapper and is easily extendable to new classes. Also, if your requirements change, you COULD lookup data.
The only reasons for changing your system to SQLite would be more comfort and maybe a more foolproof system. E.g. now you have to check if the file exists, parse the contents etc. and if you'd use SQLite, you don't have to verify the integrity of the data and Android also helps you a little. And you could use the data for other causes, like displaying them in a ListView.