Let me explain how my application is supposed to work:
Application will ship with a sqlite database in its assets folder which will be copied into databases folder later and it has some content in it(categories, sub categories, products and news) which they all have image. Then after download user can update the content via internet and the application store the new content in database so the application can perform offline.
So my question is, after a while this content will increase in size, is it gonna cause my application to crash? Lets say I release the application with 1 MB database and after 2 years of work the database size goes up around 120 MB. Is it gonna make the application to crash?
Also the other concern is that currently I'm storing the images in database and I load'em from there. Is it a good approach? Because I don't want user to be able to clear the cache or delete the images because later on updating the content it has to download those deleted images again and it will consume traffic imo.
please remember that the Application should be able to load content offline
No, applications don't just crash because they have a large database.
Part of the point of a Cursor is that it gives you a view into a large set of data, without having to load it all into memory at the same time.
If you follow best practices I see no problem - you're using a database. Forget for a second that it's on Android - you should optimize your table structure, indexes, etc, as best you can.
Also, large database or not, don't make any queries to it on the main thread. Use the Loader API if you need to show the result of a query in your UI.
Last, potentially most importantly, rethink why you even need such a large database. Is it really that common that a user will need to access all data ever while offline? Or might it make more sense for you to only store data from the last week or month, etc, and tell them that they need to be online to access older data.
Regarding your 2nd question - please in the future separate that into a separate question. But, no, storing binary blobs (images in this case) in a sqlite database is not good approach. Also, if they clear data on the app, everything is gone, so there's no advantage to using a database to avoid that. I would suggest storing images in a folder named after your app in external storage of the device, potentially storing image URIs/names in the database.
Any problem with database will cause SQLiteException which you are able to handle in your app to prevent the abnormal termination.
Having said that, a database of 120 MB seems to be too much, are you sure your users will want all that?
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.
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 have been asked to create a tiny android app.
In everyday work i code for .NET and I have no experience connected with Android, but as it is a really small app I guess it's going to be a good experience rather than something hard.
The core of the app would be a small database (probably XML, unless somebody suggest better solution) that would contain categories, names of the institutions assigned with each category and logo (not very high resolution I guess a single file would be <100kB) of the institution.
The database also would not be very big - I expect not more than 1000 records in total. The DB has to be totally offline and local, it cannot require Internet access when operating.
The model I assume would be to ship new version of the application when the database changes (which is not going to be very frequent).
What is the best way to deal with these requirements?
My first idea was to create an XML file that would contain the records and link to the image. The XML and all the images linked to it would be stored in single file (preferably zip) that would be stored in app resources. This is very good as it is going to be very easy to update the database.
The second idea that somebody suggested me would be to use SQLite and store images in BLOB. In general I have read that it isn't a good idea to store images in database directly, and I am afraid if it's going to be possible to meet all requirements mentioned above.
Mostly I have no idea how to update the database easily and attach it to new version of application.
Any suggestions?
I would be grateful for any response.
I wouldn't go about using XML to save your data and by no means zip anything.
I think your way of thinking is ok, but you're making things really complicated for yourself.
Seeing as you're used to .NET I suppose you're also pretty confident with SQL, so I'd suggest you have a look at how to use the built-in SQLite database in Android.
If you would go the XML route you'd have to serialize and de-serialize the XML file over and over again and then parse the XML. Ok you don't have a lot of data, but searching inside an XML file with at least 1000 nodes would be slow in comparison to the performance of a database.
Also upgrading an existing SQLite database is not that hard - Android has methods for that (onUpgrade coming from the SQLiteOpenHelper).
As to saving images I'm assuming that you won't fetch new pictures from the Internet, so it would be best just to store them in the drawable folder of your app (be mindful of different screensizes) and then reading them into an ImageView when needed. To figure out what image should go for what institution I would store either the image name of each image in the SQLite database or store the resource id for each image in the database - for instance R.drawable.myawesomepictureformyinstitution.
I know my answer is somewhat "superficial", but your question is also somewhat "broad" and hard to answer without me actually writing most of the code, and that's not my intention ;-)
Hope this helps - let me know if anything is unclear.
There are many similar questions about this issue but I have clear points about my question to ask you.
I am new at Android development and before only I developed small applications which store small sized data. For example country List, calendar, birthday reminder etc. I stored my small data in single XML file and I parsed it with easy methods. This was enough for me. But for my Mobile Application Development Course I took a project which will store huge static data.
Specifications of my project will like these:
There are about 200 entities.
Each entity has about 20 sub categories which they stored in text format.
Each sub category has about 30-sub categories which they stored again in text format.
Also for each parent entity I will have 2-3 image
If I calculate simply, I have to store 200 X 20 X 30 = 120.000 static data for my application and data does not change. This is only install and use application. Online data interaction is not necessary. (If there are some changes for data I will relase major updates in long periods of time.)
My question is about storing method.
Which way should I choose? SQLite or XML parsing? For your answer can you explain advantages / disadvantages for your choice?
Interesting project, although not necessarily realistic.
To manage a large amount of "static" data, you'll want a database. XML parsing forces you to store the data in memory, which means that you have to read it into memory on a regular basis. Remember that you can't count the in-memory data being around when the user goes to your app; Android may have destroyed your app previously.
On the other hand, you can use an SQLite database on disk directly from your app. It's persistent, even if your app goes away. You'll have to load the database once, when you install the app.
Consider wrapping your SQLite database in a content provider. This will, among other things, allow you to do asynchronous queries using a CursorLoader.
Im working on a self-test app.
And I wondering on how to store the data, I've got over 200 questions and more is on the way.
Was thinking of storing them as XML but didnt find a way to get a random question without reading the whole string-array to a variable, which is bad for the memory.
So the correct way to go is to use a SQL-database, right?
But how do I make such a database so that it exists at boot and dont need to be made during start up?
Can't seem to find any tutorial on this subject, on how to handle questionnaires.
Here's a good tutorial on SQLite and Content Provider. It'll introduce you to using SQL databases on Android, and wrapping them into a ContentProvider.
As for how to get the data to the device - you have two options:
You pack the SQLite .db file in the application assets folder. Pros: the database is ready for consumption on the first run of the app. Cons: your .apk is too big. Updating is hard.
You download the data on the first run. Pros: your .apk is slim. updating is easy Cons: there's a delay before the user can use the app.
You ship a small .db file with the first 10 questions. Pros: Your users can start using the app immediately, while you download the rest of the questions in the background. Cons: You have to pick 10 questions you're likely to never or rarely change, or you risk your app to start with outdated data.
Create the db offline and either put it in the apk or download it.