Is this good programming pratice?

[Esko2300]

What i started doing is with view that would need to manipulate data in, i started placing an instance of the class or view controller in the next class, then i would use the assign property in order to change or manipulate any data from the previous class by just calling the object in the new class and changing the data accordingly. Ok so let me get to the example now.

NOTE:This is not exactly how the controllers work they are more complex in data and in operations im only trying to give a short example

heres view controller 1's header file that places another view upon it

 
@interface FirstView : UIViewController{
    SecondView *secondView;
    UILabel *label;
    
}
@property (nonatomic,retain) SecondView *secondView;
@property (nonatomic,retain) UIlabel *label;

;


now somewhere in the .m file for FirstView the user would press edit which would bring up another view with a textfield.

@interface SecondView : UIView{
    
    FirstView *firstView;
    UITextField *tf;
 }
-(void)updateLabel;
@property (assign) FirstView *firstView;
@property (nonatomic,retain) UItextField *tf;

;

I would then in the init method set the firstView variable to the previous view which is loading this view on the screen

now in the SecondViews.m file i would have a function like this

-(void)updateLabel{
      [firstView.label setText:tf.text];
      //do some functions that remove this screen
}

I would like any input some of you can give me on this like pro's con's of using this type of programming method. Or even a better option in trying to do the same functionality,
Thanks

[baja_yu]

You should never manipulate a view of one controller from another controller.

[Esko2300]

Originally Posted by baja_yu

You should never manipulate a view of one controller from another controller.

Its not another view controller its a view i lie upon the existing view controller thats another object of UIView.
I should have changed it in the second view .h file sorry

[Duncan C]

Originally Posted by Esko2300

Its not another view controller its a view i lie upon the existing view controller thats another object of UIView.
I should have changed it in the second view .h file sorry

Not true.

@interface SecondView : UIView{
    
    FirstView *firstView;
    UITextField *tf;
 }
-(void)updateLabel;
@property (assign) FirstView *firstView;
@property (nonatomic,retain) UItextField *tf;

In your secondView code, you have a line like this:

-(void)updateLabel{
[firstView.label setText:tf.text];
//do some functions that remove this screen
}

The method updateLabel is directly manipulating a label inside FirstView, which is a view controller. That is VERY, VERY BAD programming practice. Outside objects should never read or write data from a view controller's views directly.

Instead, create a string property (lets call it labelText) in firstView. From outside, change labelText string property. Then, inside first View, use the value of the string property to set the label.

Update the label's text immediately if the view is currently being displayed. If not, just save the new value, and assign it to your label your view controller's viewWillAppear method.

[Esko2300]

@Duncan

Ok so since your telling me i should just have a variable,in the FirstView called Label TExt, that i will change directly in the SecondView by assigning it the value from the textfield in the secondview. I think it would be better that i just create a method in the first view that takes in an nsstring and sets it to the label in the firstview.

so in my firstView.m ill have a method

- (void)updateCellText:(NSString*)text{
     label.text = text;
}

but i should call it from the variable i assigned the FirstViewController to in the SecondView like so

in my secondView.m

- (void)changeText{
      [firstView updateCellText: tf.text];
}

The point of me asking this was should i use the assign property when i need to do something like this. And from what i read you said that its pretty much ok to do this just dont manipulate any UI in another Viewcontroller. Am i putting the pieces together correctly?

[Duncan C]

Originally Posted by Esko2300

@Duncan

Ok so since your telling me i should just have a variable,in the FirstView called Label TExt, that i will change directly in the SecondView by assigning it the value from the textfield in the secondview. I think it would be better that i just create a method in the first view that takes in an nsstring and sets it to the label in the firstview.

so in my firstView.m ill have a method

- (void)updateCellText:(NSString*)text{
     label.text = text;
}

but i should call it from the variable i assigned the FirstViewController to in the SecondView like so

in my secondView.m

- (void)changeText{
      [firstView updateCellText: tf.text];
}

The point of me asking this was should i use the assign property when i need to do something like this. And from what i read you said that its pretty much ok to do this just dont manipulate any UI in another Viewcontroller. Am i putting the pieces together correctly?

You're on the right track.

However, you should be aware that unless a view controller is the front view controller, it's views may not exist at all. The outlets will be nil and the views won't be loaded until the first time the view controller has been loaded, and then the views can be unloaded again by the system at any time (if the view controller isn't the front view controller) to release memory.

Even if the label is loaded at the time you try to assign the text, it could get unloaded in the future if the system needs to free up memory. Saving data in UIView objects is not a good idea. Save the data in your model, and then PRESENT the data in your view objects.

Thus, you should not take the string that is passed to you and try to assign it to your label directly. Use a retained or copy property to store the value. Then assign it to the label in case the view is the front view.

Also assign the text to your label in your controller's viewWillAppear method. That way, when you display your view controller, the label will be set up with teh correct text.

[Esko2300]

Thanks i see what your getting at in my future programs ill try and do things differently. Right now this works and even though it aint the best its working as i need it too.

Another quick question though. The Model-View-Controller aspect of things.
Model would be the data with in the view i.e. all my strings, floats, ints ect.
The View would hold the UI variables.

But im not understanding the Controller aspect of it since when you create a new view controller it gives you a view and a controller. how are these separate from each other?

[Duncan C]

Originally Posted by Esko2300

Thanks i see what your getting at in my future programs ill try and do things differently. Right now this works and even though it aint the best its working as i need it too.

Another quick question though. The Model-View-Controller aspect of things.
Model would be the data with in the view i.e. all my strings, floats, ints ect.
The View would hold the UI variables.

But im not understanding the Controller aspect of it since when you create a new view controller it gives you a view and a controller. how are these separate from each other?

Your code has a latent bug if you are setting labels to a string and then forgetting about that value.

Consider this:

While View controller A is the front view controller, it invokes the setLabelString method in view controller b to pass a new string in.

View controller B obediently sets the label string, and it seems to work.

The user goes back to view controller b, and everything seems fine.

Then the user goes to view controller c and does something that needs more memory. The system triggers a low memory warning. View Controller C is the front view controller, so the views for view controller a and view controller B are released.

The next time you invoke view controller B, it will reload it's views from its nib file, and your label text will be lost.

You can trigger this bug at any time in the simulator by switching to a view controller other than view controller b and selecting "trigger memory warning" from the simulator's hardware menu.

[Esko2300]

Originally Posted by Duncan C

Your code has a latent bug if you are setting labels to a string and then forgetting about that value.

Consider this:

While View controller A is the front view controller, it invokes the setLabelString method in view controller b to pass a new string in.

View controller B obediently sets the label string, and it seems to work.

The user goes back to view controller b, and everything seems fine.

Then the user goes to view controller c and does something that needs more memory. The system triggers a low memory warning. View Controller C is the front view controller, so the views for view controller a and view controller B are released.

The next time you invoke view controller B, it will reload it's views from its nib file, and your label text will be lost.

You can trigger this bug at any time in the simulator by switching to a view controller other than view controller b and selecting "trigger memory warning" from the simulator's hardware menu.

OK i see it now. But in this situation its ok since ill never need to know the value of the string because it gets sent to the server. When i come back to this view i just grab a list of names from the server again, display it on the screen and the user can choose from a list of names.

and any input on the last question i posted? cause clarifying that up for me would be great.

[Duncan C]

Originally Posted by Esko2300

Another quick question though. The Model-View-Controller aspect of things.
Model would be the data with in the view i.e. all my strings, floats, ints ect.
The View would hold the UI variables.

But im not understanding the Controller aspect of it since when you create a new view controller it gives you a view and a controller. how are these separate from each other?

I didn't answer this part of your question.

In MVC, the model holds the data. The view is used for display, and the controller mediates between the two.

The view controller is the controller object. The view hierarchy of the display is the view. The model can be as simple as an array that's fed to a table view, or even NSString objects that hold the values displayed by the labels in your screens.

For simple projects, the line between model and controller can get blurry. That's not a big problem because the controller object is in charge, and manages how to store it's data. It pays, though, to remember what part of a controller object's data is really model data that needs to be saved.

The idea is that you always go to the controller object in order to make a change in an MVC "triad". The controller has the smarts to decide what to do with messages, when to flush data changes to disk, etc.

Trying to save data in your labels is using the view (UILabelView) to store data. That's bad. Storing data is the model's job.

Trying to change one view controller's label from another is bad, because you are bypassing the controller object. Again, the controller is the brains.

Consider this analogy: If I go into your desk calendar and add new entries, move appointments around, etc, but don't tell you about it, you're going to be confused, and might miss appointments as a result. The desk calendar is your model object, and you are the controller. Or lets say I'm the ad agency for your company, and I decide to completely change around your ad campaign. Different slogan, different logo, and airing your ads in different markets. Again, I don't tell you. Your ad campaign is your business' view. It's the visible part of your business. If I change your ads without consulting you (the controller) then the view might not reflect what's really going on in your business.

[Esko2300]

Short wrap up of what you said. The model = data. The View = The layout of the screen. And the View Controller controls everything. So the View controller should have objects of each model and view objects that correlate with each other. One view controller can have 5 model objects and 5 view objects,which is how apples intended it to be, where all their UI interactions and changes in the data between these objects are controlled by the view controller