I've heard Facebook and Google do not use UIStoryboards or nibs because they are difficult to merge – they format all their views programmatically. Are there any resources out there that can provide some guidance as to how best to position assets, handle localization, organize files, etc., when creating all your views without nibs?
The first step would be to create an UINavigationController or a UITabBarController within the AppDelegate's didFinishLaunching method, where you should set the rootViewController for the current UIWindow ([window setRootViewController:]).
Then you just have to create your content viewcontrollers and views. Let's say you want to create a menu, then you should create a MneuViewController which inherits from UIViewController and a MenuView which inherits from UIView. Within the MenuView code you create your view components like labels, textfields or whatever you need. In the MenuViewController you create an instance of the MenuView class and call [self setView:] with that object. Finally you have to add the ViewControllers to your rootViewController.
The AppDelegate should look similar to something like this:
- (void)applicationDidFinishLaunching:(UIApplication *)application {
MenuViewController *mvc = [[MenuViewController alloc] init];
UINavigationController *rootViewController = [[UINavigationController alloc] initWithRootViewController: mvc];
[self.window setRootViewController: rootViewController];
[self.window makeKeyAndVisible];
}
Localization has to be done using the macro NSLocalizedString() for which you should find a lot of samples.
Files should be handled using NSFileManager.
For eveything else you should ask more specific questions.
Related
Right now I'm attempting to integrate this library with an existing app. However, the app already has a rootViewController. Is it possible to simply redirect the frontView this library requires to the current rootViewController that the app has? All I need to implement is the ability to swipe between the rearViewController and the frontViewController like in the first example the library gives.
Yes, but then you need to set the SWRevealController as the new rootViewController.
Here's some sample code to illustrate from application: didFinishLaunchingWithOptions: in your app delegate:
MYAppViewController *mainVC = [[MYAppViewController alloc] init];
// Before using SWRevealViewController I had this line:
// self.window.rootViewController = mainVC
// Used for the rear view of the SWRevealViewController
MYMenuViewController *menuVC = [[MYMenuViewController alloc] init];
SWRevealViewController *revealVC = [[SWRevealViewController alloc] initWithRearViewController:menuVC frontViewController:mainVC];
// Now set the SWRevealViewController as the root view controller
self.window.rootViewController = revealVC;
Just make your rootViewController class inherit from SWRevealViewController, then you wont need to wrap anything.
read the Documentation it explains what to do. You don't need to wrap anything.
I have created a .xib file containing a UITabBar with 5 UITabBarItems inside. I would like 4 of the 5 tabs to link to the same UIViewController class since they have the exact same interface (only the data differentiate their looks).
Therefore it makes sense for me to instantiate my UIViewController 4 times, once per tab bar item. And then link each one of the UITabBarItems of the .xib with one instance of my UIViewController.
But I cannot figure out a way to take a reference of my xib tab bar items in my UIViewController and send the setTabBarItem message. How could I achieve that ? I was trying somehow to pass the .xib tab bar items on init (overwriting the init) but I didn't manage to reference them. I instantiate the controllers in the AppDelegate after the self.window stuff.
(If I say something weird here, not making sense with the usual iOS programming conventions, please let me know)
Use UITabBarController for this , not sure what you exactly want to do with the same UIViewController but UITabbarController will definitely work;
UITabBarController *tabBarController = [[[UITabBarController alloc] init] autorelease];
ViewController *viewController1 = [[ViewController alloc]initWithNibName:#"ViewController1"];
ViewController2 *viewController2 = [[ViewController2 alloc]initWithNibName:#"ViewController2"];
tabBarController.viewControllers = [NSArray arrayWithObjects:viewController1,viewController1,viewController1,viewController1,viewController2,nil];
self.window.rootViewController = tabBarController;
What i'm doing is this:
UIViewController *rootController = [[[UIApplication sharedApplication] keyWindow] rootViewController];
AlarmRingViewController *alarmController = [[AlarmRingViewController alloc] init];
[rootController presentViewController:alarmController animated:YES];
What i want to achive with this, is to push my AlarmRingViewController on top of any other controller which is displaying at the moment and it works so far.
Now im wondering if this is good practice:
to instatiate a new viewController each time it should be presented
do so in a non UI related class? (in my case a scheduler for NSTimer)
from there push the newly created viewController with the rootViewController on top
Or does this violate the MVC pattern or Apples guidelines or anything.
cheers
Personally I think it's ugly code. It's hard to read and hard to debug. Split the code up a bit:
UIViewController *rootController = [[[UIApplication sharedApplication] keyWindow] rootViewController];
AlarmRingViewController *alarmController = [[AlarmRingViewController alloc] init];
[rootController presentViewController:alarmController animated:YES];
There is no benefit to typing so much into one line.
Update: Based on your updated question:
There is no problem instantiating a new view controller each time you need it. This is very common. It might be appropriate to create one and cache it. This is an optimization that could make sense if only one of the view controllers is every shown at any given time, the view controller is used very often, and it takes a lot of time to create.
View controllers are usually created and presented by other (view) controllers.
Why don't you just use a UINavigationController as the root view controller. That way, you can just do this:
AlarmRingViewController *alarmController = [[AlarmRingViewController alloc] init];
[self.navigationController presentViewController:alarmController animated:YES completion:nil];
My application starts off with nothing but a UIWindow. I programmatically add a view controller to self.window in application:didFinishLaunchingWithOptions:.
myViewController = [[UIViewController alloc] init:...];
...
[self.window addSubview:myViewController.view];
[self.window makeKeyAndVisible];
At the same time i kick off a background process:
[NSThread detachNewThreadSelector:#selector(startupOperations) toTarget:self withObject:nil];
The startupOperations look something like this:
NSAutoreleasePool *threadPool = [[NSAutoreleasePool alloc] init];
// Load data
...
// When your done, call method on the main thread
[self performSelectorOnMainThread:#selector(showMainViewController) withObject:nil waitUntilDone:false];
// Release autorelease pool
[threadPool release];
showMainViewController removes myViewController, creates a UITabBarController and sets it as the window's main view:
[self.myViewController.view removeFromSuperview];
self.myViewController = nil;
tabBarController = [[UITabBarController alloc] init];
...
[self.window addSubview:tabBarController.view];
[self.window makeKeyAndVisible];
Questions:
All the view controllers are returning YES for shouldAutorotateToInterfaceOrientation:. Rotation works fine for myViewController but as soon as the tabBarController is made visible, rotation stops working and interface appears in Portrait. What's the reason behind this behavior?
Also, in iOS 4.x, UIWindow has rootViewController property. What's the role of this property? The new templates use rootViewController instead of [self.window addSubview:...]. Why is that?
Pretty strange. I tried and simulate your "view flow" in a simple tab bar based project and autorotation effectively works after removing the initial controller and adding the tab bar controller's view as a subview.
The only condition I found where it did not work is when self.window did contain a second subview that I did not remove. Could you check at the moment when you execute
[self.window addSubview:tabBarController.view];
what is self.window.subview content?
If that does not help, could you share in your question how you initialize the UITabBarController and UITabBar?
As to your second question, as you say rootViewController is the root controller for all the views that belong to the window:
The root view controller provides the content view of the window. Assigning a view controller to this property (either programmatically or using Interface Builder) installs the view controller’s view as the content view of the window. If the window has an existing view hierarchy, the old views are removed before the new ones are installed.
(Source)
You can also use that, but take care of assigning it already in applicationDidFinishLaunching, otherwise, if you "manually" add a subview and later change this property, it will not remove the subview you explicitly added.
I am trying to display a UISplitViewController presenting it as a Modal View Controller in my iPad app. I manage to have it display, but for some reason there is a gap to the left of the modal view the size of a Status Bar which is also preserved when the orientation is changed.
Does anybody know why this is happening? Or if this is even possible? Maybe I'm just digging myself a huge hole.
Like for many of you, I needed a 'modal way' to use the UISplitViewController. This seems to be an old issue, but all I found in StackOverflow was at best an explanation why the problem happens when you attempt to do so (like the accepted answer above), or 'hack-arounds'.
However, sometimes it is also not very convenient to change much of your code-base and make a UISplitViewController the initial object just to get it's functionality up and running.
In turns out, there's a way to make everybody happy (including Apple guidelines). The solution that I found best, was to use the UISplitViewController normally, but when needed to be shown/dismissed, use the following approach:
-(void)presentWithMasterViewController: (UIViewController *) thisMasterViewController
andDetailViewController: (UIViewController *) thisDetailViewController
completion:(void(^)(void))completion
{
masterViewController = thisMasterViewController;
detailViewController = thisDetailViewController;
[self setViewControllers:[NSArray arrayWithObjects:masterViewController, detailViewController, nil]];
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
self.window.autoresizingMask = UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleHeight;
self.window.rootViewController = self;
[self.window makeKeyAndVisible];
if(completion)
completion();
}
-(void)dismissViewControllerWithCompletion:(void (^)(void))completion
{
self.window = nil;
masterViewController = nil;
detailViewController = nil;
if(completion)
completion();
}
Where "window", is a property of your UISplitViewController subclass. And the system will take care of the rest!
For convenience/reference, I uploaded this as a UISplitViewController subclass to gitHub:
ModalSplitViewController
--EXAMPLE ON HOW TO USE --
mySplitViewController = [[ModalSplitViewController alloc] init];
mySplitViewController.delegate = self;
[mySplitViewController presentWithMasterViewController:masterViewController andDetailViewController:detailViewController completion:nil];
// when done:
[mySplitViewController dismissViewControllerWithCompletion:nil];
mySplitViewController = nil;
Side-note: I guess most of the confusion originates from the fact that
the UISplitView usage example from Apple documentation uses the window
created in the appDelegate, and for the fact that most people are not
so familiar with the window concept - because we normally don't need
to (they are created once in StoryBoards or boilerplate code).
Additionally, if you are doing state restoration, one should not
forget that programmatically-created UIViewControllers won't
automatically be restored by the system.
The stock UISplitViewController was designed for use as the root view controller only. Presenting one modally goes against the Apple Human Interface Guidelines and has a high probability of getting rejected by the App Review Team. In addition, you may receive the error:
Application tried to present Split View Controllers modally
Technically, this is what I did:
1/ Subclass a UIViewController ie. #interface aVC: UIViewController
2/ In the viewDidLoad, set up a splitViewController, ie. aSplitVC
3/ Then self.view = aSplitVC.view
After all, present aVC as modalViewController
I agree with Evan that this is slightly off-color for Apple, but I was able to complete a working version of this with the following solution:
UISplitViewController *splitVC = [[UISplitViewController alloc] init];
splitVC.delegate = VC2;
splitVC.viewControllers = [NSArray arrayWithObjects:navcon1, navcon2, nil];
UINavigationController *splitNavCon = [[UINavigationController alloc] init];
splitNavCon.modalTransitionStyle = UIModalTransitionStyleCoverVertical;
[splitNavCon.view addSubview:splitVC.view];
VC2.splitParentViewController = splitNavCon;
[self presentViewController:splitNavCon animated:YES completion:nil];
This allowed me to have a working back button in the new UISplitViewController that was presented modally on the screen.
You'll notice that I actually pass the VC2 (the delegate of the UISplitViewController) its parent UINavigationController. This was the best way that I found I could dismiss the UISplitViewController from within the VC2:
[splitParentViewController dismissViewControllerAnimated:YES completion:nil];
I believe one can do the other way around: instead of custom controller presenting split controller, one can set up the split controller as the root window controller in storyboard, and on top of its view you can add your custom controller (ie, login screen) and remove it from the screen (removeFromSuperview for example) when it is needed.
That answer is not actually correct, because it not valid any longer since iOS8 and if you need to support even iOS7 you can do that like you put actually modally UIViewController which has a container as SplitView.
let mdSplitView = self.storyboard?.instantiateViewControllerWithIdentifier("myDataSplitView") as! MyData_SplitVC
self.addChildViewController(mdSplitView)
mdSplitView.view.bounds = self.view.bounds
self.view.addSubview(mdSplitView.view)
mdSplitView.didMoveToParentViewController(self)