I am working on an android project where I need to save my json files to implement offline mode.
According to my research I can use LRu cache or Realm database
Still confused which one to use or is there a better way to implement offline mode for mob app ?
caching your data might not be the best option to go for in this case, i think using database will be the best option,
you can use realm database or best yet room database you can follow the benchmark test for Android persistence libraries here Android-ORM-benchmark
and read more from android developer page https://developer.android.com/reference/android/arch/persistence/room/RoomDatabase
I am not sure if you mean by LRU cache, the class in Android or generally the technique of evicting least used items.
Anyway, you are comparing very two different things here.
I will assume that when you mention offline mode, you need your data to survive you app's process being killed for any reason.
So you users would come back to your application in a day or two, and the persisted data would still be there.
For offline persistence you have multiple options
SharedPreferences (might not be best idea for cache)
Files either on internal or external storage, might be faster than implementing a database if your data is not huge
SQLite database
If you have lots of data and need some CRUD operations, DB is probably the way to go, there are lots of ORMs on Android, Realms is certainly one of them, but to name a few more.
OrmLite
GreenDAO
Realm
Room (made by Android team)
There are also many more, just Google "Android ORMs"
Hope that helps!
Related
My app are sometime needed syncing with web servers and pull the data in mobile sqlite database for offline usages, so database size is keep growing exponentially.
I want to know how the professional app like whatsapp,hike,evernote etc manage their offline sqlite database.
Please suggest me the steps to solve this problem.
PS: I am asking about offline database (i.e growing in the size after syncing) management do not confuse with database syncing with web servers.
I do not know how large is your data size is. However, I think it should not be a problem storing reasonably large data into the internal memory of an application. The internal memory is shared among all applications and hence it can grow until the storage getting filled.
In my opinion, the main problem here is the query time if you do not have the proper indexing to your database tables. Otherwise, keeping the databases in your internal storage is completely fine and I think you do not have to be worried about the amount of data which can be stored in the internal storage of an application as the newer Android devices provide better storage capability.
Hence, if your database is really big, which does not fit into the internal memory, you might consider having the data only which is being used frequently and delete otherwise. This highly depends on the use case of your application.
In one of the applications that I developed, I stored some large databases in the external memory and copied them into the internal memory whenever it was necessary. Copying the database from external storage into internal storage took some time (few seconds) though. However, once the database got copied I could run queries efficiently.
Let me know if you need any help or clarification for some points. I hope that helps you.
For max size databases. AFAIK You don't want to loose what's on the device and force a reload.
Ensure you don't drop the database with each new release of your app when a simple alter table add column will work.
What you do archive and remove from the device give the user a way to load it in the background.
There might be some Apps / databases where you can find a documentation, but probably this case is limited and an exception.
So to know exactly what's going on you need to create some snapshots of the databases. You can start with that of one app only, or do it directly with several, but without analyzing you won't get a reliable statement.
The reasons might be even different for each app as databases and app-features differ naturally too.
Faster growth in size than amount of incoming content might be related to cache-tables or indexing for searches, but perhaps there exist other reasons too. Without verification and some important basic-info about it, it's impossible to tell you a detailed reason.
It's possible that table-names of a database give already some hints, but if tablenames or even fields just use meaningless strings, then you've to analyze the data inside including the changes between snapshots.
The following link will help in understanding what exactly Whatsapp is using,
https://www.quora.com/How-is-the-Whatsapp-database-structured
Not really sure if you have to keep all the data all the time stored on the device, but if you have a choice you can always use cloud services (like FCM, AWS) to store or backup most of the data. If you need to keep all the data on the device, then perhaps one way is to use Caching mechanisms in your app.
For Example - Using LRU (Least Recently Used) to cache/store the data that you need on the device, while storing the rest on the cloud, and deleting whats unneeded from the device. If needed you can always retrieve the data on demand (i.e. if the user tries to pull to refresh or on a different action) and delete it whenever its not being used.
I am developing an android project where I want to store images and details about that image.As it will take large storage for images on large scale, I am looking to store them on cloud and link that image with details in the database.So I am confused on which database I should use(like SQLite or MySQL or any other?).
As they say----
SQLite -- is faster but I think it's not convenient to use it for this project(as it will be a large one).
And I am not sure about MySQL (can I use it effectively?).
Or is there any other effective way to approach it.
Any help will be appreciated.
As stated in the comments, you don't have mysql on android, you only have sqlite.
You can use an ORM: http://greenrobot.org/android/android-orm-performance-2016/ and see what best suits you.
Are you worried about write speed? probably go with GreenDao / Realm.
Are you worried about read speed? go with Realm.
Are you worried about size? don't go with Realm.
Do you want a noSQL DB? Go with Realm
Do you have a lot of joins? Go with an ORM
Here https://github.com/olivierg13/GreenDao-vs-Realm you can see that Realm was faster in all tests, but from my experience the write speed difference wasn't that big.
I'm asking for a piece of advice. Currently, we are developing android client for out service. Service produces like a lot of dynamic information, and it must be stored on users phone so it can be accessed without connection to the net. On iOS client we achieved this using restKit. On android I found that there is no tool like restKit. So there are 2 options - use sqlite db or cache last json response. I want to use sqlite db, but our android developer sad that it's not stable and slow. Is he right? What practice is better?
The second question is that I found a sqlite editor app, which allows to edit sqlite databases on phone. Is there any way to avoid this?
You can use SQLite because SQLite is capable of being extremely fast. If you are seeing speeds slower than other DB systems such as MySQL or PostGres, then you are not utilizing SQLite to its full potential. Optimizing for speed appears to be the second priority of D. Richard Hipp, the author and maintainer of SQLite. The first is data integrity and verifiability.
The first thing you should know is that most of the time spent by SQLite (and most other DB systems) is on disk access, which is slow compared to memory operations. So the key to optimizing SQLite is to minimize the amount of disk access required. This requires some understanding of when SQLite is accessing information on disk, and why. Because operating systems generally cache open disk files in memory, a carefully tuned use of SQLite can approach the speed of a pure in-memory database.
If you are new to optimization, you must know that the only reliable way to optimize for speed is to measure where time is being spent. Unless you are already familiar with doing this for SQLite, you will often guess wrong. Use quantitative tests on representative examples whenever possible. Unfortunately, reproducibly measuring performance on an application that does disk access isn't trivial.
However it is difficult to use cache no doubt cache is fast but its not for large data and data cannot stored on cache for long time. So if you want that user will use your app offline then you should place your data on SQLite in an optimized way.
Hope this will help you.
No according to experience SQLite is the most reliable database to use in android device itself. It doesn't have separate server process and it directly read/right to single disk file.
This link will provide more information
I'll begin with explaining how I stumbled upon SQLite Asset Helper library. I am trying to build a small android application which is basically shows the meaning of words. And to do so I intend to keep everything offline (no dependence of internet connectivity). Now, as far as I can think of, there are 2 ways of achieving that:
1. Using String array, which I believe will be a tedious task and a memory hog.
2. By providing a pre-populated database, using which I can easily establish relations between words and their meanings and do more (searching, sorting, etc).
Now, the problem I am facing is supplying a pre-populated database (or words and meanings) with the app itself. And for doing that I came across SQLite Asset Helper which does the job.
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android. Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)? Is it acceptable method? Any other better alternative up for suggestion would be great!
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android
It works on the latest iterations of Android.
Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)?
You are welcome to roll your own implementation. I do not know what you would gain by this.
Is it acceptable method?
I am not aware of anything better.
I have a hybrid application which runs on Android and ios platform, I have been using "localStorage" as data storage.
I also heard sqlite as well, Is there any other local database that I can use for mobile storage?
I would like to know prop and cons in these technologies.
I would really appreciate if anyone can clarify about these technologies.
You can manage data or storage in Android by following ways,
Shared Preferences
Internal Storage
External Storage
SQLite Databases
Network Connection
You can manage the storage or data in iOS by following ways,
Property lists
SQLite database
Core Data
As you say that you have a hybrid application which is for Android and ios you should use SQLite database, because
It is light weight
Comfortable with both Android and iOS [ Cross platform ]
capacity to Handle huge data
The handling of code, manipulating the code is much easy with sqlite.
So, its my opinion to u that you should use SQLite as an database for hybrid application, it will be easy for you. If you are doing application only for iOS then core date can be another good option since you doing both one SQLite is best.
As far as we consider speed and performance , SQLITE is best according to docs.
but you can use xml data storage as well but you will find a little bit slow than sqlite.
Your options are limited. Shared Preferences, local storage, sqlite and network are your only options.
Everything you need to know about your options can be found at the official Storeage Options docs.
I recommend that if you only need to save user options and states and not lots of data then you only need to use Shared Preferences. You can even save JSON in the shared preferences if you don't want to setup a sqlite database.
And remember a user can wipe app data from the app settings, if your worried about the data being wiped then the only option is network or a combination with network.