I'm developing an iPhone application (well, I'm migrating a Windows Phone 7.1 to iPhone), and I have some questions:
Previously, I've asked this question, Storing data in XML or SQL?, when I was developing a Windows Phone 7.1 app. And now I have the same question, but in this case it is about iPhone.
I've found in iOS development, that XML is not as easy to read as in Windows Phone. In this question, Reading XML attributes and text, you can find what method I'm using to read a XML file.
I'm sure, I don't need to use a database to store only 22 items, but, is there any other way to store that 22 items? Or, maybe, you know an easy way to read XML.
I need something like this:
<?xml version="1.0" encoding="utf-8" ?>
<cards>
<card id ="0">
<name lang="en">Mad</name>
<description lang="en">This...</description>
</card>
...
</cards>
This data will be readonly: user will never change it. And it will be as file bundled with my app.
You haven't said how you are using this data.
Are you talking about simply bundling data with your application? If so, the simplest way of doing so is to use a property list (plist). Both NSArray and NSDictionary have convenience methods to pull arrays and dictionaries straight out of plists, and there is a graphical editor build into Xcode.
Are you loading this data over a web service? Do you have to support multiple platforms? If this is the case, then JSON would be a better option. JSON support was only included in iOS 5, but if you need to support earlier versions, JSONKit will handle this for you.
Do you have to update and run queries over the data? Core Data is a better option for this kind of thing. You can preload it with the contents of a plist or JSON file when the user first runs the application.
There are a lot of different options, and unless you provide more detail, it's difficult to give you good advice.
XML Parsing in Objective C isn't that challenging. Please see this example on Introduction to Tree-Based XML Programming Guide for Cocoa http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSXML_Concepts/NSXML.html#//apple_ref/doc/uid/TP40001263-SW1
I'm going ahead and using Core Data in my project even though I don't really have all that much to store. It's really not all that difficult, especially since you can choose Core Data as an option in a couple of the Apple templates. Inside the iOS developer library they also have a pretty good basic tutorial.
Core Data Starting Point
I guess the main difference between whether I would use the Plist or Core Data would be whether I expect my data to be static from compile time or to be updated by the user.
Plist files
Documentation: http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
Example: http://www.ifans.com/forums/showthread.php?t=64679
Related
I'm working on an iOS app that will need to save data onto files. I chose to go for a Document Based app, precisely an app based on a UIDocumentBrowserViewController so that I can easily save and load files from the system's Files app.
Since the data I need to save/load on a file is quite complex: big hierarchy of different objects, with meta-data, image files, etc. I'm wondering what is the best technology to use going forward.
I came across NSFileWrapperand its ability to save different files as one. And I could definitely use that. But I also saw UIManagedDocument and the ability to use Core Data in my project while maybe saving the content of the Core Data database (I know it's not quite a database, but you know what I mean) into a file that I could write somewhere in the File App.
Is this a behavior I can expect?
To reformulate: I'm wondering if I can read/write files through a UIDocumentBrowserViewController, with data described by a UIManagedDocument that works with Core Data.
Thank you in advance. 🙂
As you have discovered, UIManagedDocument is there for your kind of application. And it does feature methods to write and read additional content like the metadata or image files you have, within the document package.
That being said, I have never used UIManagedDocument, and have never seen it used by others. A quick search of GitHub finds only this one project with two contributors who wrote a wrapper around it in 2013. Also, there does not seem to be any sample code from Apple, and the remark in the the writeAdditionalContent(_:to:originalContentsURL:) documentation that Additional content is not supported on iCloud leaves me a little concerned, but maybe it's a good sign that the Core Data team knows where to draw the line.
I have used the macOS counterpart of UIManagedDocument, NSPersistentDocument. It is in a similar situation of not being used very much, but with many more known technical issues. So a few years ago I switched to BSManagedDocument, which purportedly mimics UIManagedDocument to support Core Data in all its modern glory. I have been happy with BSManagedDocument.
In summary, if I was in your situation, yes I would give UIManagedDocument a try. But don't be surprised if you need to use a DTS support incident or two during your development.
I'm working on a simple ResearchKit app that has 20 survey questions, or ORKSteps. How do I get the answers from a participant who submits the survey into a database?
My research has found ORKESerializer and SQLite as potential parts of the solution. I'm missing a big picture view of how these things can be integrated into a working solution.
Starting without knowledge of databases or data transfer from Swift, so any basic information would be very helpful.
How do I extract data from ORKResult using Swift?
Where do I extract the data to? Or, what's the standard type of database for a small survey?
ResearchKit doesn't have any out-of-the-box solution for storing your results. Generally, it's the task of the developer to go through the ORKResult hierarchy and either persist the processed results for later access or send them to a remote server.
You have several options here:
Use NSCoding to store the vanilla ORKTaskResult (with their ORKResult children). This way you can recreate the whole ORKTaskResult hierarchy at later time to inspect or process it.
Use ORKESerializer (as you guessed) to serialize ORKResults into the JSON format. ORKESerializer is currently included as part of ORKTest's unit tests, and it's not documented very well. It's possible that it will be moved to ResearchKit proper in the future, but it's completely usable right now. The JSON format is particularly useful if you want to send your results to any remote server of your own.
You can manually iterate through ORKResults and convert them into objects that are suitable for storing, or into database records. As you said, you could persist them using SQLite; or other database of your choice; or Core Data.
To sum up, there's no recommended or standard method for persisting results, it depends on your needs.
You can also have a look at the official open sourced RK apps. I think they make use of the AppCore library (which sits on top of the ResearchKit) to store the task results (and also use the Sage Bridge to send the results to Sage's servers). But that may be overboard if your needs are simpler.
I suggest that you run the sample ORKCatalog app and then inspect the ORKTaskResult hierarchy (you can do that within the app itself). You'll get an idea of how the result hierarchy looks.
I do not have experience with the Research Kit but as a database you could use sqlite. stephencelis has made a great wrapper for swift which you can use.
I'm trying to inch my way towards building a data collection app for a specific application. Eventually I want to have drop-down and manual text entries, building a dataset that I can export as a CSV and manipulate further in Excel.
I've used some apps like Fulcrum, but eventually I'd like to add some more functionality to the app. Basically I'm trying to figure out how these apps are storing the entered data, then pushing it to a server when internet access is available. What are some general options that I should explore to do this magic?
Thank you!
You can store data with Core Data, you can use the native API's and methods or external libraries which will make a lot easier all the work, such as Magical Record and more.
If you want native I recommend you AppCoda tutorials, you need to do a lot of research to start with core data.
And also you can use an external library to store this info into a server or in the cloud.
I've heard Parse is great.
Hope it helps.
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.
I'm building an iPhone app that is essentially a book, it will be bundled with a lot of text-heavy content.
I considered bundling the data as XML and load it when the application starts but the XML would contain a lot of nested structures and be a bit of a pain to parse.
Would it be better to use a plist? I'm concerned about memory usage and plists are loaded entirely into memory - can they be parsed in chunks? Is there a maximum size to a plist and how efficient are they?
I'm not sure how big the bundled content is going to be yet but I should imagine it could be anywhere from 500k to 4MB.
Property Lists are the native serialization format for anything derived from NSObject. There are some issues with mutable-state preservation, but overall plist is the format preferred by Apple.There are parsing methods available with NSData that abstract away the details of the mark-up. As for XML, you're burdened with the task of writing your own parser.
You can refer to this for further details.
It should be noted that a plist file itself is strict XML; in choosing plist, on the server-side you should be able to parse the plist XML and treat every two nodes as key-value pairs.
In my experience, plist is far easier for you to maintain and better in the long run. I have a similar situation and wrote an app that generates the data file my app reads using all of the same APIs with no extra setup. Its hitting the ground running (as long as you're familiar with Cocoa.)
Its even human readable with the property List Editor app included in the iPhone SDK. Although I don't recommend it for very large data structures by hand, that's why I mentioned how I built another app for that — the code generating the data and using it almost has a 1:1 comparison, they're that similar.
The plist editor does come in very handy to tweak an item or edit small-medium data and, once again, it hides the underlying XML.
If human-readability is a design goal, you should consider JSON. It's not the right answer for every application, but it bears considering. The open-source json-framework (here: http://code.google.com/p/json-framework/) is GREAT, and provides very convenient methods for encoding and decoding JSON strings to objects, as a category on NSString. So you can say:
NSString *jsonString = ...// however you're loading the goods
NSDictionary *myData = [jsonString JSONValue];
...and boom, you're working with native objects. For my money, that's even easier than reading a plist.
Why not ship the content as HTML? (Maybe split into chapters or some such)
That way you could immediately display it through a WebView without any parsing or reformatting.