I want to make an iPad application (I'm actually making it now, it's just not working...) where I start out with a login screen for the users and if they authenticate I want to transition to another screen which will have a TabBar.
Right now I have my iPadAppDelegate with a MainWindow XIB file. In MainWindow I have a SignInViewController which is matching a class and XIB file of the same names. The SignInViewControlelr XIB contains all the text fields and buttons the user needs to sign in.
If the user is authorized I want to transition to the screen with a TabBar, which is why I have a UITabBarController in MainWindow XIB, but I can't seem to transition to it.
Ultimatelly, I think I'm misunderstanding how Cocoa's version of MVC works (my MVC knowledge is limited to ASP.NET MVC since it was in v1 preview 1... And as I can see it right now there's big differences, but I am most likely very wrong, hence the misunderstanding). Perhaps I'm using too many controllers and too little views or just not placing them where they should be, let alone writing the code to interact with them...
I'd appreciate an explanation on how I should properly structure the controllers and views to get what I want to achieve. An app similar to what I want to do is the AT&T myWirelss app.
Help would be appreciated!
P.S. I've litereally been learning how to make iOS apps from watching the videos of xvitcoder on YouTube and further adding the functionality I need while asking questions on how to add the functionality I need. The videos are good (I think), but I'm trying to do something that isn't really explained by them (I think).
UPDATE
The code I ended up using, which works, although I'm not sure if its the proper way of doing it:
DashboardViewController *dashboardViewController = [[DashboardViewController alloc] initWithNibName:#"DashboardViewController" bundle:nil];
[appDelegate.window insertSubview:dashboardViewController.view aboveSubview:self.view];
[dashboardViewController release];
You may find the View Controller Programming Guide informative. Ultimately you can have a derivative of UIViewController that you use to internally manage your different views/view controllers or you may also utilize a UINavigationController.
A really good simple model of flipping between big views is provided by the "Utility Application" of the iPhone templates. It shows how a view controller can call another controller. This might give you a start.
Related
I am a newbie in all this as will be apparent really soon.
I am using the iOS: Application: Tabbed application template. I have placed a UIImageView in the first view and two standard rounded buttons. One button is attached to an action in the FirstView Controller which places a picture into the UIImageView. The second button is attached to an action in the AppDelegate which calls a method in the FirstViewController which in turn places a second picture into the UIImageView.
The AppDelegate method does not replace the picture. It doesn't crash… it just does not seem to do anything.
How can I manipulate the view in the First and Second View Controller from the AppDelegate?
#dasdom
Well that's one issue explained. I've been reading the theory of MVC and trying to put it into practice now. Short version is I am trying to write a Battleship app for practice. Was planning on using the first screen to setup the game pieces, prefs, etc.. and use the second screen for actual game play.
I've created another class to use as my "brain center" but I ran into the same issue of not being able to manipulate anything on the screen for the first or second views. (That's why I tried the appDelegate).
That's my life story right now… can you throw some pointers my way on how to proceed and how to solve my one of many problems?
First you shouldn't do that. The AppDelegate should only be responsible for bringing the first view onto the screen.
Second you should have a look into the Model-View-Controller design pattern. Search for it in your preferred search machine.
But I you really still want to do that you should have a look into delegation and/or notifications. For example you could send the First View Controller a notification from the AppDelegate to change the image.
Relevant Data:
I'm making a simple game, using OpenglES. The game itself is done, however I would like to have a main menu as well as some other screens designed in IB. So far I have a death/score screen that is displayed with a simple modelviewcontroller.
I haven't done a ton with GUI building or much programming on the platform outside of C code (posix sockets) and some examples from some books. So I'm not sure how I would go about having lots of views- usually I just use a model view, and it's gotten me along just fine so far. However I don't think that would be the best route here.
Situation:
I have a view controller that shows my main menu- the main menu branches off to the main game, a settings screen, and a high score screen. The main game is made in opengl, and I haven't made the settings view yet, but it likely will be as well. How should I switch between the views? Presenting the main view from the app delegate is as simple as setting the root view controller = newly created view controller, should I do the same thing here? If I do that can I remove the resources from the menu view controller?
Sorry if this is an extremely simple question, I just don't quite get the process.
I'm not entirely sure what you want to do, but an easy way to show a new view controller is:
SecondViewController *aSecondViewController = [[SecondViewController alloc]
initWithNibName:#"SecondView" bundle:nil];
[self presentModalViewController:aSecondViewController animated:YES];
I hope that helps.
How should I switch between the views?
In the vast majority of cases, you should be using a UINavigationController. Your initial controller would be the main menu. When you want to go into a particular section of your application, you push a new view controller onto the stack. When you want to come back out, you pop it off the stack.
Besides navigation and presenting modally that others have mentioned, another option is to swap out views. May or may not fit your app's flow but wanted to point out another option for you to consider
Best practice for switching iPhone views?
If you are already limiting the game to iOS 5 for some other reason you should look into UIStoryboard. If you don't currently require iOS5 the "simplest" way is to use table views, but that isn't a very "gamey" UI.
In Apple's developer guide, they state: "A split view controller must always be the root of any interface you create" (see here). I was curious if anyone knew why they decided that. I have a tab navigator-based application and it makes sense for the content in one of the tabs to be presented in a split view. Why would Apple be opposed to that kind of design? Thanks in advance for your answers.
-Max
PS I'm not looking for ways to put a split view controller in a tab navigator controller (that much I can figure out, even if the code does look sloppy). I'm more curious if anyone has any idea why Apple frowns on it.
I don't think that this is necessarily a user experience decision as much as it is a technical restriction. UIKit makes a number of assumptions about how UIViewControllers will be used. Including the idea that only a single UIViewController instance has its view visible in given window at any given time. Now since Apple has access to the implementation they have been able to make exceptions for their own "container view controller" classes (UINavigationController, UITabBarController, and UISplitViewController). We can't tell exactly how much of a special case these controllers are or what they needed to do to support displaying nested sub view controllers correctly but one consequence seems to be that both UITabBarController and UISplitViewController are not intended to be used except as the root view controller of a window. Attempting to nest them within other container view controllers may cause unexpected or unreliable behavior.
I tried to cover these restrictions on the use of view controllers and some possible alternatives here: http://blog.carbonfive.com/2011/03/09/abusing-uiviewcontrollers/ Hopefully that's of some use to you but I'm afraid the only reliable way to get the UI you seem to be looking for it to implement your own split view style display within the view of a single UIViewController.
Please ignore my answer:
Because you can't resize UISplitViewController's subviews with touches?
Apple has always placed high value on consistent use of user interface elements. Having all applications work in the same way helps the user to immediately understand how an app works even if they've never seen it before. Establishing a conceptual hierarchy of view controller containers makes a lot of sense when you're trying to help the user predict behavior.
Summary
From a conceptual point of view, should one be working with UIViewController subclasses and their Nibs, even if you're not using the UINavigationController?
Scenario
The application I'm trying to develop has no UINavigationController. I'm mostly looking at elements in one particular UIScrollView implementation, and if there's at all a 'next level of navigation', it merely alters the appearance of a small element to show more details. The detail views of the elements (different elements spawn different views) are laid out in Interface Builder, for which I opted to create new UIViewController subclasses with corresponding XIB files.
Doubt
While exploring the different ways I could have these instances animate into view, I come across a lot of solutions using the UINavigationController. The UIViewController itself already seems to be geared towards the synergy. There's a self.navigationController, and lot's of examples online of how to push and pop with and without animation.
Question
So what I'm wondering right now is "did I do the right thing?" Googling an answer to that question only brought me to more specific implementation examples, so I decided to post this.
Should I have restrained myself in using XCode's "new file" template for UIViewController subclasses with XIB? Or should I have implemented a UINavigationController in my app, even if there's no screenfulls of navigation going on?
I'd be much obliged for enlightenment.
Cheers,
Eric-Paul.
UIViewController is a useful tool. It offers memory management things, anchor points for interface rotation and lots more. If needed, they can be pushed to a navigation controller (if not now, maybe later), could be a page of a tab bar controller, or behave well in popovers on iPad.
They come cheap and I don't see a reason not to use them. And your code needs to go somewhere anyway. Don't flood the application delegate or the view.
I'm trying to create an iPhone app with a welcome screen that leads to two or three pretty disparate UIs; once you've drilled into one you're not going to have much use for the others, and each one is itself fairly complicated.
The designers are all web types and it looks like the "navigation" paradigm is the closest to what they want, but the breadcrumb-style navigation bar isn't.
If I set up a UINavigationController, can I then drive it with arbitrary buttons in the views?
And in general, is it possible to swap out the contents of a view programmatically?
And if so, what do I need to watch out for? (E.g., in Java if you change the contents of a JPanel you need to make sure it gets revalidated and repainted.)
Total iOS newbie here, coming from the Java world, super-explicit advice much appreciated. Using Monotouch, but happy to take Obj-C help and translate. :)
It's hard to tell you how to design your app with only that information, so I'll assume you want to do a drill-down thing like a UINavigation controller.
1- Yes, you can drive the UINavigationController from other ViewControllers, using methods like PushViewController() and PopViewController(). You can also hide the toolbar or some of the toolbar buttons if you want. You can find some great examples here.
2- Yes, you can change contents of a view. Views contains other views and you can add and remove them as you want.
3- The main thing to be careful about is to make sure that calls that update the view are done inside a InvokeOnMainThread(()=>{}) call. More info here.