Pasing variables between views

I would use delegates in one class that can be accessed by both.

 

Are you currently able to navigate between all views controllers? What have you learned in regards to properties or memory management.

This isn't necessarily what you're looking for.

 

That post is nearly 5 years old (Jun 2006). Just sayin'.

One reason for the difference is the separation into Model, View, and Controller. I have completely changed the views in nibs with no change at all to the code, not even recompiling it. I have completely changed the code in controllers and models with no change at all to the views. I have copied code and views and reused them without change in multiple projects.

I don't know what the unit of modularity is in VB, but in Xcode the units are separate: the unit for views is a nib (or subviews of a nib), while the unit for code is an @interface header. Two separate units, which can be combined, reused, changed, and altered separately. It may make one-off programs harder, but I think it makes long-term programming easier.

 

Maybe you can rephrase the question as a more general one. Instead of "How do I pass variables between views?" you should ask "How do I pass variables between classes?" Or since you'll really be passing variables between instances of classes (i.e. objects), "How do I pass variables between instances of different classes?".

If you know how to make or use classes at all, then it shouldn't be hard to come up with examples of passing variables between instances of different classes. It happens all the time. If some class has an ivar that's an NSMutableArray, then every time you send objectAtIndex: to the array, you're passing a variable (the index number) to the object of the other class (the array). The value returned is passed back as the return-value of the method.

Next, how do you write a new class that does these two things:
1. Accept objects passed to it as method parameters.
2. Return objects as method return-values.

What if the object passed as a method parameter has properties of its own, and those are what the receiving object is interested in? For example, suppose a method is interested only in the longest and shortest NSString. That's the length method of NSString. How would you write code to access the length? Or suppose the receiver is counting how many strings have different first characters? How would you write code to access the first character in the string?

 

While a few of those steps are no longer needed in fact there more steps that you need to do now to set up an outlet, on iOS anyway. Create the @property, @synthesize, add code to viewDidUnload, add code to dealloc.

It is in fact something of a mess.

On the one hand you get a lot of power but there's also a lot of responsibility to manage things that could be done better by the framework and the tools.

 

Remember that Objective C is a clean superset of ANSI C, and some consider C to be not much more that a macro-assembly language for DEC minicomputers. If you can't figure out how to pass variables using MVC OOP and well structured code, you could always use all global variables and goto statements and get the job done with a sledgehammer.

Because Microsoft making it so easy in Visual Studio led to a proliferation of the types of apps that caused the PocketPC and Windows Mobile to be such a huge success compared to the iPhone OS?

But I think the tools could be intentionally complicated. It's Apple's IQ test to make sure that Mac applications and now iPhone apps are only written by people who can actually read the documentation and remember a bunch of details.

 

I would have to say passing data between views is if not easier than passing data between forms. It's a heck of a lot easier to maintain. Don't skip the basics. VB is easier in the sense you can just skip the basic and copy and paste your way to an application.

 

He was answering your implicit question:

And doing an excellent job at that.

 

The suggestions about global variables and goto statements are more helpful than you think. It's what the Objective C compiler sometimes turns your code into anyway. So it's better to know what's actually happening "under the hood".