I've got a pretty basic question concerning iOS apps: How do you get large amounts of data into an app? I know about plists which is they way I import data. But it is tedious to create these plists (I use excel and smultron to do that - is there a better tool to do this) and I believe not very efficient for very large data sets.
Once the data is loaded I use it in the app (and could possibly feed it into a core data db).
Secondly, I was wondering what would be a good set up architecture-wise to load the data. Currently I am doing that in each viewcontroller that I use. But I guess that can be done more efficiently and centrally. E.g. by having one class that loads all the data - DataLoaderClass - (or on request if data is not always required). However, that would imply that I would need properties for each set of data for each viewcontroller. It would be much easier if I could just declare some global variables that can be accessed by each viewcontroller but are filled by the DataLoaderClass.
Any advice or key concepts that I should look up?
Thanks for answering these newbie questions - which are nonetheless of fundamental importance to me.
You can create a massive .xls file using Excel, then import it using DHlibxls. Or you could use make a cvs file.
What i do when i have large data sets is i write a small OSX app that saves it all to a core data store. I then export this store into my app and use it as my core data store in the app.I would recommend Core Data.
Related
So i'm following the ios tutorial here
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/SecondiOSAppTutorial/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011318-CH1-SW1
The data for the tableview is a custom class containing just strings and dates.
Here is what it looks like
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/SecondiOSAppTutorial/DesigningDataModel/DesigningDataModel.html
Can anyone suggest how to save this to data between launches of the app?
What about making the app Document based .. i.e. using UIDocument?
You could use NSCoding to store such simple data. You could probably even use NSUserDefaults but I wouldn't recommend it. Core Data is really the way to go unless you know you'll never need anything slightly more complex.
Check out this guide on how to persist simple data using NSCoding from www.raywenderlich.com - a really good tutorial site for people beginning iOS development.
You could use NSCoding or NSUserDefaults.
But for any real application that has a lot more than sample data you'll be looking at something like Core Data eventually.
From your comments I see that you think it's overkill for just a couple of fields. However, this is an ideal time to learn about and practice setting up a Core Data model and connecting it to a table view with a Fetched results controller.
I'm writing an iOS applications that saves Music albums(just an exercise I'm doing for the fun of it) .
For every Album there's a singer, song names, time, and a picture
The final result will be a lot of objects with a lot of details including a picture attached to every object. Should I even consider doing something like that with plist? (can pictures be stored in a plist?)
What's the best way to save and access that data?
I'm new to iOS and from the training videos I've seen Core Data is not recommend for the beginner user. Is that really the case?
If I'm going with plist, should I create one plist for every genre for example rap.plist , rock.plist etc' or just a big data.plist?
Thanks
I would go for core data. If you choose the right template when you create your new project in xcode then reduce the once-off overhead work significantly.
With that simple structure I would say that the templates provides nearly everything you need. Just define your model and layout and off you go.
There is just the images where I would spend a bit more time in thinking it over. I personally never put the image data into core data itself. I rather stored them as file and within my core data model I just stored the path and filename to access it. As file name I simply used a timestamp. You could use some auto-increment or other unique id technique but a time stamp would do as well. It will not be visible to the user anyway.
I think the best way you can do this, since you are new to IOS is by using sqlite. Save all the information you want in your local database and display it on the screen.
You can use plist if you have data structure that is small.
Note that property lists should be used for data that consists primarily
of strings and numbers. They are very inefficient when used with large blocks
of binary data. A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory.
With Sqlite you will easily be able delete , edit, insert your data into the database.
Core data also uses sqlite for data storage only it helps you to manage your data objects, their relationships and dependencies with minimal code.
And since your are new getting started with core data would not be such a good idea i think.. so i would suggest start off with normal sqlite. Save the data in one of your folders of your app and store their path in the database.
You dont have to write different plists.. You can use the same one if you are using.
EDIT : here is a link that will help you with learning sqlite
http://www.iosdevelopment.be/sqlite-tutorial/
you need some more code to set up the core data stack (the store coordinator, the store, the object model, and a context)
it is a tad more complicated but that shouldnt scare you off.
Reading a plist is indeed dead easy but while good for smaller data (like the info.plist) it doesnt scale and soon you need a fullblown DB
As you edited your original question an decided to go with plist now.
In that case I would go for one plist per ablum and one overall plist for the list of albums.
You could, of course, use more plists for categories etc.
However, if you are thinking of data structures like categories you are far better off with core data. Especially when it comes to searching.
No one seems to be mentioning SQLLite, I would go that way and for reasons that I explain here ( https://stackoverflow.com/a/12619813/1104563 ). Hope this helps!
coredata is a apple provided persistant tool, while plist is XML file. The reason why core data is not recommended for beginner, I think, is core data is more difficult than plist from programming perspective. For your application, obviously core data is more suitable. But alternatively, you may also use archive file, that's between core data and plist.
I would like to know what I have to think about in order to download an SQL DB into core data? I am not sure what frameworks I would have to use or if there are any particular requirements when formatting the SQL DB.
Any help, suggestions, links to tutorials would be hugely appreciated.. I have done some searching around and its just hard to make sense of things because I am not sure if what I am looking for is even correct.
Im not sure if I understand what you are after, but maybe 2 links would be helpful:
an application that lets you load you data to a Sqlite DB from a lots of formats (Excel, xml, ...) is Navicat. It's an easy way of getting data to the DB. As David H mentioned, you could then work with the data without using Core Data via an Sqlite wrapper like FMDB. Then you can access the data with SQL commands.
A totally different tutorial is offered by nsscreencst.com: Importing into Core Data is a tutorial that shows how you can import JSON data to Core Data from a web API. This might be related to your use case. Unfortunately the videos there cost $9/month, but IMHO they are doing a terrific job.
(I'm not affiliated with either of the above companies)
This is just not possible - even though Core Data can use SQLite for storage there is no import/export. You really have two options:
1) If you have one database you want to use Core Data with within an iOS app, then you can write a really simple Mac App that interacts with your SQL store, and essentially replicates it in Core Data using a Core Data Schema you create based on your SQL database. The advantage of this is that is simpler to test and develop using a mac app. The final Core Data repository can then be used by your iOS app (by including the Core Data Schema with it).
2) Do all the import in your iOS app. This may take longer to develop but you can then dynamically download the SQL database into the phone and use SQLite to read it.
To import your data you have to create NSManagedObjects objects from every single record in your SQLite database. Depending on the complexity of your database model this can be very tricky.
There is a good introduction by Marcus Zarra on how to create NSManagedObjects from JSON: https://stackoverflow.com/a/2363996/480069. This should give you an idea on how to start. As Marcus said be aware of the relationships in your object graph so you don't end up in a loop when having complex relationships.
There are also a lot of good tutorials out there how to serialize NSManagedObjects, so just give Google a try: NSManagedObject serialize.
I'm currently looking for the best way to save data in my iPhone application; data that will persist between opening and closing of the application. I've looked into archiving using a NSKeyedArchiver and I have been successful in making it work. However, I've noticed that if I try to save multiple objects, they keep getting overwritten every time I save. (Essentially, the user will be able to create a list of things he/she wants, save the list, create a few more lists, save them all, then be able to go back and select any of those lists to load at a future date.)
I've heard about SQLite, Core Data, or using .plists to store multiple arrays of data that will persist over time. Could someone point me in the best direction to save my data? Thanks!
Core Data is very powerful and easy to use once you get over the initial learning curve. here's a good tutorial to get you started - clicky
As an easy and powerful alternative to CoreData, look into ActiveRecord for Objective-C. https://github.com/aptiva/activerecord
I'd go with NSKeyedArchiver. Sounds like the problem is you're not organizing your graph properly.
You technically have a list of lists, but you're only saving the inner-nested list.
You should be added the list to a "super" list, and then archiving the super-list.
CoreData / SQL seems a bit much from what you described.
Also you can try this framework. It's very simple and easy to use.
It's based on ActiveRecord pattern and allow to use migrations, relationships, validations, and more.
It use sqlite3 only, without CoreData, but you don't need to use raw sql or create tables manually.
Just describe your iActiveRecord and enjoy.
You want to check out this tutorial by Ray Wenderlich on Getting started with CoreData. Its short and goes over the basics of CoreData.
Essentially you only want to look at plists if you have a small amount of data to store. A simple list of settings or preferences. Anything larger than that and it breaks down specifically around performance. There is a great video on iTunesU where the developers at LinkedIn describe their performance metrics between plists and CoreData.
Archiving works, but is going to be a lot of work to store and retrieve your data, as well as put the performance challenge on your back. So I wouldn't go there. I would use CoreData. Its extremely simple to get started with and if you understand the objects in this stack overflow question then you know everything you need to get going.
I'm studying using Core Data.
After I create the entity in Xcode, I want to insert some data, which is master data, what is the common way or should I say best-practice to achieve this?
I googled a little and found out where the real sqlite file that generated by xcode located. It looks like /Users/<Username>/Library/Application Support/iPhone Simulator/User/Application/<Application GUID>/Documents/<database name.sqlite>
Now I'm wondering if I edit the sqlite (just to insert data) file directly is a proper way?
If what you mean is a preset database setup for all new database instances, there's a couple of ways to do this.
Programmatically , you can insert Entities into the managedObjectContext with a bunch of code. This will get be slightly painful for anything other than a fairly trivial dataset but the advantage is that you can use all of NSPersistantDocument for virtually free.
Use your app to create the dataset and then save it in the apps bundle as a read-only copy which you can clone as needed when a user creates a new database. A bit messier if you are using the NSPersistantDocument architecture.
Do what you said in the first place . Use an sqlite3 client to inject data into the database to create a read-only copy like 2, but the risk is that there is more to the database structure that CoreData inserts which you dont know about so you might put a bit of work in to find that CoreData cannot read the db after you mess with it in sqlite3. I haven't tried but it might work.
IMHO 1 is the best practice as you get a bunch of free behavior from NSPersistantDocument
The only sane way to populate a data set into a Core Data sqlite store is programatically.
For iPhone apps, it's common for people to write small OS X apps to generate sqlite files, which can then be added to the app bundle.
The Core Data sqlite store is complex, and Apple officially considers it an opaque data store. Attempting to modify or create data in the store manually is likely to cause data corruption. Don't do it.