I've got a question about the Model View Controller (MVC) design pattern for iphone games.
Let's say I have a simple game that uses a ViewController. So this view controller has an associated window/view and takes player inputs of buttons sliders, etc.. on this view.
Now I also have a subview of the ViewController's main window/view and I actually do some animation of various polygons in this subview. I also want to take touch events in this subview.
My question is, in the subview, I've got all the user touch code and animation code as the player's touch input affects the animation directly changing rotation etc.. There's a lot of variables in my subview class.
Am I violating the MVC design? Should I delegate this stuff to another class or the view controller?
Many thanks
It depends on what you're trying to accomplish.
Let's assume you want your game to run on an ordinary PC, as well as the iPhone.
Obviously, you'd want to isolate all of the code specific to the iPhone, which includes the touches. I'm assuming you'd want the animation on both versions of your game, so that would be part of the controller, or perhaps the model. Rendering the animation would be part of the view.
The easiest way to determine which functions belong in the view, and which functions belong in the controller, is to imagine porting your application to two different viewers. It doesn't have to be a PC and an iPhone. It can be Android and an iPhone. :-)
Related
I've written a small multiplayer game for the iphone. Once one of the players win, I want to display him 'You Win' image and a button so that he can play again.
How can this be done? One option is to use a segue to a new view-controller, but I think this should be shown with the game in the background. What would you suggest, as I'm pretty sure this is a common scenario for an iphone game/app.
EDIT: I ended up using both Phillip Mills's answer and Selkie's answer. Here is on How to Use UIView transitionWithView?
You can create the custom view and keep it as a separate property within your main game view controller. When someone wins, add it as a subview to the view property of the controller. It can be full screen size with transparency so that it's effectively modal, yet shows the game as background.
You can make it as a view, then show it using UIView animateWithDuration:(NSTimeInterval)duration animations:(void (^)(void))animations
The animation block could be sliding up, fading or whatever you want.
The other way is to add it at the beginning, but set its hidden property as YES. Change it to NO when it's needed.
I'm using quartz-2d to do a school project. I have implement a user interface like the following.
My question is how to implement touch function under quartz-2d ? For example when I touch some area in the menu will draw another picture?
Thanks
Quartz or no, you're still drawing into a view, and you probably still have a view controller, right? Both the view and the view controller are subclasses of UIResponder, so implement the usual -touchesBegan:withEvent:, -touchesEnded:withEvent:, etc. Since it's probably your view that knows how the various parts of your UI are drawn, it would make sense for the view to handle the touches, figure out which part of the UI was touched, and send higher-level messages to the view controller.
A couple of weeks ago i have started my research in Iphone app development and after alot of hello world applications in different settings i am now ready for my very first application based on the MVC design pattern used in Cocoa.
This opens up alot of questions for me though and after reading the different class references about UIViews and controllers i am stuck in trying to figure out which one i should be using.
In my application i am trying to create a grid of small rectangle's with each rectangle having a different text value on them, to be more specific, i am trying to create a simple calender that will display all the days of a month in a grid.
Every rectangle is a instance of a class i named Tile, in this class i want to implement the drawRect method to draw the rectangle for me and set the text value to the day it should represent.
In order to implement this i have done some research on how this should be done.
From what i have learned so far is that UIViewcontrollers do not really display anything, they are basically sitting there waiting to respond to any events from their children.
In my application i would translate this to the Controller that will respond to each touchevent on a tile.
A UIView however is also a container but one for objects that will need drawing methodes like drawRect. This would translate to the grid that will hold all of the tiles if i'm correct.
Except, i have no clue what subclass i should use for each tile, i have the feeling i am really missing some basic knowledge here but i just can't figure it out. Would really appreciate it if anyone could point me in the right direction with this.
If there were any two apple document you should read, it is the one about UIViewControllers which can be found here and the one about UIViews which can be found here. The UIViewController, as you mentioned, is more about integrating with the iOS system than being a visible component. It has a reference to a UIView, and that UIView is the root node in the visible tree of elements which starts at that View Controller.
In iOS programming you don't really need to worry about drawing rectangles, because for the most part you will be extending elements which know how to draw themselves and then just telling them where to go. The basic visible element in this case, is the UIView. There are many different kinds of UIViews (see the graphic in the UIView programming guide link), so for your case you could use a simple UIView with a background image set to your calendar box graphic, and add a subview of type UILabel. UILabel is a subclass of UIView, so you know it will be something visible as well.
Once you grasp these concepts (which can take a long time) Interface Builder will start to make more sense and you can start doing some of these things with it - and understand how its working. In essence it will create the hierarchy of a UIViewController referencing a hierarchy of UIViews automatically, then you.
Tile should be subclass of UIView since you want to drawRect your "days". Then you can add as many Tiles as you want to your UIViewController.view and manipulate them from UIViewController code (.m file).
But you can add UILabels to your Tile view and manipulate them by setting their text property. In this case you won't need to override drawRect: at all, UILabel will do the rest for you, but you will have to programmatically add this labels to your Tile (e.g. in Tile's init method) or in Interface Builder. In the last case you will have to load them from XIB using [[NSBundle mainBundle] loadNib:owner:options:] method.
I'm about to start a new iPhone app that requires a certain functionality but I'm not sure if it's doable. I'm willing to research but first I just wanted to know if I should at least consider it or not.
I haven't seen this in an app before (which is my main concern, even though I haven't seen too many apps since I don't own an iPhone), but an example would be the iPhone shortcuts panels: you can hold on an app, and then drag it to another panel, sweeping while still dragging it. But this is the core app, is it possible to reproduce something similar within a normal app?
I only need to be sure it can be done before I start digging, I don't need code examples or anything, but if you have some exact resources that you consider helpful, that would be appreciated.
Thanks!
Yes. If you have your custom UIView subclass instance inside a UIScrollView, your view controller just needs to set the UIScrollView to delay content touches and not allow it to cancel touch events.
[scrollView setCanCancelContentTouches:NO];
[scrollView setDelaysContentTouches:YES];
When the user taps and holds in the custom view, the event goes to that custom view, which can process the touch events to drag an item around, but if the user quickly swipes, it scrolls the view.
The "panel" view that you're referring to appears to be a UIPageControl view — although, perhaps, the specific incarnation of this view that Apple uses for the iPhone's home page may be customized.
Instances of generic UIView views that you might touch-and-drag will receive touch events. By overriding methods in the view, these events can be processed and passed to the page control, in order to tell it to "sweep" between pages.
If I wanted to do what you're asking about, that's how I might approach it. It seems doable to me, in any case.
Start with this: Swip from one view to the next view
Try using a UIButton that tracks the time since the state of the button changed to "highlighted". You may need to do this in order to track the dragging and move the button around:
Observing pinch multi-touch gestures in a UITableView
Check to see if the button starts overlapping one side of the screen while being dragged. If s certain amount of time elapses since the button first started overlapping the edge and then manipulate the UIScrollView so that it switches to the next page on the corresponding side of the screen
You may need to use NSTimer to keep track of how long the button is held down, etc.
In any case there's no reason why this couldn't work.
If UIButton doesn't work then perhaps try a custom subclass of UIControl (which tracks the same touch down actions etc.). If that doesn't work then use the window event intercept thing to track everything.
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.