I am new to iOS app development. I have been reading the documentation on the Apple Developer website as well as reading references on the Internet and I still can't seem to find anything that explains how to separate content from the app such that the content itself is easy to update. The open source iOS examples I have seen all hardcode content into implementation files. Although I have read up on Core Data, I'm not sure if that is the most approriate framework to use for my use case. I want to make a basic app that simply contains lots of views with each view containing various types of UI elements as those seen in HTML for example H1, H2, H3, P, UL and IMG. With Core Data, I'm assuming I would have to somehow save my data(content) into a SQLite database file and then get the app to read it, would this not be tedious? How would I then update the SQLite database in addition to populating it in the first place?
To reiterate I simply want to know, what's the best way to achieve this and still be able to update content relatively easy without having to go to a file that has the content hardcoded.
Many Thanks
easier way is to fit them inside plist files, then read them as NSDictionaries
please read Plist Array to NSDictionary
and Parse Plist (NSString) into NSDictionary for more information
Related
Alrighty,
I am new to Xcode so I apologise if I am missing any key points here.
But, I want to have a large list in a UITableView type display. The list will be an array of strings with maybe 500 ish entries and a search bar to search for what ever entry you like. Once found you can tap the entry and it will load a detailed view of what ever it is. I would prefer to not have to have all of the data entry in Xcode and am wondering what would be the neatest way to store/read/write this?
I am leaning towards some sort of data file... but couldnt quite work out how to implement this into Xcode. I have searched around a bit but couldnt find anything which made sense (probably because i am quite new to Xcode).
This will be an App for iOS.
Any ideas?
I understand that you want to create a UITableView displaying static data and your problem is that you don't want to store the data in your code. Depending on how complicated the structure of your data is you could save it in a sql database, store it with coredata, keep it in a xml file or keep it in a file in a custom encoding. I don't quite now where your Problem lies. You can just load the file/database, parse it in an object structure and display it in the tableview. There are a couple of advantages of using a database to a file:
You can create connections easily and handle them without a lot of effort
You only need to load in the memory what is really needed at the moment.
Core data will be fine for you. However if you don't need all of its extra functions and the list will be static (eg, non changing and will be read into the code at runtime in its entirerty) then you can probably use a plist. Plist data can be read directly into arrays.
I am making a simple iPhone app that will basically be an editor.
As such, I need some way to store the documents the user creates.
Since on iPhone, the concept of the filesystem is not present for the user, I searched around to see what I should use.
I found this question & answer that basically says to use Core Data, but I recently found out about NSFileManager.
My question simply is, for user-created documents, what is the best storage system to use? Traditional files by using NSFileManager? Core Data? Something else?
Personally, I would use CoreData because it will abstract away all of the file-management code for you. If you are making simple text documents then this isn't such a big deal, but if you are working with a complex document architecture (i.e., a collection a numerous objects) then it can save you a lot of effort.
If the user wants to export their document it is very easy to write a function to do so with your CoreData objects.
The only downside to CoreData is that if you are using non-standard attributes it can get a little bit tricky, but it is certainly not a deal breaker in most cases.
People create document formats without CoreData all of the time, so there are plenty of examples out there, and it will just come down to personal preference. There really isn't any generalized right answer to this - it a design decision that should be evaluated on a per-app basis.
If all of your data for displaying the file is contained in one long string (like HTML) then I would recommend that you use the file manager, since it will be easy to get a list of files in a certain directory to display to the user for opening. However, if they are not self contained (like NSAttributedString, which has many stored formatting regions along with the actual content) then you should use CoreData, as it will be easier to keep all the pieces together.
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
I am writing an iPad app that will be expandable with new items via in-app purchasing. For example, my current plan is to have a jpg pattern and a matching plist file with the parameters I need to expand that pattern into a full picture.
The user will select one jpg/png from a list of small thumbnails - the list is held in Core Data - and the app will find the matching plist for displaying the jpg/png correctly. I'll only have about 10 of these open at one time. But I could end up with storing 1000s of jpgs and plists.
Does storage of lots of small files cause app problems?
I'm going the plist way, rather than storing the parameters in Core Data, so that if I need to add parameters later, I don't have to migrate the database, just change the access in code. (And when I'm creating the patterns, it's easier to concentrate on a plist file rather than a Core Data row.)
The app seems to work really well at the moment, but I'm worried about futures...
My app does also use Core Data for other things, so I could change over if the app will get bogged down with number of files.
Thanks.
Saving a large number of small files is not a problem as long as you have a well thought out means of naming and tracking the files.
Remember that the user does not have the same flexibility and ease of file management on a mobile as they do on non-mobile platforms. Designs that work on non-mobiles are unworkable on a device used on the move with one finger.
However, when you say:
And when I'm creating the patterns,
it's easier to concentrate on a plist
file rather than a Core Data row.
... the use of "row" suggest that you haven't fully grasped Core Data's utility. Core Data doesn't use rows, columns, tables or joins. It's an object graph management system that sometimes uses SQL way behind the scenes.
Core Data is designed to handle data in a way that meshes seamlessly with the rest of the object oriented API for the UI and other services. When you use other data management systems like plist, you will most likely end up manually duplicating a lot of Core Data's functionality anyway.
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.