I have an app with some tabs at the bottom (UITabViewController), and most of the tabs also include a toolbar at the top.
The user needs to be logged in to access one of the tabs -- let's call it the "My Account" tab. Once they are logged in, they will either be shown their profile information, or if they haven't set it up yet, then they'll be shown a dialogue that explains the benefits of filling in their profile along with a big button that says "Get Started". All three of these screens have tabs at the bottom and a toolbar at the top. So the views I'm making only take up the middle portion of the screen -- therefore they need to be loaded as subviews. In essence, I'm trying to display one of three different subviews based on the user's current state, and I need to be able to switch these subviews with one another whenever the user's state changes (such as when they log in).
I originally created three separate "layers" for these subviews and just used setHidden to switch between them, but that has the big disadvantage of initializing all 3 views regardless of which ones are being used. I'm also not sure how to animate the transition when I'm just hiding/unhiding them.
Ideally, I would like to create three separate nib files (one for each view) that share the same viewcontroller (the parent controller), and just load them in dynamically based on the user's state. So if the user is not logged in, I'll load in the "Login" nib and then use addSubView to add it to the screen. When the user logs in, then I can load one of the other nibs as a subview and then use an animation to switch out the subviews.
The problem I'm having is that all three of the subviews are simple enough that I just want to keep the logic for handling their button clicks within the top level view controller (the "MyAccountViewController"). For example, I would like to be able to handle the click event of the "login" button within the same view controller that is responsible for displaying the user's profile information. I don't want to have to create a separate view controller for each of the subviews.
This is what I'm currently doing:
- (void)showLoginView {
UIView *loginView = [[[NSBundle mainBundle] loadNibNamed:#"Login" owner:self options:nil] objectAtIndex:0];
[self.view addSubview:loginView];
}
It just crashes on the "addSubview" line with EXC_BAD_ADDRESS. By the way it is behaving, it seems to be running out of memory, possibly due to an infinite loop or something. I have a feeling I'm WAY OFF on the solution here.
Is what I'm trying to do possible?
I would also be interested in learning about any best practices for handling login screens. I've been having a lot of trouble figuring out the best workflow for an iPhone app. I'm used to writing web apps (and yes, a login is necessary -- this app is tied to a website).
Thanks!
EDIT: I've considered writing a separate view controller for each of the subview nibs. These view controllers would handle the button clicks within their respective nibs and then use objective-C's delegate feature to propagate the event up to the parent view controller, but that's a lot of extra code I'd like to avoid if possible.
If you haven't already, I'd double check your connections in that nib and NSLog the class of the var at index 0 to make absolutely sure it is a UIView.
My advice: scrap the nibs. If you can't do it in code, why even bother? I only use nibs as a layout tool, and never package them with a binary. Just make UIView subclasses instead and save yourself time, memory, code, and storage space.
As for your login screen idea troubles, when I'm stuck, I visit the Mobile Design Patterns Gallery for inspiration. If you would like a more... -Expert shall we say- opinion, visit SO's visual cousin ux.stackexchange.com
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'm working on my first app and I've issues on how to layout some of its logics.
Basically, what the app is supposed to do is to show a first screen when launched where user can fill in some values and press a button that opens a tableview which shows results. The first screen (view), outlets and connections are all working fine. The issue I'm having is how to leave this "home" search view and show the results to the end user on a table view. Right now, I've only 1 view with its related View Controler and this controller handles the tasks of taking user inputs and get results throughout a HTTP post request.
I need your guidance...Thx in advance
Stephane
Is there a reason that this all has to happen on one screen? iOS is set up to allow for this to happen very easily and (I think) attractively by using a UINavigationController and pushing in a new view controller (could be a UITableViewController or simply a UIViewController that contains a UITableView).
If you MUST have all of this take place in one view, Swastik is correct that it will require some view acrobatics. One way to do it attractively is to use the UIView animations introduced with iOS 4.
Here's Apple's UIView documentation: UIView Class Reference
Specifically, check out the CLASS methods of:
1. animateWithDuration:animations: (with or without completion:)
2. transitionWithView:duration:options:animations:completion:
Note that these methods will require you to learn a little bit about blocks, but it's worth it and I think blocks give tremendous power!
With the methods mentioned above, you could fade out your form and fade in your tableview, or maybe just move the form off-screen while the table view flies in. The possibilities are limited only by your imagination.
u can add a table in ur xib.Initially make it hidden, & when u need to show it unhide it & also if u want to update table's data , you can reload the data of the table.
how do I use multiple UITabBar tabs for controlling a single UIWebView?
An Example:
Pressing tab1: UIWebView loads index.html
Pressing tab2: the same UIWebView loads customers.html
Pressing tab3: the same UIWebView loads tos.html
My approach was to put the UIWebView in the AppDelegate and set self.webview of every ViewController to that single UIWebView. However, the WebView gets displayed, but is white and doesn't load anything.
Any hints?
WebViews are expensive so your approach is probably right, but you may want to start out with creating a separate webview in each tab view controller and see if things are working as you expect there first. The overhead may start causing your app to start receiving memory warnings, but this would at least allow you to see if your pages will at least load correctly in that context.
Also, can you post some code that shows how you're adding your webview to each view controller? If you are not setting the frame of your webview using -setFrame, once you've added the webview as a subview of your view controller view, it won't show up correctly.
You need to -removeFromSuperview and then -addSubview to move the webview around; just re-assigning to an instance variable won't do the trick.
A tab bar is really the wrong model for what you are trying to do. If you want to switch content what you really want is a ToolBar, because that is meant to alter an-place view in various ways - TabBar is meant for switching between multiple unrelated views, and as such you are fighting against it when you try to use the same view across multiple tabs.
Now if you really have totally unrelated content, why not consider just using different UIWebViews, one per tab. They are not so heavy that loading having multiple instances really hurts anything, and tabs do not load content until pressed so they will not all load at once. To conserve memory you could even toss away view controllers when tabs are switched. But having each view manage its own web view makes more sense and means you can keep the content cached much easier.
I have looked at the PageControl example from Apple and have an architectural requirement difference. In the example the scroll view and page control objects are at the app delegate level. This means the scroll view and page control appears on every view of the application.
However, I have a "settings" view toggled from an info button (for now) that should not have these controls displayed. Therefore, I need to move my scroll view, page control, and view controllers objects down a layer and I'm struggling with how to best do this.
For example, the primary application view consists of metals (periodic elements). From this view I need a scroll view, page control, and info button on every view descending from here. Each metal will have it's own subclass where different images, calculations, etc will be displayed but I believe I need each of these subclassed elements to share the same scroll view, page control, and viewControllers array, right? Do I need a singleton?
What you are describing is kind of like how the native Weather application works. Each time you swipe, the info light is rendered as part of the page you are viewing. However, no matter what info light you tap, when it flips over you still get the same settings. Obviously this is how Apple thinks the UI should work because they did it that way. There is no reason you can't do the same.
In this situation, you don't need to create a singleton, you can use [UIApplication sharedApplication] as your singleton to get to your custom application delegate via the delegate property.
Look at Crème where I do exactly what you describe. The main view is scrollview+pagecontrol. Upon triggering the app into settings mode, the settings panel comes up that does not have a page control.
The solution is simply that you have a simple top-level UIViewController, and you make both the scrollview and pageview children of that viewcontroller. And for settings, you animate the modal settings dialog with a flip animation into the top-level UIViewController.
What is the best approach to implement tabs that look like web applications on the iPhone, like the screenshot below (notice the "Checkin-Info-Friends" tabs)? These are not part of the UIKit standard library, but seems to be very common lately.
I've spent considerable time developing applications for the iPhone, but not developing controls like that one. What would be the best approach here:
create a new UIView for each tab content, and add the three subviews to the mainview straight away?
create new UIViews only when the user clicks on each of the tabs?
Put all the content in a UIScrollView, and just change the page as the user clicks on each tab?
Maybe there are open source controls for this out there? I couldn't find anything.
(source: foursquaregame.com)
My approach to a similar problem was to make all 4 (in my case) tab views, but respond to didReceiveMemoryWarning by releasing all but the current tab view. (Then, of course, you must make sure that you create the new view, if it doesn't exist, when the user chooses a new tab.)
I thought this was a good compromise - a speedy reaction to the user at first (and in my case memory footprint is at its lowest at this point in my app), and then a response to low memory to avoid being shot.
I think it best just to have three UIView* references to the subviews in the parent view or view controller, all initially null, then to have subroutine to hide the other two views if they are visible and either construct and show or just show the new view. Assuming no extraordinary memory requirements.
I think with such a small screen area load/unload concerns at the subview level are unlikely to be a concern, but if the parent views need to be loaded/unloaded, the subviews should all go (be both hidden and unloaded), and on reload, loadView should call the routine described in the last paragraph at startup.
If there is in fact a great deal of memory or resource use by any of the three subviews, then my advice is reversed and each of the subviews and/or any memory-intensive objects behind them should be not only hidden but unloaded whenever possible. I think with your use of Google maps there, a need to unload when hidden might apply to that.
Is this th right point to make? Is there some extra detail I'm missing?
You can have each tab be a real view controller with nib and everything. The only catch is that you must forward on the standard view controller calls you want to receive (viewWillAppear, etc) but it makes the coding much cleaner since you code just as you would for any other view (although for a smaller space).
You call each controllers "view" property to get out the view, which you add as a subview of a container view you have under the tabs.
If all three are table views, you might get away with using a single UITableViewController that changes contents based on the selected tab. Otherwise I second KHG's comment of using real view controllers to back up each of the subviews.
For the tabs themselves consider subclassing UISegmentedControl.