How-To Use Global Variables With The AppDelegate For IPhone And IPad Apps

Now open the view controller, klCViewController implementation file and in the viewDidLoad method, add the following as in listing 3 to assign the value from the gvar the first UITextField. The two method of importance in the listing 5 code that we will need are the viewDidLoad and the viewWillDisappear. The first will display the value of the gvar when the view is loaded. AppDelegate as you must do in the first view controller. The second will grab the any input from the UITextField from the second view controller before it is removed from the stack. The viewWillUnload will update the gvar when the view is unloaded when the user clicks on the back button. The output is displayed in the three following screenshots, Figure 2, 3 margin:0px ! Sign in or sign up and post using a HubPages Network account. Post CommentNo HTML is allowed in comments, but URLs will be hyperlinked.

Comments are not for promoting your articles or other sites. Sorry for the late reply. If you still need my two cents, I would say that yes this technique would work any number of VCs. If not (since I haven't tried it), maybe you could consider using a plist to maintain the values between VCs since this is another technique for data persistence. I created a counter on a single VC. Do you think this method will work if I wanted to use this counter to work across 5 VC with segues, Example: VC 1 has a UIAction button of plus 1 (no text fields) and when clicked adds it to a UILabel-outlet on VC5. I've been searching for a way to make this work by capturing all clicked buttons from 4VCs to last VC. Works fine on one VC. You can change the value of gvar as needed, you just don't need to create a new instance. Thanks for this Tut. It is helping me somewhat.

One thing I confused about. Why is gvar value "Hello" again after returning from the 2nd VC, while gvar was set to a new value in 1st VC. Cool, I will check it out. Good point about the event triggers. I will keep in mind. As for ARC, yes can opt out of it as needed. I didn't know you could selectively opt in and out on the same project, good to know. I rewrote the data model for my app moving data from the views to the app which made your article very relevant. Most of my KVO broke in the process. It was somewhat painful to fix, but now memory management and caching is twice as efficient, so worth the effort. I think your point about backwards compatibility is an important one, though I've never believed it should be at the expense of progress. MFC. MS were terrible at breaking apps with new frameworks so I can relate to iOS developers grief.

I was under the impression you could opt not to use ARC. The project I'm working on ATM uses some JSON classes that don't support ARC, even though my project does. The mixture seems fine; just opting not to compile the JSON classes with ARC. The change of view behaviour is alarming. That said, once you understand the new model it's quite good. My current app allows endless reclusion of views to deep dive into data. A very helpful function available within ViewWillDisappear, is determining which way your view is travelling. TRUE the view is popping off the stack. This in turn allows you to pop your active data member off your own stack. I might start a hub about it to explain the model as I'm sure others would fine it very useful. Just to touch on one other point worth noting about the new viewModel. When the app loses focus, viewWillAppear is how you can kick off new actions that need to happen when your app gets focus again.

On the whole, it's worth considering moving what you would have had in ViewDidLoad to ViewWillAppear. Thanks for your comments and thoughts. They are very refreshing. But I hope my tutorial wasn't the reason for your bad weekend or lost of hair. You offer some very interesting points and you are stating a blaring point about application development: data should never be part of the views. There should be a clear separation between the Model and the View. OS 5 has introduced many changes to the way we are supposed to write code and create apps, for instance ARC. I am sure that Apple, like many other software companies, has good reason to force us into a new direction, but it should never be to the point of breaking our code. A case in point is IBM. Apple and others should keep this in mind when introducing changes when developers have invested several thousand hours developing apps and helping Apple make billions. You are write about the viewWillDisappear. This article brings about an interesting concept that caused me to lose an entire weekend and several tuffs of hair.