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.
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 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
I have a set number of ViewControllers in my app. They are allocated and initialized at application launch and released at exit. They are used by a NavigationController to be pushed/popped. In these ViewControllers there are WebViews (actually there is nothing else).
My problem is :
When I want to change de content (URL) of a WebView that is not on the current TopViewController, the content isn't loaded until I push/pop the associated ViewController.
And the transition us "ugly". The pushed/popped Viewcontroller shows old content at worst or blank page at best, before the ViewController is in full view THEN the new content is shown.
I tried lots of things (even putting the "loadRequest" in a different thread with looks stupid).
Do you know any way to make things go smooth?
In general you should plan your UI for slow UIWebView loads, because you can't plan ahead to know how long things will take. What I often do is have a UIView that has a spinner and a message such as "Loading..." that is layered on top of the UIWebView. Here's how I use it:
In viewWillAppear: I unhide the loading view and start the spinner.
In webViewDidFinishLoad I hide the loading view.
If webViewDidFail gets called, then you're not showing some interim or invalid content while the page loads. You can present a UIAlertView in that case.
If you're curious, you can see this in the high score page of my game (Lexitect, free)
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.
I have been spending time learning how to use the iPhone SDK. I've read "Beginning iPhone Development: Exploring the iPhone SDK" from cover to cover and I've never seen an example of multiple views within one XIB.
To illustrate what I mean, here is a screen shot of a XIB with the simple configuration of what I'm referring to:
alt text http://theopensourceu.com/wp-content/uploads/2009/04/one-xib-multiple-views.png
I figure that there has to be a very specific reason that I've never seen this. In Apple's examples and in all of my readings thus far, multiple XIBs are used with only a single 'view' (and sometimes the Navigation Controller or a Tab Bar Controller, etc). What is the reason for this? Should I avoid multiple views inside a XIB? What are the advantages or disadvantages to to either method?
Thank you in advance
It's a question of memory optimization and loading times. If you put all your views in one XIB, then when your application launches, it has to load the entire XIB into memory and construct all of the objects for all of the controls, and this takes a non-trivial amount of time.
If instead you separate your views into separate XIBs, then your app will start up much faster, because only the XIB containing the initial view will be loaded, and it will also use less memory at first. Then, when the view changes, you can load the XIB containing the new view lazily. This will incur a minor hitch when opening a view for the first time. If you're really trying to optimize memory use, you can also unload the previous view when switching views, but I wouldn't recommend this, as this will incur a hitch every time you switch views, instead of just the first time you switch to any given view.
Following up on the previous answer, there are some times when you would like to load multiple views at the same time. Here's an example: You are displaying a report with multiple pages and you're going to use a UIScrollView to manage them. When the user is done browsing the report, he will close the report which will dismiss the view.
Create a UIScrollView in a XIB along with a UIView for each page you need. Since the UIViews are part of the XIB, they will be loaded into memory together, all at once, when the report is opened. Create two UIViewControllers and use them to display the page being viewed and the one being scrolled to. As the user moves through the pages, re-use the UIViewController on the page being scrolled away from to hold the page being scrolled to.
This will ensure great performance while the user is flipping through the pages. It loads all the pages at once up front into memory. I only uses two UIViewControllers, and it just changes which views are in them and moves them around.
This also has the great benefit of having all of the pages in one XIB. It makes it easier to edit, and quicker to load than separate XIB's. You just have to make sure you have the memory to load all the pages at once. If it's static content (such as in my case) it's a great way to go.
If you're looking for a good example of how to do this, I found this resource to be an excellent starting point:
http://cocoawithlove.com/2009/01/multiple-virtual-pages-in-uiscrollview.html
This is a warning to anyone trying to implement landscape and portrait with two views in a single XIB (iOS 4 with Xcode 4). The primary disadvantage of having two views in a single XIB–for me–was that you can only connect a single UIOutlet object in a XIB to a single UIOutlet object in a view controller.
So, for example, if you have a XIB with a view for landscape and a view for portrait, and both views contain the same interface objects in different positions (such as a UILabel in landscape and a UILabel in portrait). It is not possible to link the UILabel in your portrait view and the UILabel object in the landscape view to a single UILabel object in the view controller at the same time.
I find this a disappointment, as the iOS UIViewController documentation (iOS 4.3) suggested that I could implement custom landscape and portrait views by switching between two views programmatically as the screen rotates.
After spending quite some time to figure out how to do this, I discovered that it is possible to have two different views attached to a single view controller, but you need to have outlets for both views. For example, in my view controller, I have two UILabel objects (one to connect to a UILabel in the portrait view; one to connect to a UILabel in the landscape view). In my code, every time I update the landscape outlet, I also update the portrait landscape.
Not very elegant, but it works, and as this is for a simple view with one screen, it won't use up too much memory to have have all the UI objects duplicated in the controller and views. I wouldn't create a project that did it that way again, but it was a good enough work-around for that project.
One reason I place multiple views in one xib is because unlike storyboard xibs don't allow placing header and footer in the table view itself. So I create to separate view for header and footer view and assign them in viewDidLoad.