Android Question Online images vs download for further use - best practise?

tsteward said:

So I am wondering should I be saving the images after being downloaded the first time and then use a local image or is it acceptable to use online image?

Click to expand...

this is a good question.
does your app work only with internet connection? besides the images?
what about the other data do you always get it from the net?
i think it is always a good choice to save/load data locally.
i would save everything locally and allow to download the data via click on a refresh button or a refresh function that run every x sec/min if you need to always stay updated.
if you do decide to download the images and work with them offline but still want to check if the image that is online has been updated and download the latest image then you can store image info on a db and check the latest upload date/time with the current download date/time you have on the stored images.
making such checks if much faster then downloading the image

so what i would do is this

have a database online with all necessary columns and a datetime column where you save the last update of that row. now you have a copy of that db on your phone locally (sqlite) and every x time (min./sec) you decide you make the check if the datetime is higher then the one you have on your sqlite db if yes download only those rows.

These are only small images and will not change often.
The app would function if internet not available although many other features rely on internet access.
a DB to track image download & date seems like too much work, but food for thought thank you.

1. Do users who already have my app and some images want another couple of hundred images sitting on their device using precious memory.
2. Do they care about data and want to continually download the same image when the cache has been cleared even if that once a week.

Thank you for your thoughts

tsteward said:

1. Do users who already have my app and some images want another couple of hundred images sitting on their device using precious memory.

Click to expand...

i dont know much people that constantly check how much an app uses space on the phone. many times you download an app that has less then 10mb but when you uninstall it you see that it got to several hundreds mb. but again it is not something you track (the space an app usage) besides that you are talking about small images that maybe will take around 50-80mb and that is not much for new phones that have 256gb memory standard today.

tsteward said:

2. Do they care about data and want to continually download the same image when the cache has been cleared even if that once a week.

Click to expand...

the question is what happen if connection is lost and you are in the middle of scrolling the clv? i think users won't like to see and empty clv when scrolling. better to save them locally. you can also save a smaller version of the images and only if the user clicks the image you download the real size of it.. inside a clv list you dont really need full size images anyway.

I have an app that users can choose to either use a local SQLite DB or Firestore to keep their data. The can also add images (avatars, album pics, etc...) which, if they are using Firestore, are uploaded to Firebase Storage. I also keep a local copy of the image to make accessing it faster - so effectively the Firebase Storage copy is just a backup. If for some reason the local image is corrupted or accidentally deleted, the app will just download the Firebase Storage copy & save it to the app specific storage.

There's a little more overhead in doing it this way because you have to make sure the images are synched - ie: if the user deletes an image in the app you have to delete it from local storage and Firebase Storage & of course you also have to delete the original image & upload another one if the user changes it - but overall it seems to work pretty well & speeds up the time it takes to access images - especially if the user has created an album with a heap of images in it.

- Colin.