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.
Related
I am creating an iPhone application I need
tableview with rows and column
and fetch the rows and column data from mysql database
Please help me out. Thanks
First of all if you target iOS 6 or later then you should use UICollectionView for this purpose. It looks like a simple grid and much easier to manage than UITableView with 'rows and columns'.
Answering your second question then you might look into Core Data, simplifying definition - its entity based database engine built on SQL(in most cases).
There is complete tutorial how to combine em.
Hope it helps.
As standard iOS doesn't support tables with columns although (as #Mehdzor says) UICollectionView sort of does this.
To be honest if you can't make UITableView fit your needs then you are probably going to have to either design your own table or use a third party framework. Apple have done this when they developed Numbers for iOS but you have to be careful when you are working with small screens.
For your second question CoreData is brilliant. I use it myself for several projects and it is really easy to use. It really comes into its own when you get to synchronising devices via iCloud (a really, really, really difficult thing to do from scratch).
The only downside to CoreData is that it is controlled entirely by the Apple framework. As such you cannot easily port your app onto other systems. Other alternatives are things like Parse, or (if cloud synchronisation isn't necessary) you can control your own databases using the sqlite3 library. Although sqlite3 for Apple is written in C, it's not bad to use once you get your head round it.
EDIT: If your mySQL database is on a server then you could just use web services to query your database and let the server side logic do the actual work.
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'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.
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 am pulling data from an API and then building out my data objects with it. I want to cache this data for the future. I have been storing the string from the api in NSUserDefaults and then re-parsing it each time the app loads. This works, but it really seems like the wrong way to go about it.
How can I do this?
Have you noticed the NSCache?
An NSCache object is a mutable collection that stores key-value pairs, similar to an NSDictionary object. The NSCache class provides a programmatic interface to adding and removing objects and setting eviction policies based on the total cost and number of objects in the cache...
Personally I'm quite fond of the EGOCache classes, I use them quite a lot in my projects:
https://github.com/enormego/EGOCache
The classes are easy to use, I used to have my own classes with a similar design, but these are just more well-rounded, so I decided to stick with them (don't wanna reinvent the wheel).
There are many different solutions to this problem and there is no "right" way to do it. A few popular options are:
Core Data - Apple's framework for persistence. Very performant, but more difficult.
SQLite - Fast and flexible, but bare bones.
Plists - Basically writing a file to disk, you have to read and write manually.
NSUserDefaults - The lightest weight "key-value" option.
I would encourage you to read up on all four and see which one works best for you.
I vote Core Data
What type of data? If its text/string bases SQLLite would probably be the best.
I'd store the computed/parsed data in either a Core Data store, or in NSData flat files in your application's Documents directory. You're correct that storing that in NSUserDefaults and then re parsing feels a little overkill.