I am developing an iOS app that is a calculator to keep track of a score of a certain game. The game has many view controllers. I am going to create a "Player" object and create 4 instances of that player. Now in terms of Objective-C, how would I keep those instances alive between several view controllers? Should I for example, create an array of players and keep passing the array from one VC to another as the view progresses?
Thank you,
using singleton class , you will get the anywhere the same object. you need not to create each and every time. it create once and you use the app whole.
You can create the 4 instances in AppDelegate.
Then these 4 instances will be accessible by all view controller using shared AppDelegate object.
Let me know in case of any difficulty.
Cheers.
Just a quick thought, Passing array of Players can resolve your problem. But quickest way to share objects between view controllers is through using Application Delegate as you can simply access application delegate anywhere.
you can use of ApplicationDelegate to store your progress. when you move to another view at that time update your ApplicationDelegate variable in - (void) viewWillDisappear:(BOOL)animated method and at another view in viewLoad method get the updated value from the delegate variable.
Related
I have a general working knowledge of object-oriented programming and I'm currently trying to create an interactive novel program in Objective C using Xcode 4.2 with storyboarding.
I have a storyController class that instantiates the page objects and a viewController class that needs to display the pages. My fundamental question is the best approach for my storyController to tell the viewController to update it's text to display that of the new page object. My instinct tells me that my storyController needs to call a method on the viewController and pass it a page object. However, I'm not sure how to reference the view controller since it seems to be automatically created and linked by the storyboard (I don't see the viewController instantiated in the appDelegate).
I've read this post: http://www.iphonedevsdk.com/forum/iphone-sdk-development/54859-sharing-data-between-view-controllers-other-objects.html and it seems to address the issue. I could make a shared object on my appDelegate and use KVN or NSNotification to tell the view controller to check it.
I've also been reading about delegates and protocols as possible solutions.
So considering these potentially different approaches, which would be best to tell my viewController to update itself and pass it an object that contains the updates?
I would suggest looking at the UIPageViewController class, which probably will do a lot of the heavy lifting work for you, depending on the specifics of your app. This class is essentially a controller class that contains multiple viewControllers. Each managed viewController becomes essentially a "page" in your book.
Here is a tutorial using UIPageViewController.
If this approach won't work for your app, I'd still suggest using a separate viewController instance for each "page" of your book and handle the transition between the pages with segues.
Is it possible to communicate with a viewcontroller after a segue switched to another viewcontroller?
I want to know, because I need data from a viewcontroller passed on to the next viewcontroller,
but I just can't figure out how to get data from one viewcontroller to another, as they have no unique names or something which I can use to communicate with.
So can someone tell me:
If it is possible to communicate between viewcontrollers, and if possible, how?
Usually you do it the other way around, pushing values from the source to the destination. If you implement prepareForSegue in the view controller that is going to be segue'd out, you can use
[segue destinationViewController]
to get a reference to the destination view controller.
Then you can set any values in that controller that are needed using properties on that controller before it segues in.
I have searched for tutorials about making a MVC based iPhone app, but without success
Goto ITunesU and look for Paul Hegartys "iPad and iPhone Application DEvelopment" from stanford university
very good!
try the views presentingViewController property.
A typical OOP pattern is to create yet another object, a Model object (MVC paradigm), connect all the view controllers that need to communicate with this Model object, and pass any shared state or variables by setting and getting properties in this Model object. A common shortcut for very small apps is to use the App Delegate as a Model object, as any other controller can get a reference to the app delegate. But this shortcut is not very extensible to larger or reusable code.
In my iPhone app, the user will be making multiple NSStrings. Once these are made, I need to pass them to another view completely in the app. How can i do this? All I know at the moment os I can't access objects or variables declared in one view, in another. Thanks.
One way would be to follow the MVC (model view controller) design pattern. Whichever controllers are responsible for your respective views can then store and retrieve the NSStrings from/to a common data model object.
As to how you can make the strings stored in an object visible to the outside, the easiest way is to use Objective-C properties to save you from writing the accessor methods yourself.
I hope this helps with your problem or at least gets you started in the right direction.
Place the strings in a data model object (the M of the MVC pattern), with accessor methods (getter and setters, which can be automagicly created by properties). Then create and place that model object in some central location, a controller common to all views requiring that data, or the appDelegate, a reference for which can be found from any view.
Josh,
I would add to the MVC thing, that still you can do this in several ways.
What I would do for example, is to make your other "View Controller" (MVC), to "observe" when does the user create a new string, and to fetch it accordingly. In that way you would reduce coupling and it will be a cleaner implementation.
Another way would be to create a "delegate" so that the First View controller, "notifies" or calls the delegate method that you created, each time the user creates a new string ( again reducing coupling )
I´m trying to use Interface Builder (IB) to gain time in my app development. So I´m trying to do new things, for example, connecting objects between File´s Owners and Controllers.
The situation is:
1 - I have a ViewController with a Nib. This view controller have an array set as a IBOutlet.
2 - I put a custom TableViewController inside the Nib. Inside this TableViewController I set another IBOutlet Array, that I want to put as cell values (I will do this inside my TableViewController.m).
3 - The quesntion is, is possible to connect the two IBOutlets Array? Or to create something like a "IBInlet"..? Or in Interface Builder you can just use the IBOutlets as connections to the Library Objects of Cocoa Touch..?
Thanks for everyone..!
First off, I think it's unclear if you're trying to have two pointers to the same Array object or if you actually want to have two Array objects which you keep in sync. The latter makes little sense as it will just double your memory usage with no benefit, so let's assume you just want to have two pointers to the same Array object.
IB will help you link a data structure (your Array object) to a compatible interface widget, but it's still up to you to initialize your data structures in your code. Following that line of thinking, you can use IB to link your Array in the appropriate controller to the widget which you manage in that controller. Independently from that you can have one controller initialize the object and the other controller can get a pointer to that object from the first controller. Just make sure you manage your retains correctly ;)
I am developing an iPhone app for some sweet undergrad research I've been working on. Sadly, my school doesn't offer software engineering / design classes so when it comes to questions of best practices in OO Design, I do a lot of reading.
My Dilemma:
My application loads a view (v1) where, upon user's button click, v1's controller class executes an action method. This action method should fill an array with objects. After that, the user will either execute the action again or click a different tab to load another view. Other views in the application will use the array that v1 populated.
So, where should this shared array be declared? Right now, it's in the AppDelegate class from when I was testing features without a GUI. Should I grab the AppDelegate singleton and add items to it in the v1ViewController? Should it be declared as static?
Thanks for the help!
^Buffalo
EDIT:
Follow-up Question: When interacting with a singleton, which is the better way to talk to it:
[[MyAwesomeSingleton sharedInstance] gimmeSomePizza];
or
MySingleton *s = [MySingleton sharedInstance];
[s gimmeSomePizza];
I guess what I'm wondering is, do you make the sharedInstance method call every time or do you define a pointer to the sharedInstance and then reference the pointer?
Using the app delegate to store data that's shared between views and view controllers is reasonable and appropriate.
In my apps, I view the app delegate as the controller part of MVC, with UIViews and view controllers all being part of the "view". I prefer to use a variant of MVC called Passive View that keeps the model and view parts of my app strictly segregated with only the controller connecting them.
I'm assuming that the array of objects you're storing is your app's model, so storing them on your app delegate makes sense. As Daniel D said, there's no need to make it static.
The app delegate is really the heart of your program. You create and initialize your model and views in your -applicationDidFinishLaunching: method and save your model data and view state in -applicationWillTerminate:. When your view controllers receive events that changes your model, you can call methods on your app delegate to make those changes.
You could store it in an ivar in the app delegate. You don't need to make it static since the app delegate is a singleton anyways (there's never more than 1 instance).
If the app delegate is getting a bit complicated, you can factor out the data storage into a separate model object or perhaps use Core Data.