I have a question regarding best practices when adding targets to a UIButton on a custom view. Currently, I create my UIButton in a loadup method of my view, and assign my view as the buttons target. My view is handling logic when the button is pressed, and it occurs to me that this is not good MVC.
So, I'd rather have my controller provide itself as target and an action for the button, however I'm not sure the best way to accomplish this.
The view could be initialized with a reference to the controller, or could get the controller using UIResponder's nextresponder, and set the target with this reference. However, this could result in circular retains, and would require my view to be aware of the methods that exist on my controller, which is more tightly coupled than I'd prefer.
Alternatively, I could create a setter for each uibutton on my view. However, this quickly becomes unwieldy if I have several buttons, or a view that contains a custom subview with buttons. I could also create properties for each button, but that would also be unwieldy and allows the controller access to more than it needs (it just needs to set targets, it doesn't need to be able to get any reference to the button).
Finally, I could create and add targets to all my buttons within the controller, and pass it to the view on initialization, but that seems to violate the roles of MVC as well.
It seems as if this is a common scenario, are any of these practices considered standard, or is there a better solution?
My personal belief is that in Cocoa custom views are allowed to have logic and state needed for them to operate, but that they should fully encapsulate the logic and state. That is, you should expose an interface to subviews, but not the subviews themselves. You should expose any private properties or subviews through a combination of delegates and properties as well as custom actions.
That being said, given that you provided no specifics on the purpose of your custom view, it is difficult to provide specifics on the best approach.
It's proper to target the view that owns the buttons. This way, if you need to do any view manipulation (enable/disable, highlight, popup, etc) you're in the right place. Also, only the view will know what the button is, so that, in your action, if you want to check what is sender, you can do it. But having your controller know about each individual button would seem to be a more egregious violation of MVC.
It's not inappropriate to have an accessor for your buttons. It can be handy to have the reference around at runtime. If you don't use it, it's hard to argue that there's harm in keeping around an extra id. As for hiding them in a private interface, that's fine, but unless you're publishing your API or working with morons, I don't know what harm there is in making the accessors public.
It's proper for your view to have a weak reference to your controller, and the button actions can be as simple as invoking one of your controller's methods. It's no big deal, and if you want to add some logic a little later, there's a spot for it.
Sounds like you're doing fine.
PS This is stupid:
Related
I am making an app that has about 20 different view controllers that are loaded into a single container view. Some of the views have sliders and buttons and some have only buttons.
Is there a strategy I can use to make building the views controllers more inline with Objective C coding techniques?
Currently I am trying to combine similar methods into model objects but before I get too involved I thought I'd ask if there is a better way. I'm also willing to do the groundwork and research so any keywords to point me in the right direction would help, i.e. protocols, delegates, etc.
The main piece of advice I'd give you is to consider whether or not each one of those view objects needs to be controlled at all. Consider UIViewController like the delegate between the view and the model. If you don't need an extreme context switch (i.e. pushing a new view onto the navigation stack), then is it really advisable to have 20 delegates floating around? In most cases, not really. UIViewController is not a "heavy object" by any stretch of the imagination, but it can quickly make your codebase unwieldy and large if every time you decide to throw a new component onto the screen, you subclass UIViewController.
Try to focus your attention on dividing the logic to setup the view and the actual responsibilities of the controller (reacting to model changes, dispatching operations, updating the view) into a UIView subclass and a UIViewController subclass respectively. If you truly do need to keep some component of the view separate because its logic simply cannot fit under the main view controller's category of responsibilities, then, and only then, is a new view controller appropriate.
I have an iPad project I'm working on that dynamically creates a number of buttons that I need to add to the main view of my application. I was planning on firing a method that lives inside my View from my ViewController...say it's called add_buttons. It's my impression that in the MVC pattern, the view should handle the rendering of buttons and the general display, but the controller should handle the interaction. I'm also under the impression that it's bad design for the view to "know" about the view controller.
So I guess my question is, should I have my button tap logic contained in my controller? If so, how do I handle the separation? If I'm creating the buttons in my view, then it would have to have a reference to the view controller to use as the delegate for the event handler. If I create them in the controller, then I feel like I need to set certain UI elements in the controller which seems wrong to me. I know I'm missing something obvious but searching so far has proven fruitless.
Can anyone point me in the right direction?
The button tap logic most certainly belongs in the controller.
The code that creates the buttons probably belongs in the controller too. However, it would make sense to include a view method that returns a button with its appearance configured but not its behaviour.
Some general pointe:
View controllers and their view are very tightly coupled.
If in doubt it's best to put the code in the view controller.
A views interface should deal with primitive data types (e.g. strings, numbers, images). Views should not need to know the specifics of model objects.
Also, the naming convention for methods lowerCamelCase. Eg:add_button should be addButton.
when you add button to view,
[myButton addTarget:nil action:#selector(myButtonPressed) forControlEvents:UIControlEventTouchUpInside];
in view controller add
-(void)myButtonPressed {
}
with target:nil event will be handled by first controller containing this view
I rescently finished a project where I had to dynamically create UIViews which contained both UITextfields and UILabels.My approach to this problem was to call the "addViews" function from within the view controller. I figured this to be a better and easier approach rather than dealing with view controllers from inside the UIView. I have tested my approach and works completely fine (dynamically change UIView size and adding other UIViews with a UITextfield and a UILabel).
I am writing a fairly complex iPad app - my first bigger one.
This app has some custom UIViews that present fairly complex data, including a table. These views do not take up the whole screen, and there can (and likely will) be many of them on screen at any time (though only one would be in an "expanded" state where the table is shown).
Here's a basic example that should convey the basic principle:
Please note that these things are not supposed to be in popovers; instead, the FamilyViews expand to show their detailed data. (And please also note that this mockup was only created for the sake of this question and has little to do with how my interface is going to look; I know this is not good screen design)
I'm undecided on who to put as the delegate and datasource of these custom views:
Making the ViewController for the current screen delegate and datasource is unelegant, because it's not just one table that's part of the VC's main view.
Making the View itself the delegate and datasource seems a bit weird to me because it feels like giving the view too active a role; making it into a half-controller.
Making the underlying model object the datasource seems too tightly coupled, and also breaks MVC. And it doesn't answer the question of who should be the delegate.
I'm tending towards making each of these "FamilyViews" delegate and datasource for their own tables. Action on these tables will have to be coupled to the FamilyView's delegate (the ViewController), but that shouldn't be a problem, should it?
Anyone have some input on this?
Views should know how to paint themselves and layout their sub views, depending on their properties, and that's it.
You definitely should let a controller class be the delegate instead of the view itself.
The delegate controller doesn't have to be the view controller that displays the view, though. It could easily be a completely separate controller class that only knows how to handle what the view requires.
I am making a UIView-based class for use as a tableHeaderView. It will have several controls that will be based on edit mode - some will appear/disappear and some will change appearance when it switches modes. The height of the view itself will change when it switches modes. Seeing that the layout will change a lot, I decided it would be better to just make the whole thing programmatically than to try to lay it out in a nib.
What I am struggling with is where the view/controller separation should be. Should the viewcontroller have an object for each control (UITextField, UISegmentedControl, UIButton, etc) or should it just have an instance of my UIView-based class?
Where should the code that actually creates the controls and sets the properties reside? Should my view have a method that gets called to set the entire view (based on edit mode) or does this put too much power in the view that should be in the controller? Should the view only set the positions of the controls? Or should there not even be a UIView-based class - the view controller will declare and configure all the controls by itself?
What is the proper MVC separation here?
jorj
The MVC rule of thumb is that your controller is the go-between – if your model is storing information about the edit mode, then your code will be cleaner if the controller does the work. If the edit mode settings are discarded when the view goes away, then the controller doesn't need to know about them.
It's also worth considering whether this code will be re-used – if you're creating a view that you're going to use again elsewhere, that may make it easier to decide where the "brains" of the code should reside.
Specifically, I have something like a game, with a menu screen made out of standard components. I want a button to switch to another view controller that the user will interact with for a while, then return to the menu screen. It seems like having the menu controller present the 'game' mode as a modal view controller is the most straightforward solution, but is this the best way to essentially replace the entire view? Is the whole menu (which may later become a deep nav or split controller) kept in memory as long as the modal controller is in front, and is this something I should bother to worry about?
There are really two parts to this question:
Which method of transitioning from one view to the next in an iPad application provides the best experience to the user?
Which method of transitioning from one view to the next is easiest to implement and best handles memory management?
I'm not going to try to address the first part of this question other than to point you to Apple's 'iPad Human Interface Guidelines' which says (among other things):
Reduce Full-Screen Transitions
Closely associate visual transitions with the content that’s changing. Instead of swapping in a whole new screen when some embedded information changes, try to update only the areas of the user interface that need it. As a general rule, prefer transitioning individual views and objects, not the screen. In most cases, flipping the entire screen is not recommended.
When you perform fewer full-screen transitions, your application has greater visual stability, which helps people keep track of where they are in their task. You can use UI elements such as split view and popover to lessen the need for full-screen transitions.
http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html
However, in your case I'd have thought a full-screen transition is entirely appropriate (but then I'm not a user experience expert).
In answer to the second part, yes displaying a new view controller modally seems like a good approach to take.
By default both the objects used by the menu view and those used by the modal view will be kept in memory - but the great thing about using UIViewController sub-classes is that they've got some default memory management built-in. If your application receives a memory warning whilst the modal view is being presented in full-screen mode, the menu view controller's views will be removed and it's 'viewDidUnload' method will be called. So in your implementation of this method you should release any objects you don't need and then recreate them as needed in the menu view controller's viewDidLoad method (which will be called again before the menu view is shown).
This is explained in more detail in the UIViewController class reference:
When a low-memory warning occurs, the UIViewController class purges its views if it knows it can reload or recreate them again later. If this happens, it also calls the viewDidUnload method to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded with the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. Typically, if your view controller contains outlets (properties or raw variables that contain the IBOutlet keyword), you should use the viewDidUnload method to relinquish ownership of those outlets or any other view-related data that you no longer need.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html