I have a very very old iPhone/iPad app, actually it was my very first Objective-C app, I started learning iOS programming on it. Now I want to update it a bit but have following problem:
The app has never had any viewController. When I started writing it, I wasn't familiar with MCV and Interface Builder. First version was just for iPhone and it made the UI manually by just positioning UILabels and UIButtons in UIApplicationDelegate's didFinishLaunchingWithOptions via addSubview directly into self.window (there is MainWindow.xib but it's empty). A couple of months later I created iPad version. It has all the UI created in Interface Builder in a single MainWindow_iPad.xib. There are no other xibs, just UILables and UIButtons placed directly in MainWindow_iPad.xib and no view controller was used again.
Now, a couple of years later, I want to update this veteran app a bit. I want to add a root view controller so I set window.rootViewController in UIApplicationDelegate's didFinishLaunchingWithOptions. I have no problem with the iPhone version, it works a treat. But I have troubles with the iPad one. After setting window.rootViewController, the app doesn't interact to any touch at all. It loads, the UI is created but it's just frozen.
Any idea what could be wrong? Thanks a lot!
Don't tell me I should throw it away and write it again from scratch in a normal "experienced way", I know this would be the best way but I don't need to update it that much to waste so much time.
Related
I have created two UIViewControllers in IB.
PROBLEM 1: I can't make the 2. VC transparent.
I have read a lot of stackOverFlow solutions but nothing seems to work in my case.
I have tried the following setup in IB both in my current project and in this simple project and something strange occurs (IB,for 2.VC):
Setting the alpha value below 0,5
Setting opaque to "checked"
Setting the background color to "black"
https://imageshack.com/i/kqdXWk9Jp
The second VC gets pushed when I click "GO TO NEXT VC" (push or modally , doesn't matter) and while he is being pushed I see the the result I want:
https://imageshack.com/i/idXUCFCPp
... and when the push is finished the new VC changes from being transparent to black (not transparent):
https://imageshack.com/i/iqmLw8D1p
I have no clue why this is happening and I cant get it to stop working like that.
Q1: Why is this happening?
Q2: Why can't I change the properties of the views programmatically when the views are created with IB?
I have done this thousand times WITHOUT using IB. As soon as I start using IB things don't work like they are supposed especially when I try to edit stuff programmatically.
When I do all of these steps without IB only in code everything works perfectly fine but I need to use the IB in my next project. I am using Xcode 5.1.1. on mac mini (late 2009) with Mavericks.
Sorry for bad English.
Your problem is because the memory management of iOS removes the previous interface ViewController, to save resources.
After iOS7, you can customize the transition viewControllers. Please read: UIViewControllerAnimatedTransitioning Protocol Reference.
I also had the same problem and managed to solve it by following the tutorial Custom UIViewController Transitions.
If you are still having doubts, there is another tutorial to help you: iOS7: Custom Transitions.
Hope you get success!
After a number of tests I found that a normal working iPad storyboard starts working weirdly upon introducing auto-layout. In particular it seems not to properly pop-up dismissed views by always recycling the same view controller and to also badly handle the queue of instantiated view controllers. When I disable auto-layout everything works fine again. Does anyone know if this bug is known to Apple or there is a fix?
Not been able to complement the question with new information, I posted a new one at:
Triggering segues from annotations
I am coming from iOS background and starting to learn Cocoa. On iOS unless we have multiple targets for iPad and iPhone we usually have one Window and manage the screen using UIViewControllers. Where every new screen will most of the time will map to a UIViewController.
However on cocoa this seems to be the otherway around where a new screen/window is manage by NSWindow and it's subcomponents are managed by NSViewController. So if I have multiple window app I should have separate NSWindowController for each window.
Is this approach correct or am I having a misunderstanding ?
With iPhone SDK and Leopard SDK, they introduced view controllers, or NSViewController and UIViewController. As their names suggest what they do is to manage views
The view controllers are for managing views. Current trend in UI design is Single Window, Multiple View. What it means is that there is one Window and inside of it, different group of views designed for different purpose can be swapped in and out. So, the View Controllers handles these for programmers for well-established pattern.
Currently view controllers are very important for iPhone and iPod touch programming, because the platform is based on Single-Window and Multiple View model. However, it doesn’t seem to me that using view controller is very popular for Mac.
how about the window controller like NSWindowController? Its counterpart, UIWindowController doesn’t exist for the iPhone and iPod touch environment, because there is only one window for those environment.
Unlike view controllers, the NSWindowController is for document based programs. Well, document based program can use multiple window. So, it is reasonable to think that NSWindowController is for document based programs as Apple’s document says.
I also come from iOS and started coding Mac apps a while ago, learning mostly from Apple's documentation.
My impression is that on the desktop, you almost never need NSViewControllers (one big exception would be a window with tabs and multiple views, like the GarageBand welcome screen).
Most of the time you have one NSWindowController per window. Learn first the relation between NSWindow and NSWindowController (and NSDocument, if you are making a document-based app).
Once you got that right, start experimenting with NSViewController.
UPDATE: It seems that since the introduction of storyboards for mac apps too, Apple expects that most of the view presentation logic should be migrated from the older NSWindowController to the newer NSViewController, more in line with how an iOS app is structured. I am not very knowledgeable on exactly where to draw the line, or what kind of code should remain in the window controller (or whether it still needs to be subclassed at all).
A Window Controller creates a traditional window and has all the traditional APIs.
A View Controller can also be shown outside of another view. It then gets a window frame but does not support the full traditional Window Controller API.
In addition to custom, modal, and show, a View Controller can also be presented in the modes sheet and popover.
So, View Controller has more presentation options and a more streamlined API but probably a few limitations in cases that are covered by the traditional Window Controller.
I have been learning iOS development for a few days now. At this moment, I have questions over how the rootViewController is to be used. I searched the web for 3 hours yesterday looking for the answer which turned up quite a few results that never really answered my question.
I am trying to learn to program an app using code only (no storyboards/xib files). I currently am trying to understand how to properly switch between views without using the UINavigationController. In my project I have the main delegate which creates the window, initializes my main view controller (which loads the separate view as well) and adds it as the rootViewController.
My first view has a button which calls a function in its controller to switch to my next view. Here is where my question arises: Do I switch the main rootViewController to the next view or do I load the next view as a subview of the rootViewController? Is the rootViewController supposed to encase all the views for an application? (I think this is how the UINavigationController works)
I have gotten switching of the rootViewController to work in my app, but I want to make sure there isn't some other way I am suppose to manage my views.
I would not switch the rootViewController, I think that should remain stable. So you could add it as a subview, or you can present it as a modal view.
And of course, you can just change the rootViewController to point to your new view if that's how you want to do it.
I’ve borrowed the Whereami code found in The Big Nerd Ranch iOS book and used it in the app I’m writing. My app determines the user's location and displays it in a map in the app delegate, just like Whereami app in the book does. The UIWindow is made visible and displays the map correctly. From this point on, the code is my own.
My app allocates a UINavigationController, sets the root view controller, and proceeds to allow the user to view other view controllers and perform other methods after navigating to them.
At some point, a view controller contains a button labeled “MAP” that, when pressed, should display the map showing the user’s current location.
How can I get the app to display the UIWindow that is in the AppDelegate.m? I assume the app delegate is continuing to determine the user’s location, and I want the user to have the ability to display the map at will.
My current code allocates a MapViewController when the “MAP” button is pressed, but I can’t figure out how to get the UIWindow which is in the AppDelegate.m to display.
I’m thinking I should be able to do it by having a pointer to the UIWindow in the MapViewController. Is this the right approach? Do I need anything else? I'm using Xcode 4.0.2, Snow Leopard, and testing on an iOS 4 device. I'm new at this, and I don't want to get confused by upgrading to Lion, a higher Xcode, or iOS 5 yet.
Consider using presentModalViewController:animated: (it's a method on all instances of UIViewController and its subclasses). There are a variety of transition styles you can use, like a flip or a fade.
On iOS you very rarely work with UIWindow objects. You pretty much set one up when your app launches and you leave it alone. Everything is done with UIView instances or the UIViewController instances that manage them.