I'm making an app where the user can take a picture and add a title and description. But now I need to store the picture and the titles. I’ve tried making an object that contains title, description and image properties.
When it’s done I save an array of custom objects with the information on it with UserDefaults. My idea is showing in another view a table view with all the content and pictures the user has taken on the cells. I tried getting back the information with user defaults. It was working well until the user saves too many pictures. When the viewController with the tableview loads, then my app gets slower, and eventually it crashes.
I suppose the problem is when I load all the array with all custom objects, all the pictures are loaded into memory although they aren’t used and displayed for users. So I think it isn’t the best way to make what I want to make.
Is there any way better to make what I’m making or store data more efficiently and use it in tableview without using all the memory of the device?
I’m making the app from 0 again.
Can you show me how to store data and images efficiently?
There are several options for permanently storing user data on the device such that it will survive app and phone restarts. NSUserDefaults typically is for small amounts of data, such as user preferences.
When it comes time to store a lot of data, in particular big binary objects like photos, you need to decide which design you want to use. One option:
store all the photos in one directory in your apps documents and then use some simple lookup store (perhaps Core Data, or SQLite, or even a flat file) to index the photos and their metadata. Or if you don't care about indexing you can read the list of file names from the directory and sort them by time.
The other problem you are maybe having is that you are trying to load all of the photos at once for the user. As you have discovered, once you have more than a handful of photos this system falls apart. You need some mechanism to load only a few photos at a time, preferably only the ones the user needs to be displayed at that moment.
So, for example, if you are displaying the photos in a tableview, you want to only load the 10-15 photos that are visible in the table at any given time.
When storing this kind of data, you have 2 options (In fact you have more than 3 options, but saving image to the disk is IMHO complicated for this.) -
UserDefaults
Database like CoreData/Realm/FireBase...
The first one is recommended when there is not much data to save... For operating with more data, I would use database - CoreData...
For you operation you can use CoreData and NSFetchedResultsController (which is designed especially for fetching objects from the database)...
you can read the FetchedResultsController doc here... and core data basics here
Wish you best luck!
Related
I am wondering why storing user profile images as Data to user defaults is ill advised. The reason being: I have already created an app that has some people using it. The app requires that users create a profile, on which they can upload up to 6 profile pictures. The images get pushed to my back end and also are stored as Data to the app's user defaults.
I've read that it is better to save these images to the document directory and save the file path as a string to user defaults. Why is this exactly? Is it such a big deal that I should take the time to write code that will convert images saved as Data to user defaults on already existing devices to images saved to the document directory?
The "why" is easy. The UserDefaults is not a database. It's just a plist file. Either the whole thing is loaded into memory at once or it isn't. If it is, there are all your UIImage data objects sitting in memory. Memory is limited and images are big. Plus you waste time during loading and saving.
The "is it such a big deal" part is a matter of opinion. In my own opinion, yes, it is. That's because I've gone through this process, and I was glad I did. Yes, it's a pain writing migration code, but once you've done it you just leave it in place and your app is now handling data saving correctly forever after.
I have a social app, where the user can like photos... So, in order not to wait for fetching the data from the server, I want to store to the device, an array of strings, containing the photos' objectIds.. The question is, considering the user can like thousands of photos, is it good practise to use UserDefaults to achieve that?
EDIT
As pointed out by Eric Aya in the comments, NSUserDefaults aren't loaded automatically into memory when the app launches.
NSUserDefaults are loaded into memory when your application launches If you have a particularly large amount of data stored in NSUserDefaults then the time it takes your app to launch to load NSUserDefaults will be impacted by the amount of IO required to retrieve your data. The intended use case for NSUserDefaults is to store small sets of data such as default user settings.
A Plist may be a better solution (NSUserDefaults is just a Plist, the difference being is it's loaded automatically for you when the app launches). You will still have the same issues with load times when you decide to grab the Plist as you will be loading a file (the Plist) into memory. You will be able to handle this with something like a progress bar or an activity indicator which gives the user a nicer experience. than having to wait longer than usual for an app to open. CoreData is another option (usually intended for more complex data structures than strings, on the flip side it gives you the capability to scale your storage needs very easily if the complexity of your data increases), there's a fairly steep learning curve involved but it's a wonderful feature and is well documented by Apple: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/
I would also recommend storing the data on a server where you could expose it via an API and cache the response using a Plist/CoreData/Whatever you like. This way if your users change devices they will still have access to the same data as it's stored remotely.
Good luck!
i am developing an sample app where i have N number of custom button with images present in the screen.I can able to perform following operation(drag drop,rotate,change color etc.)upon these buttons.
I can also able to draw line on the screen.
So now i want to persist these data so that on restart of application i can able to see my previous objects.What is the best solution to do this?
You've got three options, all pretty simple:
store the data in user defaults
store the data in a plist in the documents directory
use core data
In all cases you'll need to transform your data into property list type format (strings, numbers, data, dictionaries, arrays). User defaults would be frowned on if you had a large amount of data. Core data could be overkill. A plist is probably your best bet on the information you have given.
You'll need to store your data either each time it changes or when the application goes into the background, and restore it if needed on launch. I say if needed, because if you are just resuming from background, everything may still be present if iOS hasn't sent you any memory warnings or closed you down.
Core Data. Use a managed object to represent each button with attributes like "color","position_x", "position_y", etc.. use sqlite as the persistent store.
My app has various pins that drop onto a map and when you click on the pins you get more information about this entity.
Each time you click on the entity it retrieves the information from a web service. Should I only retrieve this information once and store it in memory or should I retrieve it each time that page loads?
It's a small about of text and 3 small images?
If its just 3 small images and some text that will not change i would probably cache them in the application instead of retriving them over and over, it will provide a better user expirience in my opinion...
Also I have a Core Data application that uses images...
I tried both methods but I chose to retrieve it every time because for my goal is the best practice. However this method causes me to write some code and a lot of if and else!
How Daniel said, cache each image can be a better solution for your problem because if an user would like to retrieve these images from internet but the connections isn't fast, he'll wait a lot of time...
I'm currently working on an application that users a number of different views to obtain user information and I have just hit a snag.
My current method saves each user detail against a key value in a plist file, the problem is that when the user switches to another view and saves their data again, the old keys and data are overwritten.
So my question is what is more efficient, to a) have a different plist for each different view or b) read all the existing data from the file first then save the data back to the file along with the new details.
Bearing in mind eventually I will want to export all of this information as XML, though it shouldn't be too difficult to read form multiple files.
thanks in advance!
It would probably be more efficient to use multiple files. The most scarce resource on the iPhone is memory, and loading a huge plist could potentially use up a lot. Using multiple files means you don't have to load all of the plists into memory at once. If you have a lot of data, I'd also suggest taking a look at Core Data eventually.