0

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

arash moeen
  • 4,533
  • 9
  • 40
  • 85

2 Answers2

2

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.

Sam Dozor
  • 40,335
  • 6
  • 42
  • 42
  • Thank you Sam for your insight, yea they want the user to be able to access all the updated content offline, I tried explaining what you just mentioned about accessing the last week or month data but that's how they want it. – arash moeen Jan 30 '15 at 19:17
  • About your 2nd answer, so basically there's no point in storing it my database and I should do as your said. and everytime they try to update I have to check if that for example news has its images in the folder and if not then download those deleted images again? – arash moeen Jan 30 '15 at 19:19
  • yes. That said, I would not try implementing that yourself. There are several great libraries that will manage an in-memory cache, an on-disk cache, and then a network fallback option. It can be complicated to build yourself - check out http://square.github.io/picasso/ or https://github.com/nostra13/Android-Universal-Image-Loader – Sam Dozor Jan 30 '15 at 19:24
  • Why, it will crash if it can not, say, add a record and you do not handle SQLiteException thrown because of this. – Alexander Kulyakhtin Jan 30 '15 at 19:27
  • What? what does this have to do with my answer? – Sam Dozor Jan 30 '15 at 19:38
  • It is an argument against your statement: "No, applications don't just crash because they have a large database." This statement is not true. – Alexander Kulyakhtin Jan 30 '15 at 19:47
  • An application will throw an exception if a record can't be inserted do to lack of physical space. This is true if your database only was 1 KB in size and there was simply no space. This is something that you have to take in to account no matter what. However, an app is not going to simply crash because the database is large as long as there is space to place it. – DeeV Jan 30 '15 at 19:49
  • Thank you @DeeV, that's what i mean and figured was obvious. – Sam Dozor Jan 30 '15 at 19:55
  • @SamDozor Thanks man, yea I was thinking of using picassa since I'm familiar with it but 1 question here, the part that I should download the images and save them in the folder is a part I should do when the application is updating, right? what about the first time that the application is going to be shipped with the content and should work offline? How can I handle those first batch of images then since I don't wanna put images in the folder at first and then add the urls to the db on every application release for different companies – arash moeen Jan 30 '15 at 20:33
-2

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?

Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • They kinda are worried about that but it's not my call, I rather to move to online approach but they want it to be offline. Of course that'd be too much when a device has only 4 GB or even much less space. – arash moeen Jan 30 '15 at 19:20
  • Well, anyway, you have to catch possible SQLiteExceptions then. It's an unchecked exception so it's harder. You can also set a global exception handler to do smth when your app crashes. If a database is large SQLIteException is likely to be thrown when no more space etc. – Alexander Kulyakhtin Jan 30 '15 at 19:25
  • 1
    this answer is vague and incorrect, please expand on it. Saying 'just catch exceptions' is not an answer. Also, `SQLiteException` is not the only exception that could be thrown from an interaction with a database. – Sam Dozor Jan 30 '15 at 19:37
  • Sorry if I was unclear. What I wanted to say is this: in case of ANY database issues (and you are likely to have them your db being very large) an UNCHECKED exception will be thrown by the OS. I hope you know what unchecked exceptions are and why they are harder to handle. If db is not large everyone ignores them but when the db is large they are likely to happen. – Alexander Kulyakhtin Jan 30 '15 at 19:45