views:

360

answers:

4

I'm having my first foray into Cocoa Touch programming (and one of my first into Cocoa in general) and writing a simple game for the iPhone, though this question is about cocoa touch in general.

The main UI consists of a strip of identical acting buttons (only varying in colour) arranged horizontally across the screen. Although they act like buttons they need to have a custom drawn appearance. Each responds to touch events in the same way, triggering other events in the application.

I want to define a custom view, partly to have more control over the behaviour than just having a bunch of standard buttons, and partly to learn more about cocoa programming.

  • Should I define a main view with an array of subviews each of which draws itself and forwards touch events? Each button should do standard things like show a pressed state when touched and so on. Are there any pre-existing container views for this kind of scenario?

  • Or should I just define one main view which draws the whole strip and detects where a touch occurs? I feel this is a badly engineered approach - I shouldn't be programming hit test code.


Edited to clarify the question

A: 

You can layout your view in Interface Builder. Simply drag a bunch of UIButtons in your view controller's view.

To respond to events, you define an IBAction in your view controller and connect the buttons to it.

This is all very basic. I really suggest that you at least walk through the iPhone programming introduction that Apple has online. It will teach you iPhone and Interface Builder basics.

St3fan
I realise of course that I can just drag some UIButtons onto my view, but that's not what I'm asking - I want to create a custom view so I can have control over the drawing of the buttons, add more buttons to the strip programatically, reuse the view and so on. I'm also using it to learn more about cocoa touch and working with custom views and controllers.
Mark Pim
+1  A: 

You should use an array of subviews - that way each "button" class knows how to draw itself and its superview (your stated "main view") places the buttons where they need to go.

And second on the NDA: just talk about the iPhone.

CajunLuke
+1  A: 

If you have a lot of buttons and want to do fancy things with them, I recommend using layers. Your UIView will handle interpreting which layer had the touch (hit testing) and respond appropriately. If all you're doing is managing a whole bunch of buttons with various effects and animations, this might be an easier route.

As for bad engineering, not at all. If you take a look at the associated guides, you'll see core animation and layers does require hit testing (though that's relatively easy), but it's far cleaner than the UIView doing all the drawing and more efficient than many subviews. It slips right between those two approaches nicely.

Full disclosure: I'm just wrapping my head around how to best leverage this stuff myself, but for more complicated interactive controls.

Joshua Nozzi
+1  A: 

The more lightweight approach is to add sublayers to your UIView's layer. Use hitTest: to dispatch touches you receive on you UIView to the CALayer instance that needs to receive it.

If you need more of the UIResponder behavior (touchesBegan etc.), you might want to go with subviews instead of sublayers as that would allow you to handle the events directly in the objects rather than having to dispatch them from a central responder (your main UIView).

Consequently, the essential bit may be just how much of the behavior associated with your individual buttons should be known (handled) by the your main UIView. If it makes sense to have everything controlled from a central place, you can put all the logic in the UIView and just use sublayers for lightweight display purposes. If it makes more sense to put the behavior into the buttons themselves, they shoudl be UIResponders and as such subclass UIView and be added as subviews of your main view.

VoidPointer