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.
Related
I have been using the storyboard to make an application and currently there are many segues and several components. This is causing a ton of lag when I try to do anything inside the storyboard. Is there a way to hide components inside the storyboard? thanks.
+1, For the potentially features to improve Xcode. Now, there is no way you can hide those views (Not that I know). But I would suggest you to,
Hide the debug areas you don't need.
Hide the document outline while working with segues.
Why?
I think in this way whenever you are making changes, system does not have to repaint those unwanted views and long document outline. Probably this will be less laggy(I don't think there is a word like this)!
Work around
Divide your segue into different meta segues and then you can call those segues from your main segue. In that way you don't have to put each connection on one file but you condense it!
And here we go the documentation for it! Now you can get the story board by different file and then initiate with the UIViewController easily. Then you can just use old ways to segue between different ViewControllers.
Apple Documentation for UIStoryboard
Demo App.
In order to achieve this, I have made a quick demo application which will help any future visitors.
https://github.com/Krutarth/LargeStoryboardManagement
Visually something like this,
You can split one huge storyboard into multiple small storyboards.
Select the view controllers that you want to move to a smaller storyboard, then
In the top menu, click Editor -> Refactor to Storyboard
Save the new storyboard with the desired name. XCode will auto generate all the required storyboard links from your large storyboard to this newly created small one.
I'm just getting into desktop Cocoa development (I have experience with iOS development). If this question seems basic, forgive me.
That being said, I'm dealing with a large program with lots of calculations and functionality to deal with. There are almost a dozen views, organized with an NSTabView. Rather than dumping everything into one monstrosity of a class and creating a XIB file that brings my system to its knees (Xcode apparently isn't that efficient…who knew? :P). I'd like for each tab to be its own NSViewController with accompanying XIB; as such, I'd like to load each tab's view from the corresponding XIB.
I'm thinking of this in terms of UITabBarController, but this doesn't seem to work (there isn't an NSTabViewController as far as I could find). I'm not sure how to do this (or even if it's possible—but I can't be the only one with this issue?), and I'd appreciate any assistance. Thanks!
Update: I tried assigning the controller's view to the tab's view, but quickly realized that wouldn't get me anywhere. Is it worth creating an NSTabViewController from scratch, or is there a solution out there?
Cocoa development on the desktop has some major differences compared to iOS development. One of them is the use of view controllers - they aren't strictly necessary - and when you use them you can just stick to a generic NSViewController regardless of what kind of view it contains. All of the methods you need to control the tab view are in the NSTabView class - not the controller.
Having said that, putting 12 views in to a tabview sounds like a painful way to interact with a program. Have you thought about a source-detail type setup (think itunes or mail with their sidebars - each entry in the sidebar corresponds to a different view)?
I've ditched the tab bar, and as per sosborn's suggestion, I have used a split view—or rather I've put a table view on the side, and a custom view taking up most of the screen. Then, in my AppDelegate, I have individual controllers as ivars (I need individual controllers because there are a lot of calculations involved, and I don't want to have a monster class handling them all). They'll be lazily loaded, and the view will be assigned to the current controller's view as necessary.
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.
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.
Hey champs,
This question is for iPad apps designing.
I searched a lot on this very useful site but i didn't find anything related to the question.
Suppose my application needs to present multiple views to the user, then what is the best way to do that. The ways i think that are possible are
1) Use only one view controller and add all other things as a view.
2) Push all the view controllers on the same viewController.
but if we follow 2nd way, we can not get the desired response to orientation changes.
I am a noob so please spare me on this. Any help will be greatly appreciated.
In our iPad game we are using UIKit therefore we have different views displayed at once. We are using view controllers for most of the views which were then pushed on one specific view to show them.
This keeps the logic code separated in the view controller.
The interaction between the controllers (for example hiding or showing a view after an event) will be done with notifications (NSNotificationCenter) to prevent too much dependencies.