I'm trying to design how to implement a relatively simple application.
I want to create a grid of 'squares' that cover an entire screen. Each square should have the ability to respond to touch events, and then have an on/off state. For example, if I touch an 'off' square, and then drag my finger across 10 other squares, I want them all to turn on. And vice versa.
I'm not sure of the memory overhead of just creating a grid of 150 buttons. Also buttons don't have a settable state, from what I can see. I was also thinking of subclassing UIView and implementing UIResponder methods. It feels like I should be creating an array of array of buttons (or subclass of UIViews), but I'm not sure if that's possible.
I'm assuming that I can tell what square I'm on by getting the location of the touchevent from the UIResponder methods. Do I need to create my own version of a myButton by subclassing UIView, and have a on/off state property, along with UIResponder methods, and then create an array of myButtons?
UISwitch is the only thing that does this at the moment, though some have had good experiences using the UISegmentedControl for this as well.
Beyond that, you'll have to change the style/color of a regular button or image in code, which is what a lot of application developers do so it looks and reacts exactly the way they want it to.
Unless you need more of UIView's event handling stuff, you'll get the best performance if you use a single view and give it a -touchesBegan:withEvent, -touchesMoved, and -touchesEnded methods. Then use a custom drawRect method to draw your individual squares in either on or off states. You could also use layers, but trying to lay out 150 views is asking for trouble.
Related
In the app, I have several images (same shape and size, different colors) that move on the perimeter of a circle, kinda like cursors acting as compass needles. I want to be able to tap each of these and then display a message based on which one is tapped, but am not sure what kind of approach would be good for this. Right now I'm trying making them in to UIButtons, but it's giving me a lot of hassle. Is there a way to do this with a UITapGestureRecognizer? I doubt it's possible to have one of those on the screen, but have it keep track of 6 different moving areas and let other tap events through, and I don't think adding 6 different recognizers is a good idea, so I'm just wondering if anyone has suggestions on how to go about this. I'm using Core Graphics.
The best method to achieve this effect would probably be to subclass a UIButton (or even UIControl if you'd like) that has the method that overrides touch. For example if you were to subclass UIControl you could override the method below to detect touches and do what you wish with them:
-(BOOL)beginTrackingWithTouch:(UITouch *)touch withEvent:(UIEvent *)event
Then whatever you want it to look like could be done in the drawRect: method by overriding that (and uncommenting it). Same goes for subclassing anything and tracking touches within the subclass: UIButton, UIImageView, UIControl, etc.
I'm trying to avoid putting a button in my UITableViewCell subclass so that I don't unnecessarily lag up the scrolling speed.
The button would push another view onto the navigation stack.
I figured since UITableView already has built-in and optimized methods for managing this, that simply limiting the touchable area of my cells would be the easiest and most effective way of achieving my goal.
I really have no idea how I would implement something like this. I have a feeling I would have to override pointInside:withEvent: or hitTest:withEvent:, but I'm not sure how. Managing touchEvents and the UIResponder stuff still escapes me.
So my question is ultimately, in my rootViewController, how would I implement that selecting a row will only work at lets say 220,10,40,40 ?
Thanks!
A UITableViewCell should have a normal selection style(i.e. not UITableViewCellSelectionStyleNone), generally speaking. You shouldn't have buttons on cells that you are reusing an arbitrary number of times.
If you're using a lot of UIButtons in your UITableView, you may want to rethink how your UI is designed.
You can't easily (to my knowledge) change "selectable" parts of a cell - the whole cell must be selectable no matter what(you can set the style to no selection, but you'll still recieve touch updates).
The behavior you're describing sounds like a job for UITableViewCellAccessoryDetailDisclosureButton, actually. If you're going to be pushing another view onto the stack but don't want to do that when the user selects the cell proper, use a detail disclosure button to maximize your consistency with existing UI convention. It's hard to say without more information.
As for doing the work necessary to detect touches in a sub-region, that may be more trouble than it's worth. True, adding subviews to a cell incurs a compositing cost but if you're only talking about one button, and a button whose background you can set to opaque, you'll probably be just fine. The alternative is reinventing the wheel to recreate button behavior in a subregion of the cell and that doesn't sound like functionality that will be much fun to maintain as the SDK matures.
That said, adding views to a cell doesn't incur a compositing cost per se, it's drawing those views that's the trouble. So if you really wanted to go nuts on the optimization, you could create a pre-rendered cell background image that includes the appearance of a button you want and then place a custom, image-free, see-through UIButton instance right over top of it. Nothing to draw, so no additional compositing cost. Worth a shot.
You didn't come here for a premature optimization speech, so I won't bother with one, but I say just do the cell with a normal button for now, make sure you like how the functionality feels to use then optimize toward the end if you're looking at performance that you're not happy with.
I created a minesweeper clone game and I made a 30 x 30 grid of cells. Now in my initialize design, I planned to use UIButton for each cell so that I can use its touchDown and touchUpInside. But my problem is using UIButton makes the game slow in zooming and especially in loading or adding each cell(900 pcs) in a UIView.
Now I'm planning to use images instead of UIButton and I heard about CALayer for easy animation. Can you suggest how can I use this CALayer for my implementation or replacement of UIButton?
Thanks.
I'd certainly suggest going down the Core Animation route for this. You can use an NSView subclass to recieve and handle the touch events then you could then use the location of the touch to calculate the cell that's been hit and update your model appropriately.
You arrange CALayers in a heirarchy so - whilst the complexity of the tree of views will depend on other UI elements you wish to have - you'll have a CALayer containing the 900 sub layers.
Using Core Animation will also allow you to get wizzy with animations.
It's going to be a bit more complex, but you just need to bite the bullet and get stuck into the Core Animation documentation and/or buy a book.
Good luck.
Edit: Ivan suggests using the hitTest message. This way you can get the layers to tell you which one of them was hit. Using that is obviously quite nice. However if you're looking for speed it might be quicker to avoid that and just work it out. This does make assumptions about how your game works (i.e. the buttons/cells don't move location). If you get the chance try both and let us know how it works out. :o)
On Cocoa desktop, there's NSCell, which is a lightweight alternative to NSButton, but that's an older technology before CALayer and Core Animation (they don't conflicts with each other)
To make custom button, create a custom class either extends to delegates CALayer. Then to know which button is clicked, use [hitTest] method which will return the layer being clicked efficiently.
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
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.
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.
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.
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.
alt text http://www.davidhomes.net/question.gif
I'm farily new to iphone dev (<3 months on my free time) and I'm starting development of my second app.
From the image, I'm adding a number of UIViews as subviews to my main UIViewController.view, the number of Views to add varies based on user selectable data.
Each view contains several controls, a label, a UITextField and a Horizontal UIViewPicker.
For simplicity I put a (VERY ROUGH) mock-up here with only two buttons.
Because I want to improve the GUI, I want to overlay an UIViewImage as the top sub-views of the added UIView, something like in the image.
The question is on passing through the events to the objects below it. I've read somewhere that one way was to use clipping, but the actual shape is more complex than just an oval frame.
Somewhere else I read that one could add four UIImages, one at each border, which would let the events pass through this hole. Seems like a dirty solution to me (Although I'm sure it would work)
Any ideas about the best way to do this? Any links to a tutorial or recipe online?
Your help is appreciated
thanks
david
Have you looked at protocols? You can define protocols for your views or objects, and the users of that object (the subviews underneath for example) can implement the protocol, set itself as the objects delegate and when actions happen they will notified through the protocols. So for example
An AboveView will declare a protocol that declares methods when a certain gesture was senced by that view so something like
-(void)didMakeCircleGesture...
as a property the underneathview will have a delegate, so in your method that actually sence the gesture youll have at the end something like
[delegate didMakeCircleGesture];
in turn the delegate is the view underneath or something, and it will conform to the protocol defined by the AboveView, and as part of it it will have to declare the method didMakeCircleGesture, so as a result when one makes a circle gesture in the AboveView the underneath view that conformed to the protocol will be told of the event and it can take appropriate action