I'm trying to build an educational app that will have approximately 3-5 completely different pages/screens. Each screen contains one puzzle and each puzzle is independent of all the other puzzles (screens). Once the puzzle on the current screen is solved I'd like to transition to a new (randomly selected) screen. I would allow the same puzzle to be shown multiple times, however, if it had been displayed before it would need to be reset.
I've tried doing this using segues but that seems to require a UINavigationController which is not the experience I want to present (since it requires a predefined hierarchy of screens).
I assume the best way to do this is to have each screen as completely separate UIViewControllers, correct? I'm just not sure how to orchestrate the navigation/rendering between them.
I'd appreciate whatever best practices you know of. Thanks!
Well here is a possible option:
First of all if you want a menu outside of these puzzles have that as your root view controller in a UINavigationController.
Then create a launcher controller and add it to the navigation controller when appropriate. This will be a regular UIViewController except in this controller in the viewWillAppear method have it pick a random number 0-5 and run it through a switch and depending on the number push one of your 5 view controllers. Then when the puzzle is completed call popViewController on the navigation controller. Now when it pops back, viewWillAppear will be called again and randomly push another. Then if you want to go back to the main menu at any time just call popToRootViewControllerAnimated. This should do what you need. And to make it so it doesn't animate twice either only have the push animate or only the pop.
Rather than having different view controllers you can have a single controller. You can reload the view of the puzzle after completing the first. The logic you have applied for the first puzzle will be some what similar to the the others. So now only you need to handle different states of the puzzle.
For example: I have first view with puzzle 3x3 matrix, the next will be 4x4 matrix and the next will be 5x5 matrix. So this states needs to be handled through code in view controller.
I know that using cocos2d is a great way to build games and it allows different "scenes" where things are independent of each other or can communicate if you choose. Also with cocos2d there is a "director" that handles all of the scenes and can push scenes for you. If you are curious check out: www.cocos2d-iphone.org
I hope this helps :)
Well, I was build the app tested yesterday to play different music instrument. I use UIView to handle view for 3 of my instrument. The logic is simple. I put the navigation on UIButton and add a subview for each instrument. When the user touch the button, the selected view will be add to the front, and the last view will be release or temporary on the background.
Hope it will help you.
Related
Hy everybody
I am a newbie ios programmer and I'm facing many doubts when I must switch the pages of my app.
With the term "page" I mean a UIView that fills the whole screen with some widgets (buttons, textboxes. tables..)
As far as I have understood what I've read I should use an UIViewController to manage each of these pages
since each page should be a screen’s worth of content.
My App starts with a ViewScroller with many buttons and when the user clicks one of these it opens a new page.
The first page is the UIView connected to the RootController Of the Window.
So far to open the new pages I add a child controller to the RootController and it's view as a child of the view of the RootController:
RicLocaliController = [[RicercaLocaliViewController alloc] initWithNibName:#"RicercaLocaliViewController" bundle:nil];
[self addChildViewController:RicLocaliController];
[RicLocaliController didMoveToParentViewController:self];
[self.view addSubview:RicLocaliController.view];
RicLocaliController.view.frame = self.view.bounds;
When the user clicks the "Back" Button I remove the child controller and the child view.
Going down this road I would get a dynamic tree of Controllers with their Views.
So far I have not encountered problems and my app can go up to a third level in the tree and come back. Each page behaves correctly when orientation changes.
But I'm afraid that adding, for each subpage, a child controller and a child view could be not the right thing to do.
I'm afraid that if I nest a lot of pages when the orientation changes the app could respond slowly since also the superviews will do something to manage this event.
So what I wonder is if what I am doing is completely senseless, if I should use Navigation controllers or some other way to manage my page changes.
Unfortunately my boss is not giving me enough time to study well the subject and so I would like an advice to follow the best solution possibly using the most standard and less complex component offered by the framework instead of the newest features.
I read a lot of web pages on the subject but it seems to me that there are many ways to manage the navigation beetwen pages and this makes me confused.
I apologize for my bad english but i'm tired and English it's not my first language.
You HAVE to do some studying. You will spend more time clearing up all your problems later otherwise... but, here are some tips.
Using nested ViewControllers leads to all kinds of trouble so if you are short of time, skip that.
Think of each "Page" as one ViewController. A ViewController has a property called View but that is actually just the top view of a whole hierarchy of views. A view is the base class for any visual object, like labels, buttons etc. All views can have subviews, so you can add an image under a label etc. and do really wierd stuff if you want to. I am just saying this to free your mind about how you can use views.
Now, ViewControllers are supposed to hold to code to ONE view hierarchy. That view hierarchy is for that View Controller only.
When the user wants to navigate to another page, you have a few alternatives:
NavigationViewController - that should be used when the user wants to delve down into data, like opening a detailed view of an item in a list etc. The NavigationViewController gives you help with back buttons, proper animation etc. You "pop" a viewcontroller to go back one level. If the user click the back-button, this is automatic.
TabBarViewController - use that if you want a tab bar at the bottom of the screen. Each tab is connected to a ViewController, that has it's own view hierarchy.
PushModal - If you are in a ViewController and just needs to get some data from the user, which is not part of the normal navigation of the app, you can push a new ViewController modally. This is the way you interact with iOS built in ViewControllers. This is also a good way to get a value back from the view controller.
There you have it. Go learn more. :)
It sounds like, for what you are using, you should be using a navigation controller. This will automatically handle pushing views onto the stack and then popping them off again later. This will also automatically create a back button (it is customizable) in the navigation bar.
If you are using iOS 5 or 6, I highly recommend trying out "storyboards" in Interface Builder. Storyboards allow you to graphically represent transitions (called "segues") between different views.
On top of being easier to design and implement, another advantage is that, if in the future you want to change the design of your application, you don't have to trawl through all your code and manually update each view connection.
I have a number of objects linking to each other in a circle. Each object holds a reference to it's neighbors, square and triangle are different class types:
The tow classes, triangle and square, are made visible with a ViewController, and they link to each other with segues.
So far, no problem. However, while I'm browsing around in my structure, I keep adding ViewControllers on top of each other. Not only does this seem a bad practice memory-wise, but it also presents the problem that when I want to quit this structure, I have to back-track by closing all ViewControllers that I opened.
So what I'm looking for, is a way to not add the next ViewController on top of the current on in the stack, but to replace the current ViewController with the next one.
I've been looking for a while for a solution, but have little success. So I feel that doing what I want is either impossible, or I'm just not getting an obvious point and don't know what to look for. Do I need a RootViewController for something like this? Or should I create a custom segue that dismisses the old ViewController before adding the new one? I'm really at a loss here.
Add all subView once , in viewDidLoad and give tags to all you SubView after that where you you want to show that view in viewController don't add it just bring it to front by calling the function [[self.view viewWithTag:1]bringToFront]
Since you are probably using a navigationcontroller, you should have a look at the UINavigationController reference. There are methods to modify the navigation stack. You cannot do this only with a storyboard. You will need some custom code.
You should have a look at the UINavigationController method setViewControllers:animated:.
Sounds like you want to do one of a couple things
Replace your rootViewController
Have a rootViewController which acts as a container for a single UIViewController and change that out as needed. In iOS 5 you can do this with a custom UIViewController, but or you could use one which Apple provided.UINavigationController` can do it, but unless you are also using it to navigate a tree like structure of view controllers it's probably not the best option.
Your best answer sort of relies on your need.
If your controllers don't have much state or don't get swapped in and out a lot you could use option 1.
If you expect users to swap between controllers often and quickly and/or your controllers require significant setup or have a lot of state then you might want to a NSArray and just use presentViewController:animated:completion: to show different controllers when needed. Storing your controllers in a NSArray has the added bonus of easily being able to identify their neighbors.
The UINavigation controler's method setViewControllers is an option.
Another would be to pop the most rencent view controller using popViewControllerAnimated:
In some cases popToRootViewControllerAnimated: would be best or even popToViewController:animated:. Hoever, I personally was not successful using popToViewController:animated: but that may have been my fault at that time.
Yes, I think you need a root view controller. I myself tried to exchange the root view controller the other day but failed doing so. In the end it was probably not the most elegant solution but easier for me to implement some dummy root view controller which does nothting but display my app logo in the background (Same as the default image but moved into negative coordinates in order to match the default image on startup. It is laying 'behind' the navigation bar and status bar.). It could show some empty black background or so. In the end it is will most probably never be visible.
I have a very large form to build in my ipad application and I'm note sure which approach( between create multiple views in or multiple viewcontrollers ) to follow. Well, I have decided to split may form in logical sections, so I want use a splitviewcontroller with a root( a tableviewcontroller with the sections) and multipleviecontrollers for each sections. When the user select a row in tableview I will show the correspondent viewcontroller. I'm saving a reference for each viewcontroller in my app_delegate and the app_delegate also is the responsible for change the viewcontrollers. Is this the best approach? There is other approach to follow? About the multiple view I was thinking to put multiple view in the same xib file and then choose based in tag as the use tap the row in rootviewcontroller's tableview.
Thanks in advance. And sorry for my bad english.. Learning!
I will say this on the subject: currently, having multiple view controllers on the screen at the same time can be problematic if you're not using one of Apple's existing classes, such as a UISplitViewController.
The main issue is that important events your view controllers will want to respond to (rotation events, etc) won't be passed down to them. It's not a huge pain, it's just something to need to take into account - you'd typically create your own parent view controller that could pass these events down to its children.
Now, you are using a split view controller, so alls well on that front. There is no provided way for detail and master controllers in a split view controller to communicate with each other, but Apple recommend you employ a standard delegation pattern. If your application is fairly simple this could certainly happen in your app delegate as you do now.
If you're targeting iOS 5 only there are some changes that are relevant regarding multiple controllers on the screen at the same time, but I can't discuss them on here because of the NDA. You should go to Apple's developer forums (devforums.apple.com) to learnmore.
Sounds like I'm trying to do the same thing as you (large insurance forms here, how about your project?) Unfortunately I can't help out as you're a bit ahead of me. I've been able to flip back and forth between 8 detail views by tapping on the 8 rows in my UITableViewController, without keeping a reference to either the current or previous one anywhere. The data I enter into various TextFields stays where it should.
I currently have a xxxViewController.h/.m and corresponding .xib file for each detail view. That's an awful lot of code, but I couldn't see any other way to do it. Now I'm having a problem getting my button pressed handlers to fire. Also I've still got to put a database behind these screens.
Were you able to overcome your issue?
Thanks,
Jeff in Alabama
I've spent too much time walking down dead ends on this project, so it's time to query the hive mind:
I am making a simple iPad game consisting of three locations which the user navigates between when an area of the screen is touched. These locations are represented by fullscreen images and there are a lot of different animations and stuff going on which makes it logical to divide each location into its own UIViewController.
The question is this: Which components should I use for handling the navigation between the locations/controllers?
UITabbarController: After finally managing to hide it away without a white bar at the bottom, I could not get selectedIndex to work in order to swap between view controllers.
UINavigationController: Does not permit more than one view controller inside, and I have three which I want to use. Is it possible to hide it away and still use it?
I could of course cram all my logic into a single UIViewController, but this seems plain wrong. Any advice or solutions for a newbie struggling towards journeymanhood would be greatly appreciated indeed!
If I well understand, everything happens like if you had three view to manage separately. If this is the case, you definitely should have three view controller. Communication between these controllers should then take place in the model. View controllers can be made aware of changes in the model through delegate in this case. If those interaction become too heavy, I suggest you create a super controller (application controller) managing the model and the three controllers.
I'm programming for the iPhone and I'm wondering when to use the addSubview method of a view and when to present to use the modal view controller (presentModalViewController). What complicates this even more is if you are using a navigation controller (I'm not) and you can use the pushViewController method?
When would you use each and why?
Thanks.
-presentModalViewController and -pushViewController are two ways of going about the same thing: displaying a new view. Which you use depends on the user experience you're going for. They mean different things to the user, but are very similar in implementation.
-addSubview is completely different. It adds components to the current view. You should never use it to display an independent UI. -addSubview is most often used when programmatically creating the UI in -loadView, though it has many other uses.
Here's one way to look at it:
A sequence of view-controllers within single navigatoin controller represent a single workflow in user's head. If at some point you need to interrupt the current workflow and create a diverging workflow you create a modal dialog. If the new workflow only has one step you simply present corresponding controller, but if there are many steps you create a new navigation controller to string the steps together.
The visuals are different - with nav controller user's attention moves from left to right, while with modal dialog from top to bottom. Imagine that you are flipping a book (left-to-right) and at some point you move the book away from you and then pull another book from under the table and place it in front of you (top to bottom), and then start going through that another book (left-to-right). Then you close the whole second book and move back to first book where you left off.
The addSubview method is on a different abstraction plane - subviews are used to create the two experiences I described above. You can use subviews to create a different experience which would be on the same abstraction level. Couple more examples of the constructs on the same level are UIAlertView and UIActionSheet.