I'm designing a foreign language teaching app. The app will come with its own dictionary, but will also have a dictionary created by the user. When the application dictionary is updated, I do not want to lose user words, or word scores.
I've been using Core Data as a model for the application dictionary. At present, I'm using Core Data also for the user dictionary.
Obviously in this mode, user dictionaries do not sync across devices.
I have tried CloudKit, but that duplicates my application dictionary, even though I this is saved using NSPersistentController rather than NSPersistentCloudkitController.
My question is mainly whether I'm taking the correct approach, and ideally, is there an example?
I'm attaching my core data model showing local and cloud configurations.
Thanks for any help.
Related
usually in Android I use </string-array name=""> tag in .xml file and refer to it inside the code by its name.
what is the best practice to create an array in IOS that I can use in multiple views without having to create it over and over again?
Depending on what values you want to store in your array and if you want to persist if you need to write into the array and persist it between app runs as well, you have several methods.
Store the array in UserDefaults. You can read from/write to UserDefaults from each of your ViewControllers and your data will be persisted even if the user quits the app.
Store it in a file. I wouldn't really recommend this option, unless you have a lot of data to store that can be easily represented as String/NSData.
Store data in a shared, singleton variable. This method is only suitable if you don't want to write into your array or you don't need to persist it between runs.
Use a database framework (CoreData or Realm). This is only recommended, if you have really complex data, but since you mentioned only an array, this shouldn't be your case.
Based on the amount of information provided in your question, I would suggest going for UserDefaults, it is quite easy to handle data in UserDefaults and it should be sufficient for your task.
I'm storing just one NSArray to NSUserDefaults, but this array may eventually have many objects inside.
Could it be a problem using NSUserDefaults?
I would say use Core Data just because you want to simplify your life when dealing with anything more than a hundred data objects within two or more categories or "entities".
Using Core Data means that you're not dumping the entire data set into memory when you load it. Instead, you're using what are called faults which fire when necessary to load additional relationships and associated data.
Migrating the data is also another big benefit of Core Data. When you need to change the data structure, you just create a simple migration and it's done automatically for you. If instead you had an NSArray or NSDictionary in the user defaults, you'd have to iterate over the entire thing and try to change the data structure or migrate an old key name to a new key name. Not an easy task.
Another benefit of Core Data is that it works seamlessly with UITableView and UICollectionView to intelligently search and load only relevant items within your data set which helps improve overall app performance. This is all done via NSFetchedResultsController.
Working with one type of NSArray such as People that only has a hundred people in it shouldn't be a big deal and you can use NSUserDefaults for that as long as the People array doesn't have a lot of associated data stored within it.
Honestly, every app I create that needs any kind of data storage other than basic user preferences uses Core Data now. I don't waste my time on Property Lists or user defaults anymore and I would recommend you not to either.
NSUserDefaults is named as it is for a reason. It's designed to store a handful of user preferences and settings for your app, not the bulk of its data. If you're storing anything that resembles a database, NSUserDefaults is not the way to implement it -- use Core Data, as per #iWasRobbed's answer.
NSUserDefaults only use to store limited amount of data.if you have large amount of data you should go with coreData.
I am really confused on what the Core Data actually is. Or I guess my question is, when dealing with a database, would you use Core Data? Like if I wanted access values from a database would I be using Core Data to access those values? How would I approach this problem?
Thank you so much for the help.
Core Data is an framework that does the work of "object persistence". In other words, it's code you can use that takes care of saving a collection of objects to disk and loading them again later. It does a lot of work to allow you to store lots of data and load only the objects you need at a time, and unload ones when memory is tight.
Core Data can use a database to accomplish this, but that's it's business, not yours. When you use Core Data, it is a black box. You tell it to save the data and then step out of the way.
If you want to interact with an existing database, such as a MySQL database on a web server, that's a completely different matter. You might use Core Data to store local copies of objects on your device, but in that case Core Data won't care that the objects are copies from some other database. It doesn't care.
It is a convenient, native means of storing data in your iOS applications. Don't think of it as sqlite although you can view the files it creates with various sqlite tools. Instead think of it as a tool for manipulating an object graph of information important to your app.
I've used it in two main ways. First to store a bunch of static data that is important to an app, in one case that was a large amount of location data for an indoor mapping application. What arrived as a massive CSV file of waypoints was converted to core data. Core Data was incredibly useful for this because it allowed preparing a sqlite file which was shipped with the application containing all the infomation. Updates from a web service arrive as more CSV that is added to the Core Data to keep information current. At runtime the location information object (the waypoint a user is at) is retrieved with a predicate (i.e. the point they tapped on) and that object, through its Core Data relationships, indicates where it is possible to go from that point. Core Data provided the information necessary to perform A* routing through the indoor map.
Second it is great when you have a bunch of objects arriving as JSON and you want to be able to store and access those objects later. Let's say you have a typical app where you have a User and some information about the User, let's call it Thing. Users have Things. When you want to know something about a User you retrieve the Core Data record using a predicate - typically "name" or similar - and you get all the information you stored about the User back. Again you can make use of relationships to explore the user's connections and make displaying information easy. Perhaps the User has many Things, then you can say "user.things" and you get a NSSet of NSManagedObjects representing those Things.
You use it like a database. Its utility is that it is easy to access from anywhere in your iOS code, it is easy to store and easy to retrieve information also. Faulting lets you retrieve one object and navigate to any object connected through relationships by following the relationships. Because you define the attributes and relationships yourself in the data model editor it is easily customized for what you need to store. To me it is one of the most used and most useful parts of iOS.
When you want to automate display of information from Core Data you can use a NSFetchedResultsController to initiate a fetch and to respond through delegate methods to changes to the underlying data. If you set up a UITableView to use a NSFetchedResultsController as data source, you can have the table automatically update whenever the objects displayed in the cells changed. Very useful for apps where you periodically update information and want what is displayed to be kept current.
When your object model changes it is possible to maintain all of your existing information and migrate it to the new model. Core Data manages automatic (lightweight migration) when it can, or if you have made more radical changes you can supply rules to handle the migration.
The limitation of Core Data is that it is not great for storing binaries. If you have images that you need to store, far better to store a path to the location of the image than trying to store the actual data.
Yes, if you want a local database on your device, Core Data is the appropriate technology. It probably makes sense to start your research with the Core Data Programming Guide.
You can alternatively use SQLite (which Core Data uses in the backend), but Core Data offers some material advantages and is the preferred database interface for iOS. If you decide to pursue SQLite for any reason, though, I'd suggest you contemplate using the FMDB Objective-C SQLite wrapper.
But Core Data is generally the way to go.
I'm prototyping a simple sports sim game for iPhone which will use Core data.
One the biggest challenges I'm facing is how to get the data into Core data in the first place.
The second biggest challenge is whether I should use core data's persistent stores or use fixed files (JSON) for pre-fixed game data.
--
Concept
The general concept is that a player can start a new game or continue an existing one.
When they start new game they would use pre-fixed data. (IE. A database which is read-only.)
When they continue game they would use a different database (the game database).
I am not sure how to deliver such a feature.
--
Prototype
Currently, I am experimenting with this prototype:
PHP Web App -> 2. API -> 3. iPhone
A local PHP web app which acts as a CMS.
A basic API which lets me expose specific data in a JSON format.
Read the JSON into Core Data using TouchJSON/other tools.
I have no intention of making the API public/online (for various reasons), so the method I have described is a only meant to ever be a one-way process.
This will of course cause a problem because I need to make the data read-only.
--
In sports sim games you will often find them using fixed files (.txt, .csv, .dat, etc) and then they read this data into memory or a database.
Therefore, using this concept I could:
Save the JSON as fixed files and read them at run-time into memory/core data.
And then whenever the player starts a new game, the existing core data store will simply be wiped.
However, having said that I've heard that you can use persistent stores as a method to overcome this problem.
Therefore I was thinking of setting up 2 persistent stores;
1) A pre-fixed read-only persistent store
2) The actual game store (which gets overwritten if you start a new game).
But which is better?
Creating JSON fixed files for consumption, or using 2 persistent stores?
I apologize if my question/concept is overly complex; but would welcome better/simpler solutions where possible.
I think you can use Core Data for applications that is going to store data on it and the database is empty when it starts but if you needed you data store to be pre-populated with data it is better to load it from fixed data like sqlite or xml files.
In My application, how should i find meaning of the word, it should work both online and offline? Please help me out also is there any possiblilite to take local dictionary from iphone?
Sri
As far as I am currently aware, you aren't able to query the iPhone's built in dictionary.
Even if you could, I am not sure that it contains any definitions. Rather it looks for spelling correction on "close" words.
If you are wanting to replicate storing a dictionary inside your app, like the many dictionary apps currently out there, you would have to store the data in your iPhone app somehow.
Wikitionary provides free "dumps" of it's data which you could grab, and put into a form that would be usable in your app.
You would need to store the data in some form of plist, an SQLite database or CoreData.
For taking data from the internet, you would need to look at transferring the data using JSON, XML or PLIST.