Pretty new to iOS dev, I feel I have a grasp of the basics. I was thinking through an app I would like to make and the steps involved, components needed... and I have no idea how to or what is the best method to save user input and retrieve it.
An example being (I don't plan to make this, but it illustrates what I want to know), say a simple to-do list, it has NSTableView that is populated from NSMutuableArray, to begin with it is blank as the user has added nothing. Once an item is added to the array, table reloads thanks to -reloadData. The item that is needed to-do is shown in the table. Great for this session... but not when the app is reopened.
I imagine I need to store the array and then reload it when the app next initialises, is this correct?
Or is there any other better method?
If you're just starting out. The best way to go is to use Core Data to save and display your data. You'll thank me in the end.
http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP30001200-SW1
Tutorials
http://www.raywenderlich.com/934/core-data-tutorial-getting-started
http://developer.apple.com/cocoa/coredatatutorial/index.html
http://themikeswan.wordpress.com/2009/05/22/7/
Do a google search there are lots of resources.
In addition to Jordan's answer, mostly for completeness so you understand your options. You have at least another two options:
Serialization using NSCoding (Archives and Serializations Programming Guide
Property Lists (Property Lists Programming Guide)
Both these concepts are easier to understand than a proper relational database and are for simpler things worth considering. Especially since TODO lists are not likely to contain large amounts of data.
Property Lists is the easiest and most basic one in terms of functionality. It just lets you store primitives, but is good if your TODO list is just a collection of Strings.
Serilization using NSCoding is more powerful, but requires more work from the developer. With NSCoding you can create your own coders/decoders for your business objects that lets you persist the entire state. This would be good if you have your own Todo with a lot of properties, like title, priority, complete-by-date etc.
Related
I will make a simple game app which will store some data as user progresses in levels. For example: each level has a number of sub-levels, sub-level stores 3-4 properties (strings and arrays) depending on user's progress.
The app is simple and it is not a lot to store (about 150 levels and sub-levels maximum with small amount of data in each) and I do not want to make it complicated with multiple classes representing levels and sub-levels plus SQLLite database. I thought of a simpler approach but good enough to manage data through my GameManager singleton.
Recommend what approaches to look at for my needs to store and manage data for this type of an app. Perhaps one of these or something else:
NSUserDefaults + NSDictionary
CoreData + SQLLite
etc...
Just want to make sure I am not missing anything
It's much better and less painful for you to use core data. Why do you say sqlite?? Core Data is just saving your objects in a sqlite file on an iOs device and in xml in Cocoa app.
To use plist files is kind of strange, as I think. You can put into it only a simple array, and what if you want to display photos besides your simple array? The preferred way is core data - 50% less code, as apple says. Use NSFetchedResultsController and you'll be good!
Another widely used practice would be to store your information in a property list (.plist). NSDictionary and NSArray come equipped with the capability to load from as well as write to a property list.
Here's a resource which may be helpful to you: Property List Programming Guide
Take a look into core data. It seems very difficult once you get started. But once you get into it, it gets pretty straightforward from there. Check out this tutorial he helped me get going. Hth
In the iPhone app I am developing, I need to have a list of people which is stored.
So the user go into the 'People' view and there I want a table view which the user can edit by adding and removing people to their list. Each person will also need to have properties, such as first name, last name, age etc as some examples.
I am unsure of how to approach this as its my first time. My main curiosities are how to have a list of people and go to a view displaying that persons unique properties. How to have each entry/person have its own unique properties (which I can define) and how to save/load them. It of course has to be persistent, so when the application is quit the data stays when reloaded.
Obviously code samples help understanding a lot, but any pointing in the right direction is really appreciated, thanks.
Too broad to really answer, but here's some pointers:
Use Core Data for storage.
Create a Person class, with each person being an NSManagedObject with various properties like first name, last name and so on.
Use an NSFetchedResultsController to populate a TableView with your people.
CoreData is the way to go. I have found this tutorial particularly helpful when I was learning iOS and CoreData.
http://www.raywenderlich.com/934/core-data-tutorial-getting-started
But Apple Documentation is good as well.
https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html
Easiest: Use NSUserDefaults. Define a class "Person". Store instances of "Person" in an NSArray and save it in NSUserDefaults. It'll give you persistence but little else. If you have any search or data modification operations, you'll have to write your own code and it can become cumbersome pretty soon. For very simple apps only.
SQLite3: You'll need to know/learn about SQL a bit and also know how to design tables, but will keep your life simpler if you need to do sophisticated searches, etc.
Core Data: Apple's recommended solution to all your database needs. Highest learning curve, but simplifies many sophisticated tasks (undo operations, etc.). A good choice for 90% of the apps.
I am preparing an iPad app using, obviously, Objetive-C and wich tries to deploy Data Base stored content inside a view.
Now comes the problem, it will be a huge amount of records to be shown, each of them deployed inside some kind of "container" inside the view so that I was considering to make a page browser and in every page I go to change the view I apply.
Take for example, I show the first 5 items using example1.xib, for the next 5 example2.xip and so til getting to the page 10 and starting again with example1.xib.
My question is how this can be achieved? Maybe storing diferent view class based objects inside an array and alternating them or so...
Any help or hint would be greatly apreciated.
Cheers!
Always assume others have made similar apps before you. Perhaps not exactly the same ones as you, but doing similar things that you can learn from. The iPod and Spotify apps navigate large amounts of data using indexed, searchable TableViews. Go hunting on App Store for apps that have the same kind of functionality as yours, and test them out and grab what's good and discard what's bad about them.
My advice is to get hold of a nested tables example using the built in SQLite, and go from there. I've no idea what your database looks like, but with a bit of luck you could adapt example code and just open (a converted) SQL database.
Most users by now are used to the drill down paradigm rather than the paginated paradigm, so it's worth checking out the Drill Down example that comes with XCode even if it's not for databases (at least I don't think it is, I learned from a book, like Manuel.)
I would subclass UIViewController or UITableViewController depending on what type of records you plan on using.
I would recommend checking all the Apple's Examples, and most of the available online tutorial
Here are some, may be old though...
http://www.edumobile.org/iphone/iphone-programming-tutorials/tabbarcontroller-with-navigationcontroller-and-tableview-in-iphone/
http://www.aboveground.com/tutorials/adding-a-uitableview-to-a-custom-uiview
http://www.icodeblog.com/2008/08/08/iphone-programming-tutorial-populating-uitableview-with-an-nsarray/
http://blog.webscale.co.in/?p=150
http://www.ioschef.com/2011/03/un-aperitivo-de-uitableview-y-uitableviewcontroller/ in spanish..
http://adeem.me/blog/2009/05/19/iphone-programming-tutorial-part-1-uitableview-using-nsarray/ with videotutorial
I'm currently designing a restaurant based menu system of iPad with the basic functionality of being able to view items on the menu, then add them to an order, be able to review the order (with the possibility of removing them) then finalising a price and (time permitting) be able to email the order to a specific email address.
Currently I have a split table view with each section of the menu, pictures and text. I am at a roadblock where I can't see how I can proceed with the project.
Firstly, if I have an 'add to order button' underneath the item description, how can I create a new list (or order), how do I display it/edit it?
I'm really stuck as I see no logical way to do this.
Any help or pointers would be greatly appreciated.
I'm not sure of your mileage with the Cocoa APIs, but it sound like you are missing some fundamental knowledge about how to effectively work with them. Primarily, I am speaking about the contents of the Cocoa Fundamentals Guide, Model-View-Controller Design Pattern section.
To me, it sounds like you have made good progress on getting the view component of that design pattern, and you are at the point of fleshing out the model and the controller. If you don't understand the terminology, the model essentially encapsulates all of the objects that constitute the domain, which in your case is is "restaurant-based menu systems". Then, the controller piece is concerned with shuffling data from your model to your view and also other general application logic.
Without further requirements about what type of data your app should be concerned with, it's hard to advise you on what you need. You probably want a set of objects that align with the nouns (like Menu, MenuItem, Order, etc.). Then, those objects would have methods that determine how they interact with each other.
Lastly, the controllers (of which you should already have some in your project if you used the Xcode templates) should have a way to manipulate the aforementioned model objects and present the data. The list you mentioned could be something as simple as an Order object which has an NSArray of MenuItems that have been ordered.
So, ultimately my advice would be to read through the Model-View-Controller section in the Fundamentals guide and once you understand it, try creating a model that supports what it is you are trying to achieve. Diagrams or sketches that depict the objects and their interaction help with this. Then once you have done that, you can start to wire your model up with your interface in the controller. Hope this helps.
There are a few things you are asking here:
Adding an item to an order. This implies a purchase cart like solution. These can be quite complex. I'd start with a simple list (NSArray of item numbers?).
How to display this list. This would be the visual aspect of the cart. Just think of this as a menu table like you currently have, but with the cart array as a filter.
Emailing this information. This is surprisingly easy. Present a modal MFMailComposeViewController after adding a text version of your order as the messageBody.
A further idea would be to expand the cart to use menu item objects that you design in core data. You might also have luck hunting around for a library that encapsulates the needs of the cart for you.
Hope that helps.
In the development of my first serious iPhone application (Meaning I'd like to actually get it out on the AppStore), I needed a good way to represent my data. Instead of going with core data, I (stupidly, I think) decided to use classes to represent my data.
I created three classes, MMDot, MMShowMovement, and MMShow. The MMShowMovement holds instances of the MMDot class in an array, as the MMShow holds instances of MMShowMovement. Sounded like a nice way to do it, each class has a lot of logic that has to go with it, so I thought that classes seemed like a good way to go about representing all this data.
My question is, is there an easy way to save the instances of these classes so I can restore the data after the application is reopened? I have made applications on OS X using a NSKeyedArchiver, would it be similar on the iPhone? Would it be easier to start again using Core Data instead (These objects are very complex, especially MMDot with about 15 instance variables, now that I look at it, maybe not THAT complex)?
I'm really at a loss here.
You can absolutely use NSKeyedArchiver to persist your objects. I'm a fan of either method, the decision mostly lies with your application needs. I don't think it will be much work to re-model your objects in CoreData. Without knowing anything about your application I'd say if you are doing simple persistence with a simple model you may not need Core Data, if you have complex relationships and will be reading/persisting data frequently during an application session Core Data is probably the way to go.
If you have a lot of object instances, you are probably better off using Core Data - it will help cache things, help you with queries to get specific sets of objects, and so on. KeyArchiving is really a lot more useful if you are saving off a handful of instances, but have some downsides - in particular it's harder to track down memory leaks from Unarchived objects.
Core Data can also do paging of results for you too, so that you aren't fetching in the entre contents of a large array if you do not need it.
I was looking into serializing my classes the other day and went with using NSUserDefaults. I just give all the internals of my objects a unique key based on the object. Seemed to work fast for me.
Wrote a blog about it here: http://technolojiadev.blogspot.com/2009/12/serialize-this.html