My application consists of a tabbar controller with several tabs, each with a navigation controller in them. One of these nav controllers contains a table populated via a web service. I'd like to have an overlay on the table (or a different view) that says the service is not reachable if it isn't reachable. However, I only want this overlay on the table, and not on other tabs.
What is the best way to do this? My current solution is a loading view that appears for the table when it appears, or when there is a change in reachability and this loading view disappears on viewdiddissapear. I like being able to put a semi-transparent loading view on top of the table so you can see the old data I guess....
Are there better/alternate ways to do this?
My recommendation is using an activity indicator with a transparent background.
Here is a complete tutorial and sample code (from Jeff LaMarche).
http://iphonedevelopment.blogspot.com/2010_02_01_archive.html
Related
I have used a fairly common design pattern for a standard IOS slide out navigation. I based the design off of the example found here: http://www.raywenderlich.com/32054/how-to-create-a-slide-out-navigation-like-facebook-and-path. The basic design takes four view controllers, a center view controller, a left view controller, a right view controller and a main container view controller to hold and manage the three other views. The main container places the center controller on top and when the user slides his or thumb left or right, the view slides over to display the appropriate controller beneath. I recently adapted this to a project that has almost thirty different controllers. I have it working with the initial view but am wondering what is the best way to scale this feature? I want this slide-out navigation to be available on every single page so the user can just slide and navigate to anywhere at all times. The right and left view controllers will always be the same no matter what controller your on, is there a way to have a common main container that dynamically loads the center controller depending on the view the user is on? Or do I need to go and implement a container controller for every single controller I want to have the slide-out navigation functionality? Obviously I would think the first method would be the most efficient and scalable, but I have no idea how I could do that or if it is even possible.
An easy way to have a side slide out navigation is to intergrate opensource code into your project. The code normally comes with directions on how to implement it and a demo app.
Here is an example of an opensource slide nav like facebooks
mfsidemenu
The website this link takes you to (www.cocoacontrols.com) has some great opensource iOS controls as well!
I am coming from a Windows Visual Studio (VS) background, so I'm finding the Xcode environment, well, overly complex for lack of a better description.
I'm planning an app which will need 4 views (what I would call windows in VS).
1) The main (starting) view would have a Toolbar at the bottom which opens any of 3 views.
2) View A would have a Nav bar at the top for "Cancel" and "Done" which would return to Main.
3) View B would have a Nav bar at the top for "Back" which would return to Main
4) View C would have no Nav bar but would return to Main using a DoubleTap.
I'm finding it very confusing to piece this together without a straightforward example.
Where can I find some clear explanations of Views vs Controllers, what they're each used for, and how to use them, preferably with examples/tutorials/etc?
Online is best, books are fine.
I'm using Xcode 4.2, no storyboards (for ios 4.2 compatibility).
Thanks.
The general distinction between view controllers and view is something that you can understand independently of Xcode/Cocoa - it's a design pattern called MVC (Model, View, Controller).
In MVC, your application structure is split into 3 layers:
1) The model is your data layer, such as files, databases, network services, and objects that exist independently of the display such as a user.
2) The view is what you see on screen. A view is often composed of several sub views in a hierarchy, for example a window (which is a type of view) contains a toolbar (another type of view) and some buttons (each a view), labels, text fields, etc. These are all views.
3) The controller, aka view controller is the glue that connects these two together. A user object for example has no idea how to display itself, and a label has no knowledge of a user object, so it is the job of the view controller to tell a particular label to display the name of a particular user. Similarly when you type text into a text field, the text field doesn't know that text is a password, so it's the job of the controller to take that text and store it in the correct place, or submit it to the correct web service, or whatever.
So basically a controller converts your model data into the right format to display within your views, and handles feedback from your views (a button press, a text entry, etc) and modifies your model accordingly.
In cocoa every view controller owns a main view (it's "view" property) and may also manage the subviews of that view such as buttons, labels, etc.
Normally there is one view controller class per screen of your app. Occasionally parts of your screen that have standard behaviours are managed by other view controllers.
So for example the navbar is managed by something called a navigation controller. A navigation controller actually manages a stack of view controllers as well as the navigation bar view itself. When you push or pop a view controller onto the navigation controller stack, it makes sure that the view from the current view controller gets displayed and that the navbar shows the correct title. When you tap the back button in the navbar view, the navigation controller receives that button event and pops the current view controller (and it's associated view) off the stack.
The advantage of this approach (MVC) is that is massively cuts down on the amount of subclassing you need to do. Every button on your screen is probably just an instance of a standard UIButton object. You don't need to subclass each button just to change it's behaviour because the button doesn't need to know anything about what happens when it is pressed, it just delegates that press to the view controller to manage.
Generally, you rarely need to create custom view subclasses. Almost all of your application can be built by arranging standard views on a screen and managing them with a custom view controller subclass.
Nibs/xibs are particularly useful for this because they let you visually lay out your views and visually bind their actions (e.g. button taps) to methods on your view controller using drag a drop. This saves you filling up your view controller with pointless layout code (create a button with these coordinates and this colour and attach it to this subview, etc). Unfortunately nibs can be confusing for new developers because they hide a lot of what is going on behind the scenes.
For multi-screen apps, iOS provides a set of so-called container controllers, which are controllers that manage multiple sub-controllers. UITabBarController and UINavigationController are the main examples. UITabBarController is good if you have several screens that you want to tab between, UINavigationController is good if you have a hierarchy of screens that the user can go back and forth between like a browser.
I have a uisplitviewcontroller which loads a UIWebView as its detail view. I would like to allow the use to hide the RootViewController so that they can use the detail view controller in full screen.
The behavior is similar to that used by the Dropbox application. I'm not sure how to get this done. I've tried creating a new view controller and copy the webView, but there are issues whenever the user zooms the web view.
You can customize the default split view only to a certain level..
Here are some related questions from SO:
Hiding master view in split view app..???
Ipad Split view controller
but i think you've already read them.
I would suggest you to create your own custom controller as the default split view has very limited functionality.
You can look at MGSplitViewController. It is a really good custom implementation similar to the UISplitViewController with much more flexibility.
I'd like to display some small tutorial dialogs on top of my exiting views. I want to be able to see my existing views behind these smaller views.
Do I have to use view controllers in the same I way I would me normal views, and presentmodalviewcontroller etc ?
I haven't tried making a smaller view in interface builder before.
Also, say I want to move to another one of my existing views, full screen, while in my tutorial view. How would I close my tutorial view move to the next full screen view and launch another tutorial view ?
Example code or pseudo code would be welcome.
If your tutorial dialogs are just text, you could use UIAlertView to show the information to the user, so they can just read it and click the OK button when they're done. It's a very easy way to show some text to the user.
If you need to include images or other interactive items in your tutorial dialogs, the easiest way might be for you to just have your fullscreen view's view controller create a new view and put it up. So in this case, you'd create your view in Interface Builder, and when you want to show it, instantiate it using -[UIBundle loadNibNamed:owner:options:] and add it as a subview of your main view. Of course, it may even be easier to create the tutorial view programmatically from your view controller rather than using a nib for them at all.
Regarding the question of moving on to another fullscreen view, you would probably want to look into embedding your view controllers in a UINavigationController. This would allow you to push from the first controller to the second very easily, and the user would be able to just tap the Back button to get back to the first. If you're not looking for a navigation bar type of interface, you could present the second view controller as a modal view controller by calling -[UIViewController presentModalViewController:animated:] on your main view controller. This will pop up the second view controller fullscreen, and the user can dismiss it when they're done. Check out Apple's great documentation on UINavigationController to get a feel for how to use that:
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html%23//apple_ref/doc/uid/TP40007457-CH103-SW1
I would think that you could use existing UIViewController and simply add a new UIView that is of desired dimensions, that sits in front of other views and which is non-opaque and has alpha less than 1.
If you want a general purpose tutorial mechanism that can be placed atop any one of many UIViewControllers, then you would want to extract the navigation logic, etc.
Sorry, no code - just a few quick thoughts.
I have this problem, I've got a navigation-based application, and on the one of the detail view i need to have UITabBar, which will display some UITableViews. Since apple documentation says "you should never add a tab bar controller to a navigation controller" it make quite a problem, i've found this sample: link text, it's working, but after picking one of the table view, the UITabBar disappears.
don't use a tab bar controller, just use a UITabBar inside your controller view and manage the switches between UITableViews yourself, either by:
loading up as many table views as you
need and stacking them (bringing the
one corresponding to the tab bar hit
to front)
switching a single table view's data
source and delegate among a few
helper objects - one per tab in your
bar. When the user clicks a tab, reset the single table view's data source then instruct it to reloadData
Now that you are not using a TabBarController for showing the tableviews (as mentioned in the link), have you made sure that the table views or any other views you are adding when a tab is tapped are correct size?
You are adding a subview or bringing it to top so the table view is probably covering your tab bar.
When they are choosing an item from your table view are you pushing a new view controller onto your navigation controller? If so, you will leave the tab bar behind!
Without some hefty hacking, you generally can't do what you're trying to do. What you'd have to do instead is to deal with adding new views yourself when a table cell is selected so the new views you add don't overlap the tab bar at the bottom. Though this will probably break the navigation controller.
Though my advice is to rethink that part of the app's ui so you don't care that the tab bar vanishes. Sorry :(