I have an app which communicates with a server. In this app I have a tableview in which I display several people from my company (their first and last name and their profile image).
Every time the tableview opens or needs to refresh, I fetch the user list from my server. These users will all have an image_name, which I try to look up in an array on the app itself. If I can't find it there, I load it from the documents dir, if I can't find it there either I download it from my server and save in locally on the device to prevent future downloads.
This works very well and it's a very easy way to manage the users and their images, it also makes sure that I download an image only once if several users have the same image (e.g. the company logo when they haven't uploaded an image yet).
The problem is that I don't keep a reference to these users so the app has no clue which user uses which image OR even if an image is still in use.
So when person A has image X it will be downloaded to the iPhone. If user A then changes his image to Y, the app will download and display image Y correctly. However, image X will never get deleted from the persistent data.
I ask you, the stackoverflow community, what's the best way to handle this?
Should I start keeping a reference to my users so I can also keep a reference to the old image?
Is there any way to find the timestamp of the last time and image was read from the documents dir?
Should I store the image names in coreData and all the references to them? (some kind of custom ARC logic)
...
At some point in time you have the list of used images, at this point in time you also have a list of images saved to disk. Once per day you can take this information and, on a background thread, do a comparison of the used and saved and delete them. This shouldn't require any additional data storage.
If you wanted to allow images to hang around for a while after they stop being used you can 'touch' the file (update the fileModificationDate) each time you use the file and then later you can check the modification dates of all images and delete on that basis.
You could add a prefix to the image that you download and when you fetch images, check all images in persistent storage for this prefix and then remove if there are any. You should only need to delete (maximum) one image every time your client fetches, which wouldn't be too heavy on the client.
Related
I am trying to better understand firebase storage, and I have two questions.
Does saving an image under the same reference delete the previously stored image in the storage, or does it keep it. Example : A user posts an image to firebase, I use the function storage.putData, to upload an image1 to the storage on firebase with the reference of Storage.storage().reference().child("photo"), and then I upload an image of the same ref to the storage, but a different image. Does this also delete the image1 from storage? Or does it keep it there, but is not accessible. I want to better keep my storage small.
Does storage.delete delete all data of the deleted image from firebase? I wonder this because I pay for the blaze plan with 60 gbs of storage, and I wanted to know if deleting and image with that function, lowers my storage and clears up actual space, or does it still keep some of it? I don't want be paying 100 $ a month, so I am really trying to delete any unimportant images.
A StorageReference is a reference to a specific, unique location on disk. Writing another image to the same reference overwrites the existing data at that location.
Calling StorageReference.delete() deletes the data at that location. After this you will no longer be charged for storing of the data.
I couldn't find resources discussing the difference between the three download methods in the firebase storage documentation and pros/cons of each. I would like some clarification about the firebase storage documentation.
My App
Displays 100 images ranging from 10 KB-500 KB in size on a table view
Will be used in a location where internet connection and/or phone service could be very weak
Could be used by many users
3 methods for downloading from Firebase storage
Download to NSData in memory
This is the easiest way to quickly download a file, but it must load entire contents of your file into memory. If you request a file larger than your app's available memory, your app will crash. To protect against memory issues, make sure to set the max size to something you know your app can handle, or use another download method.
Question: I tried this method to display 100 images that were 10KB-500KB in size on my table view cells. Although my app didn't crash, as I scrolled through my table, my memory usage increased to 268 mb. Would this method not be recommended for displaying a lot of images?
Download to an NSURL representing a file on device
The writeToFile:completion: method downloads a file directly to a local device. Use this if your users want to have access to the file while offline or to share in a different app.
Question: Does that mean all images from firebase storage will be downloaded on user's phone? Does that mean that the app will be taking up a large percentage of the available storage on the phone?
Generate an NSURL representing the file online
If you already have download infrastructure based around URLs, or just want a URL to share, you can get the download URL for a file by calling the downloadURLWithCompletion: method on a storage reference.
Question: Does this method require a strong internet connection and/or phone service connection to work?
Generally, your memory usage should not be affected by the method of retrieval. As long as you're displaying the 100 images, their data will be stored in the memory and should have the same size if they're identically formatted/compressed.
Either way you go with, I suggest you implement pagination (for your convenience, this question's answer might serve as a good implementation reference/guide) to possibly decrease the memory and network usage.
Now, down to comparing the methods:
Method 1
...but it must load entire contents of your file into memory.
This line might throw some people off thinking it's a
memory-inefficient solution, when all it really means is that you
cannot retrieve parts of the data, you can only download the entire
file. In the case of storing images, you probably would want that for
the data to make sense.
If your application needs to download the images every time the users
access it (i.e if your images are regularly updated), then this
method will probably suit you best. The images will be downloaded
every time the application starts, then they'll get discarded when
you kill it.
You stated that a part of your user base might have a weak internet
connection and so the next method might be more efficient and
user-friendly
Method 2
First off, the answers to your questions:
Yes. The images downloaded using this method will be stored on the users' devices.
The images should take up about the same size they're taking on Firebase storage.
Secondly, if you plan to use this method, then I suggest you store a
timestamp (or any sort of marker) in your database for when the last
change to the images occurred. Then, every time the app opens up, do
the following flow:
If no images are downloaded -> download images and store the database timestamp locally
If the local timestamp does not equal the timestamp on the database -> download images and store the new timestamp locally
Else -> use the images you already have, they should be identical to the ones in Firebase storage
That would be the best way to go if your network usage priority is
higher than that of the local storage.
And finally...
Method 3 (not really)
This is not a data download method, this simply generates a
download URL given a reference to the child. You can then use that
URL to download the data in your app or elsewhere as long as the used
app or API is authorized to access your Firebase storage.
Update:
The URL is generated from a Firebase reference (FIRDatabase.database().reference().child("exampleReference")) and would look like this: (Note: this is a fake link that will not actually work, just used for illustration purpose)
https://firebasestorage.googleapis.com/v0/b/projectName.appspot.com/o/somePathHere%2FchildName%2FsomeOtherChildName%2FimageName.jpg?alt=media&token=1a8f83a7-95xf-4d3s-nf9b-99a274927bcb
If you simply try to access that link you generate through any regular web-browser (assuming you don't have any Firebase rule that conflicts with that in your project), you can directly download that image from anywhere, not just through your app.
So in conclusion, this "Method" does not download data from Firebase storage, it just returns a download URL for your data in case you want a direct link.
I want to develop the solution where storing of image data downloaded from server and display it.
Scenario is, There will be thumbnail images placed on each row, clicking on that will download the actual image from server and display the image in a bigger view.
I want to store this image data once its downloaded from server, so that in the later stage if the same thumbnail has clicked to open, I don't need to again download the actual image from server, instead I can pull that from the place where I stored locally.
There will be more than 80 thumbnail images placed in rows and corresponding bigger images on the server.
Can I store the image data in a file and store it in documents directory or some thing like that? My worry, if the user selected all the 80 thumbnail images, then i'll have to store all the 80 bigger images locally on the app.
What is the best way to achieve this storing solution? Please advise.
Thank you.
You can store the images in the documents folder, as you already said. Just make sure to exclude them from backups, Apple will reject you for storing too much replaceable data in there.
There are also some third party image cache libraries, most notably (afaik) FastImageCache from Path:
https://github.com/path/FastImageCache
From their website what FastImageCache does is this:
Stores images of similar sizes and styles together
Persists image data to disk
Returns images to the user significantly faster than traditional methods
Automatically manages cache expiry based on recency of usage
Utilizes a model-based approach for storing and retrieving images
Allows images to be processed on a per-model basis before being stored into the cache
So my iOS app has just been rejected because it's storing too much non-user-created data in the SQLite database, which lives in the Documents folder.
The app basically involves a relatively large library of images -- around 60-or-so megabytes of them to start, and there are also in-app purchases which each add an additional 60-or-so mb of images. Furthermore, the user can add their own images to the library.
Right now everything (images and all) is stored in an SQLite database, which is generated when the app is first launched. As the user adds more images, or purchases image packs, those images are added to the database. To the user, all the images (user-generated or not) behave the same in the app.
But Apple won't allow this: I can't have all that data stored in the SQLite database in the Documents folder unless I set it specifically NOT to back up to iCloud, as it's all recreatable data.
But if I set it to not back up, then the user-generated data won't back up either, which I definitely don't want.
Any suggestions how I might "split up" the database, such that all the user-generated stuff can be backed up, but the included-or-purchased stuff isn't?
The reason you are being rejected is not following the Data Storage Guidelines. Data created or edited by the user belongs within NSDocumentsDirectory, while application data should be stored elsewhere (i.e., the Application Support directory). These requirements are a result of how iCloud backup and disk space purging work on iOS.
For a Core Data application, this means your persistent stores must be split into two different sets of files, in two different locations. This, in turn, ends up driving much of the application architecture and data model. To have relationships between the user data and application data, for instance, you must use two different managed object model configurations and the relationship must be a fetched property.
There is more detail on how to implement this in this answer.
An alternative for your specific case would be to save the images on the file system, in the caches directory or elsewhere. User images could exist in NSDocumentsDirectory while application images could exist in NSCachesDirectory. This would remove the images from Core Data and instead your model objects would have the path to the image on the file system. This would be a short term fix to get you through submission, and would probably work.
One option will be, storing your data to a server and calling is using web service. During first launch. Or as per requirement.
I’m making a gallery on site. And don’t know what the best solution for it. Need advice.
For my opinion there are two ways of operating with images.
User uploads image. I save it on server only once, only with its original size. And then, when there’s a need of displaying that image on screen I resize it to the necessary size, for example as avatar. So I store only ONE original-sized image and resize it to ANY proper size RIGHT BEFORE displaying.
User uploads image. I save it on server with original size and also make and save several copies (thumbnails-sized), for example, avatar-sized, erc. So that if the image is displayed it’s not resized every time it is displayed, just proper-sized copy taken.
I think that the second way is better. Because there’s no need to spend server strength on resizing images every time. But what if I’ll decide to change design of my site and some dimensions of images on it will be resized too? I’ll get the situation of having lots of images on server that doesn’t fit new design.
All around different forums they explain how to make galleries and every time they say that thumbnail-sized copies are also made and saved. But it looks like it doesn’t make sense if design is changed in time. Please, advise. Language – PHP.
One solution that others have come up with is a mix between the two. So, the user uploads the photo and you save it in its original form on your server. Then, when an avatar is needed, you check to see if you have the avatar saved on disk (maybe user12345_50x50.jpg - where 50x50 is widthxheight). If it does exist, show that image. If not, then use the server to resize/crop whatever, then save that image to disk and serve that to the user. This will allow you to request any size file and serve it as-needed -- taking advantage of caching those that have already been requested [Note that this is a server-side cache, so would apply for all users].
You sort of get the best of both worlds. You don't need to handle all of the image manipulation up front, just as needed. The first time the image is processed, that user will have to wait, but any other request will get the processed file.
One implementation that uses this solution in PHP is phpthumb: http://phpthumb.sourceforge.net/