I am developing an iOS game and I have two questions. First, I am maintaining the levels information (scores, background image, etc) into a plist file. The first time that the app is launched, I copy the plist file from the resources directory to the documents directory (I need to write the user best scores into it). Exits a best way to maintaing this information? Second, if I make an update of the app, adding new levels par example, how can I add the update new information without losing the current user scores?
Thanks for reading.
A property list seems as good a way to keep track of high scores and such as any other. If you've already got that working, stick with it until you have a good reason to change.
Your data file (indeed, the entire contents of the Documents directory) will be preserved when the user updates to a new version of the app.
AS Caleb said, a pList file is probably fine for saving high scores.
I'd like to add a bit about #2. You can just always re-use the same save file for simplicity, as long as you plan ahead for updates. This is a lot easier than trying to juggle different plist files for different versions.
When you create your game save plist file, just be sure to include a field for a save game format version number. That way, for future releases, you can open the save file, read the version number, and make any necessary adjustments to bring it up to the current version. This is extremely handy when players can essentially skip updates, downloading version 1 and 3 but skipping 2.
I agree with Caleb. It's best to have a little source code to help you.
I created this sample code that has both local and global support.
You might want to have a look at the NSUserDefaults class which provides basic management capabilities for storing app data. For more advanced data storage, CoreData is the recommended way to go.
Related
I am building my flash card iOS app for reviewing my learning Japanese using SwiftUI language.
The problem is how to storing and updating my images(>500 images). Please help me, any suggestion is appreciated, thanks for reading my post.
I think you're asking about how to manage 500+ images in an Xcode project. You could just add all the images to your project and load them as you would any image. You could use asset catalogs, which have the advantage that they let you store different versions of a resource for use on different devices, and only the ones needed for the device the app runs on will actually be installed on the device. See How Many Images Can/Should you Store in xcassets in Xcode? and Asset Catalog Format Reference for more information about asset catalogs. But any way you slice it, managing 500+ images is going to be cumbersome. There's probably a better way...
Managing all those images in your app isn't just a problem for you as the developer; building them into the app will also create problems for the user. Even if each image is relatively small, having hundreds of them in the app will probably make the app huge. That means it'll take a long time to install, and the app will use a lot of storage on the device. Every time you release a new version of the app, with more words, or even just to fix a few small bugs, the user will have to download all that data all over again.
Instead, you should consider building an app that can fetch the data it needs from a server. Ideally, you could apply that approach to all your app's data, not just the images. Maybe you'll organize your flash cards into sets of a few dozen, so that you can fetch a set of cards and the associated images pretty quickly, and sets that the user hasn't used for a while can be removed to free up space on the device. You'll be able to update a set of flash cards without having to update the app, and when you do update the app your users won't have to download all the data all over again.
You've said that you're a beginner, so this approach might seems very difficult. That's OK, you can start with a simpler approach and then improve as you go along. For example, you might just put all the images on a server and fetch them one at a time as you need them. Your flash card data file could contain just a dictionary with words and the URLs associated with those words. There are lots of examples of loading an image from an URL here on SO and elsewhere, so I'm not going to provide code for that, but it won't be hard to find. The earlier you start thinking about how to design your app so that it can scale as you add more and more words, the easier it will be to maintain the app later.
500 images can have a huge size. Applications that published on Appstore have size limit and Apple does not recommend to make big apps.
Store them on server and load needed images on fly. Also you will get possibility to update your images, remove add new.
If you don't have a backend, you can use something easy and free (Firebase storage for example) or with minimal code writing on AWS.
If you need to keep them on device - store them as files in the Documents or another apps folder, do not use CoreData for it (you can keep only the list of names/urls in database).
After loading image to be displayed for user, you can prefetch next bunch of images.
Use Alamofire, or SDWebImage to load images from network (I prefer last). These frameworks can do many useful things with images.
To load images:
you can have a list of your images (just list of the names and urls)
or
you can know only path and names pattern and generate links dynamically (like https://myserver/imageXXX.png.
In my iOS app, I need to keep track of which sequence numbers have already been received from the server and which sequence numbers need to be retrieved. I want to be able to store this in case the app terminates or crashes.
I am trying to decide which storage method I should use: core data, plist etc.
The list of sequence numbers is dynamic and can change a lot. Any pointers on how to decide on storage will be greatly appreciated.
Without more exact details in your question it is hard to give you an accurate answer. However, what can be provided is some insights on the benefits / downfalls of using the storage systems listed above.
I would stay away from using a plist since your data is dynamic and can change a lot. Every time you save to a plist you will need to overwrite the entire file. This means to change a single value you must retrieve all values, make a single change, and save all values back to the plist. This isn't a modular way of doing such saves and can become problematic if you have a lot of information that is changing and needs to be saved all the time. On the up side - setting up a plist save / read write structure is very easy and fast.
NSUserDefaults should be used for just that. Saving user settings and preferences. It is really easy to use NSUserDefaults, but may become very problematic in the long run if you data is very large. Values returned from NSUserDefaults are immutable too. This may or may not be a problem for your needs.
CoreData may be overkill for what you're doing, unless your sequence numbers are very large. Personally, I would go with CoreData knowing how it can handle dynamic values and how fast it is to save objects compared to the plist and NSUserDefaults. The down side is CoreData is a bit of a learning curve. Unless you have used it before, it is easy to go down the wrong path using it.
As far as pointers on which storage option to use, do some research. Make a list of pros and cons of each storage option. Ask yourself how big your data may get, and what is the best solution. You already know the data is dynamic and may change a lot. Look at the performance of each storage solution.
Here are some helpful reading material links straight from Apple:
Plist
NSUserDefaults
CoreData
I've used archiving, user defaults, and some Core Data in my apps before, but I'm running into a wall re: the best method for my current scenario. I have an app that needs to instantiate some objects from a resource file each time before it's used. An example of one of the objects could be a "MathQuestion" object that has the properties:
questionID (Int) - 2341
questionText (String) — "What is the square root of _?"
questionVariable (Float) – "4"
correctAnswer (a block/closure that returns a Float) – "{return sqrt(value)}".
Ideally, I'd just have something like a spreadsheet with columns for each of these properties and rows for each of the different questions. That way, I would really be able to visualize all the data and make quick changes during development.
My app uses Parse, which is great for visualization and easy editing of values, but for this case, I'd rather the resources remained on the device and not the Parse server. I've been considering Core Data up till this point, but (this could be my inexperience with C.D.), I'm unaware of any way to manually edit the data—and it seems like it may be overkill for what I'm looking for anyways. (I basically just need a way to upload and parse a CSV!) Any advice would be welcome!
I would still recommend Core Data. It is simply the most efficient and scalable mechanism to store and retrieve data.
When I work in your kind of scenario, what I often do is work with a spreadsheet where I can conveniently edit the data. You could edit a CSV version of it that you have included in your target. (If this does not work for you, you could also copy paste into a separate CSV file right into Xcode.)
On every start, you just trash the data store (using NSFileManager when creating the NSPersistentStoreCoordinator). Then you call a method that reads in the CSV and stores it in Core Data.
Once you are done with development, you simply keep the sqlite file (you can include it in the bundle and copy it over, or re-generate it from your CSV the first time the app runs).
First time asking a question on here, so please go easy if I don't provide enough info. Basically part of my iOS app allows users to take a picture which will be stored in a Core Data store. The attribute is a Transformable type, and I have created an NSManagedObject subclass which I simply use to set its image attribute to the new image provided by the user.
I know storing large files in Core Data is a bad idea, which is why I was excited when I saw the "Store in External Record File" option under the image attribute in the Core Data entity. However, my app performance says otherwise, taking several seconds on an iPhone 5 to load only a few images (which I know doesn't sound like much time, but considering how powerful the iPhone 5 is, older devices would likely take much longer with the same data).
I've looked around, and some people say that the Store in External Record File option is only applicable to the OS X environment, even though it is available in an iOS app. However, I also saw this under Apple's "What's New in iOS 5" doc (it's the next to last item under Core Data, near the end):
Managed objects support two significant new features: ordered relationships, and external storage for attribute values. If you specify that the value of a managed object attribute may be stored as an external record, Core Data heuristically decides on a per-value basis whether it should save the data directly in the database or store a URL to a separate file that it manages for you.
So my question is, who's right? Is it true that Apple made a mistake in giving this option for iOS apps, and that it actually does nothing unless you're on the Mac, or does it actually do something and I'm not configuring it the right way, or is it doing what it's supposed to do and the performance is bad anyway?
I've seen some guides explaining how to store large files (like images) as files, and save the URL to them in the Core Data store instead, but since this is essentially what this new option is doing, or maybe should be doing, I'm not sure if following these guides would even help.
I'm really sorry if this has been asked before. Normally I'd be fine with figuring this out on my own, but Core Data is totally new to me, and I'm still not sure how I managed to squeak by the initial setup. Thank you for any help you can offer!
who's right ?
the iOS docset for the NSAttributeDescription class does mention the allowsExternalBinaryDataStorage and the setAllowsExternalBinaryDataStorage: methods so there is little chance that there is a mistake from Apple.
are you doing something wrong or is slow anyway ?
You said that
The attribute is a Transformable type
But Core Data has a Binary data type. Maybe only this one is linked to the external storage capability.
if that's not it, we don't have enough info here:
How many pictures do you store ?
What are their sizes ?
Do you automatically fetch all the images ?
Also, the Apple doc states that:
Core Data heuristically decides on a per-value basis…
Did you use a migration or are you starting from scratch ?
You could have a look in your app's sandbox to see if your pictures are really saved outside of CoreData.
Hope this helps.
Good question!
Check this post:
Storing blobs in external location using built-in CoreData option
Apparently it should work. You should also try it in the simulator and inspect the application data folder to see if the folders are created as described (~/Library/Application Support/iPhone Simulator/... - you will figure out the rest of the path). Also you could inspect the sqlite file with the sqlite3 command to see if the binary data is in the database.
I haven't personally used this option as I would prefer to go for manually saving the images in a folder and store a reference to them in the database instead. This way it will be easier to create UIImage object from the file to be displayed, would have better control on what goes where and so on and so forth. Will take some extra labour though!
Hope that helps you out.
I want to store earned xp and gold, so that my game loads the data whenever the game starts. I am using cocos2d on the iPhone, what would be a safe (doesn't need to be toooo safe) to store such data?
I don't want the user to be able to modify the xp-points too easily. Is that possible with .plists? Or do I have to use a Database like SQL lite? It would be very nice if the user couldn't just change the values of the .plist that easily.
It may be easiest to use NSUserPreferences.
How about storing the information in a dictionary, archiving it, then encrypting the data with one of the many available encryption categories like the one shared by Aquatic?
Nothing you can do would stop a determined and experienced hacker but this would make it difficult / effectively impossible for the average user.