I'm a new developer. Recently, I'm developing a note app on iPhone with Evernote API. I have read many pdf, such as Document-based application.pdf, evernote-api.pdf and so on. But all these do is teach me how to sync with Evernote and how to design the document class. No one talks about local store mechanism.
I have designed a local store mechanism by myself; here it is:
Store all notebook/tag info in a plist file, such as which note in which notebook, which note has which tag, all of notebook/tag/note is represented by unique guid in plist.
Store each note content in their own file, with the note guid as their file name. That means however many notes the user creates, there will be the same number file on disk.
How about this local store mechanism? Is it good or bad? Any suggestion is welcome.
What's more, should I use Core Data (database) in my project?
And how can I sync with Evernote?
The most popular way to do it is to use CoreData framework. It makes easy way to store different values of your Data Model in sqlite file in local storage of device. Look at this tutorial from apple.
You have a valid approach. I think it's especially good, if you expect big document lengths. If you only expect short notes, you can use any of these: coredata, nsuserdefaults, basic nscoded arrays, textfiles, etc.
Related
I am developing an iOS notes app where a user can add image, text, audio and drawing notes. I want to implement iCloud synchronization between multiple devices. Out of the 3 options (key value, document storage, CloudKit) which one should I choose? I would like to implement the sharing of notes (collaboration) among users as well. I am using core data as my DB currently.
Key-value storage is out of question due do being too limited for your goal, document storage is only recommended when you need to handle and store the document as a whole. Since you are already using CoreData for local storage, it only makes sense to use regular CloudKit with it for cloud storage and sharing.
Synchronisation of CoreData and CloudKit can be tough. I am personally using a combo of RxCoreData and RxCloudKit libraries which provide some relief in synchronisation and some syntax sugar too.
A word in advance about uniqueness constraints: for CoreData, you define them based on key(s) or hash of all values, for CloudKit it is only possible (and also required) for the CKRecord key, to the best of my knowledge. So it is best to take care of it from the very start.
IMHO, CloudKit is the only opinion :)
I have a note app named marknote. And at the beginning I used iCloud document storage. It worked sometime, but not stable. The worst thing is, when and whether your documents can be synced is out of your control, instead it relies on Apple's daemon service. It becomes even worse when your documents are a little big, for instance several mega bytes.
So after fighting for some time, I changed to CloudKit. As #maxim-volgin has already pointed out, the implementation of CloudKit sync is tough, but it is reliable. And all headache just gone after switching to CloudKit.
when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.
How do you decide whats the best for your project?
(Only talking about data management)
For Example if you want to develop:
Time Tracker App > Is PList your choice?
RSS Reader App > CoreData?
Photo App > sqlite?
EMail Client > ?
For a beginner can you point me roughly to proper directions?
(I know it depends a lot on the App and what you like to do with
it but any thought will help)
I'm far away from developing complicated apps, they are still pretty simple.
Thanks for help,
Marc
You can use these rules of thumb to decide what storage model will work for your app.
If the data fits in memory entirely and is relatively unstructured, use plist
If the data fits in memory entirely and has tree-like structure, use XML
If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
If the data must be secret (e.g. a password), use keychain.
Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.
There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.
My rule of thumb for each of those would be:
Time Tracker App > Core Data
RSS Reader App > Core Data
Photo App > Core Data
EMail Client > Core Data
Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.
At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.
The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?
I have an array of integers that I'm using in an iOS app which is liable to change. Instead of updating the app each time the integers change, is there a way I can store the array online and access it within the app?
Where would I be able to store the information and what is the mechanism used to retrieve it in iOS?
CloudKit will probably work, but it seems like overkill, especially if the dataset isn't per-user. If don't mind paying for the backend, Amazon AWS can provide a place to host the dataset for use in your app.
You could try Parse heres a tutorial on how to set it up, https://parse.com/docs/ios_guide#top/iOS.
You can have the data served by any web server in the world. Then you can query it, either using the standard NSURL* family (and then parsing the contents, depending on the chosen format), or using libraries such as RestKit that will do both at once.
I need to store data that the user can add, they can add an unlimited amount. They can either be NSStrings or UIImages. I have looked into NSUserDefaults but it seems that it is used for small amounts of data such as settings or preferences.
What would be the best/most secure way to store the users information so that when they close the app it is still in the app. The data populates a UITableView and is a NSMutableArray.
Whats the best way to do this?
There must be a dozen ways to store user data in iOS. Here are several:
Property lists: An easy way to store a graph of common data storage objects and containers. This is a good place to start if you're just learning the iOS ropes.
NSKeyedArchiver and NSKeyedUnarchiver: Provides an easy way to serialize and deserialize your objects to/from a chunk of data, which you can then write/read using NSData's methods.
NSFileHandle: Read and write data in whatever format you like using a nice Objective-C API. More generally, you should read up on the iOS file system.
UIDocument: A full-featured starting point for managing user data, including syncing with iCloud.
Keychain: Not a general purpose data storage mechanism, but if you're storing sensitive items like passwords, credit card numbers, etc., you should use the keychain API.
POSIX file API: Good old C file handles with the read and write functions you learned in college, if you went to college before Java was a thing.
SQLite: According to the web site: "SQLite is the most widely deployed SQL database engine in the world."
Core Data: A powerful (but also somewhat complex object graph manager. This is a good choice if you have many different pieces of related data to store.
What would be the best/most secure way to store the users information
so that when they close the app it is still in the app. The data
populates a UITableView and is a NSMutableArray.
Best is subjective -- you'll need to consider your needs and look at the various options. For many people, though, best means least painful or easiest to learn. As mentioned above, property lists may be the way to go in that case. If your array contains simple data (strings, data, dates, numbers) in standard containers (arrays or dictionaries), your file I/O can be as simple as something like this:
// writing
[myArray writeToFile:somePath atomically:YES];
// reading
myArray = [[NSArray arrayWithContentsOfFile:somePath] mutableCopy];
You should use Core Data. There is a very good, free beginners course online avaibable called cs193p, see here http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/287, it is also available through iTunes U. It's really worth the time to watch and easy understandable.
If you have only some array you can check plist. is verry simple and powerful.
https://developer.apple.com/library/iOs/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
This is a great resources: Should I use NSUserDefaults or a plist to store data?
I have a basic question regarding populating Core Data with data. I am building an application, which will show ATMs on a map. I would like to ship the application with a preloaded database, but to give users the option to receive updates when they launch the app. I am thinking about using a property list for the update. Basically send a plist of all the ATMs, parse that plist and populate the sqlite. I will have around 7000 entries in the property list file, each entry containing 5-6 keys with short string values. But according to the Apple iOS Developer Library:
You can create a property list—or some other file-based
representation—of the data, and store it as an application resource.
When you want to use it, you must open the file and parse the
representation to create managed objects. You should not use this
technique on iOS, and only if absolutely necessary on Mac OS X.
Parsing a file to create a store incurs unnecessary overhead. It is
much better to create a Core Data store yourself offline and use it
directly in your application.
Should I still be sending a property list or rather think for an alternative solution to update the application's database?
P.S. I am thinking about using a Rails app for providing updates - basically sending a plist file.
I had nearly the same question a few months back, did quite a bit of searching to find a nice easy answer, failed to find it and eventually settled on a roll-your-own solution that took a bit more time than I would have hoped, but was at least very helpful in learning to understand Core Data.
Basically the solution was to write a little utility that parsed my source data (which for me is a comma-separated text file, parsed using the quite handy 'cCSVParse' library - http://michael.stapelberg.de/cCSVParse ) and inserted it into Core Data Managed Objects and then saved that off as a sqlite persistent store. Then the sqlite store(s) can be shipped with the app, and uploaded by the user when they buy more data.
You could write a conversion from plist (or whatever) into the core data representation within the app itself, but if the data is just going live out the rest of its days in some core data form, why not let your beefy dev box do the heavy lifting before you send the data to the user, instead of shipping the data to the phone and making it do the work?