I'm new to iOS development, obviously, and I'm running into a bit of an issue with many of the tutorials that I find online. While I understand the majority of the code that is going into these programs, I cannot figure out how to translate this one fact, which is probably simple.
Many tutorials either use the Navigation-based template or View-based template, but I would like to try building tab bar applications. Tutorials either use the App Delegate or rootViewController (being the navigation controller), but since my tab bar is my rootViewController, I always run into an issue. I'm also unable to use the applicationDidFinishLaunching method in most of my code, because it technically only applies to the first tab at launch.
These are my questions:
Is there a way to "translate" these files into new classes (for example, creating an instance of NSObject for the App Delegate code for each individual tab or creating instances of UINavigationViewController)?
If I can create the instance of NSObject, how do I ensure that the code links up to the objects that I create in my viewController?
If I can create a file that uses UINavigationController, how do I trick the program into temporarily allowing the Nav Controller to be the rootViewController.
Many thanks in advance!
Right off the top of my head, I can only answer number 3 for you, you could do that in one of two ways that I am aware, and if anyone sees either of these is incorrect or bad practice, I hope someone corrects me, as this is what I have been doing.
[appDelegate.window addSubview:appDelegate.newRootViewController.view];
appDelegate.window.rootViewController = appDelegate.newRootViewController;
or
[self.navigationController pushViewController:appDelegate.newRootViewController animated:YES];
Both should accomplish the same thing, though if you can help it, the second version is ideal. Its also worth noting that for the first one, there is no tricking, you are actually setting the rootViewController of your app to something different.
I'll do some digging and see if I can answer any of your other questions for you too.
Edit: So after re-reading and thinking a bit more about it, I think the other two questions can be answered by maybe clarifying a tab bar application. Unfortunately, I'm fairly new to iOS as well, and I haven't had to opportunity to create a tab bar application, so I don't want to give you incorrect info. I would recommend checking out http://www.techotopia.com/index.php/Creating_an_iOS_4_iPhone_Multiview_Application_using_the_Tab_Bar_%28Xcode_4%29 and hopefully it can give you a little bit of a better idea of how Tab Bar Apps work. I've been using that eBook along with another from that site combined with Ray Wenderlich's tutorials to teach myself.
Anyways, I hope this helps to some extent, if you want me to try to clarify or go into detail on anything just comment and I'll see if I can help.
Good Luck!
-Karoly
You're misunderstanding how the app delegate works.
It's the delegate for the application, not a controller. Your controllers may be loaded from a xib by the time applicationDidFinishLaunching is called, but there's no connection between the two events.
applicationDidFinishLaunching is just the place where you do final setup before the app is ready for use.
If you don't instantiate your tab bar controller in your main xib file, you can instantiate it here, then instantiate all of it's controllers and add them to to the tab bar controller. While you're doing that, you can load plists, set properties on the controllers, etc.
If you do instantiate your tab bar controller in your main xib file, you can still get access to its controllers here. You can edit those controllers or throw them out and create new ones. You can even throw out your tab bar controller and switch to a navigation controller.
I can't answer questions 1 and 2 because the assumptions behind them are invalid.
Rather than ask how you work around perceived problems with the app delegate and tab bar controllers, describe what you're trying to accomplish.
Related
I have a Login interface, user interface, and a Main menu.
When I'm logging in, I switch on my user interface.
if I do a UIModalTransition, and if I come back to the page, I need to RE-login again, it's a problem for me.
I search a method for Switch between view but don't close them, because if you closed them, views restart, it's the same for UIWebview, I would like to switch between views without closed and reset views.
Is it possible ?
I don't really know what kind of Code is it.
If you have ideas, please tell me.
In this answer i tried to explain the view controllers orchestration as i see it.
The idea is to create the manager class taking care of elements storage and presentation. It also mentions the way to manage the login information.
You can use pushViewController ie..
[self.navigationController pushViewController:yourUserInterFaceViewController animated:YES]; for transition between login and user interface.
you can use 3 ways
1)pushing the view into UINavigationController
2)presenting the view with ModalViewController
3)adding subView to rootViewController and remove it using removeFromSuperView when needed.
(you can allocate them when app launches and access them using
[YourAppDelegate sharedApplication].yourViewController)
Since your appDelegate is a singleTon class it will always return the same viewcontroller you've allocated at the time of launching the app. You can use Lazy Load also.
May be this will help.
I am making a iPhone app, I am currently using iAd's in my view's. I've read something about apple recommending to share the adbanner's through out the view's. How can i do this because I have read the apple documentation and it was not clear enough and i was confused, please help me, if their are any tutorials please tell me or just answer and point me in the right way. Currently I have a ad for every view controller and it runs nice but it comes with a error: Too many active banners (10). Creation of new banners will be throttled.
Please help, i am using storyboards and the latest Xcode :) thanks
The way I do it is use a Singleton class that creates the adView, this way you only ever get 1 adView. Then in your viewDidAppear methods of all your ViewControllers you simply add the adView to your view.
You can see my code in the accepted answer here although that is for an AdWhirl ad view, it shouldn't be too difficult to change it for an iAd ad view.
This is the perfect case for a singleton. Many have simply made a subclass of ADBannerView, which can then be added to your view in -viewDidLoad (or -viewDidAppear with the proper precautions taken) and removed in -viewDidDisappear for each View Controller.
Now,I gonna Develop an App ,which wants to switch from many different Views irregularly,also the views need to load large resources,AKA,it's hard to manage memory.Are there any good solustion?
PS：I created a ViewController as RootViewController,and When a button was Touch,run the code as
"ViewController=newController"
.The problem came,The new View loaded wrong way,it rotate so that couldn't show in a correct way.
I google for the solution,some one said ,I should replace the rootViewController,just like that,
[UIApplication sharedApplication].delegate.window.rootViewController=newController;
But I can't get/set the rootViewController in other class though it's a singleton.
Why not having a class that handles all the view switches ?
This article describes an architecture that might be helpfull: http://www.mikeziray.com/2010/01/27/handling-your-initial-view-controllers-for-iphone/comment-page-1/#comment-607
Short version
If I'm writing my own custom split view controller, what do I need to do to make the child view controllers work as expected?
For instance: to send viewWillAppear: and so on.
Long version
Background
A while back I answered the following question:
Switch between UIViewControllers using UISegmentedControl
With the following answer:
The right way to do it is to have the controller handling the UISegmentedControl add the views of the controllers as subviews.
[self.view addSubview:controller.view];
It's your responsibility to send viewWillAppear: and so on.
However, tc. pointed out that this is not as trivial as it sounds:
No. View controllers are not meant to be used like that - controller will miss out on a lot of the UIViewController magic that's taken for granted (namely -view{Will,Did}{Appear,Disappear}: and -shouldRotateToViewOritentation:).
By "magic", I'm referring to everything UIKit does behind the scenes. You also forgot -parentViewController (which is important for things like modal view controllers). Additionally, somewhere in the depths of UIKit, it automatically calls -viewSomethingSomething: for you, so you might get -viewDidDisappear: twice! (I can't remember the exact details, but there's another user reporting that all you need to do is call -viewWillAppear: and the other three methods happen automatically.) The key issue is that Apple doesn't document the "magic" or how it changes between OS updates.
Since then I've been thinking that one should compile a guide for what needs to be present in the parent view controller in order for the child view controllers to work as expected. Apple's documentation doesn't cover this and Google didn't help much either, so now I'm hoping to find this knowledge within the stackoverflow community.
I've written several controllers like this and they all seem to work, but I can't help but wonder if I'm missing out on important view controller magic.
I think the best solution is "don't do that". Instead of hoping that you can duplicate all of UIViewController's behavior without being rejected for using private API calls why not create non-UIViewController controller objects to manage your subviews? A "controller" is not necessarily a UIViewController.
At a minimum you would need to override or mix in replacement getters for parentViewController, splitViewController, navigationController, tabBarController, and interfaceOrientation (and probably also modalViewController). For each property you would need to make sure that any private setter called by UIKit still works as expected and any changes to those values made by modifying UIViewController ivars directly are also correctly reflected in your implementations.
You're also going to need to figure out how UIKit determines which UIViewController is currently active and should receive view controller lifecycle methods because you need to make sure that these are sent to your container view controller and not only to one of it's children.
You will also have to hope that you haven't just constructed a situation which isn't supported by any of Apple's view controller classes. For example will any of them break if they have a parentViewController but their navigationController, tabBarController, and splitViewController are all nil?
Finally you'll need to keep up with any changes to these private implementation details with every iOS release.
So I'm trying to use a UITableViewController (let's call it homeView) in my iPhone application to display a simple table with only a few rows of text which are loaded from an NSArray in the controller. I want to display the table in the grouped style in a subview of a subview (let's call it subSubView) of my main controller. When I try the following: [subSubView addSubview:homeView.view], my app crashes on launch. However, when I allocate the object without adding it to any views, it launches fine.
What's the best way (or rather a working way) to display the table generated by my UITableViewController?
There isn't enough to tell for sure what is going on, but if I had to guess I would think that you probably aren't retaining homeView. Normally I would say that as a comment to your question, since it is not really an answer, but I have a completely separate answer:
Just use a UITableView, not a UITableViewController. Instead of trying to embed a controller within a controller (which is quite difficult since Apple doesn't expose the necessary tools to actually modify the view controller hierarchy), just make the VC you are writing support the appropriate delegate/dataSource methods and directly create the view.
While it might make some logical sense to try to embed VCs inside of each other, with the exception of the builtin container VCs (UINavigationController, UITabBarController) it Really Doesn't Work™. The technical reason for this is that internally some of the event routing and messaging depends on parentViewController being correct, but since you can't set it (setParentViewController: is private) tons of latent bugs in UIKit start rearing their head. The internal collection classes can set the parentViewController correctly, so everything works right.
Also, one last thing. In your question you named your view controller homeView. Please, please on't do that. A view controller and a view are separate things, call it homeViewController. Aside from the fact that a lot of new iPhone developers get confused about what the distinction is, there is nothing more aggravating then tracing through someone else's code and realizing that something you are assuming is one type is another.