Sorry, I realize after the fact that my email wasn't particularly helpful, without specifics. So here's an outline of my initial audit of the view/view controller/app delegate code. For the record, I'm working against HEAD of the repo, as far as what version of Cordova I'm considering.
1. App template's AppDelegate: the forceStartupLocation logic in application:didFinishLaunchingWithOptions: is not necessary. An iOS app will default to a supported orientation at startup, if the current orientation is not supported. 2. CDVCordovaView inherits from UIWebView. Apple's documentation explicitly says not to inherit from UIWebView. 3. [CDVViewController __init] sets its wantsFullScreenLayout property to YES. This explicitly tells the view controller to ignore the layout of the status bar. This one took hours to track down. :( This should not be the default behavior of a Cordova app, and is the stemming point for all of the issues around having to manually deal with the position/spacing of the status bar, specifically around having to set an explicit view frame for the main view. The explicit frame setting, in turn, was affecting view layout when using (and specifically, dismissing) modal view controllers. After turning this off (or I should say removing the assignment; default iOS behavior has this property set to NO), it becomes no longer necessary to explicitly set self.view.frame anywhere; [MainViewController viewWillAppear:] can go away entirely. The list is shorter than I thought, which is good. :) I think I had blown it up in my mind a bit, with the amount of trouble I was having with the status bar and view frame, relative to the complete lack of trouble I was having with it in other iOS apps. I didn't get too much into the splash screen stuff. As implemented, I can see that the property should be set to NO in the event that Cordova is being used as a component, as it sets subviews outside of the Cordova view hierarchy. Seems reasonable, though. Also, in [CDVViewController showSplashScreen], the self.imageView.autoresizingMask setting is probably not what it's supposed to be; those values should be bitwise-ORed together, not bitwise-ANDed. The net effect at the moment is going to be that the autoresizing mask has a value of UIViewAutoresizingNone. That's all for now. :) Cheers, Kevin On Tue, Nov 6, 2012 at 12:39 PM, Shazron <shaz...@gmail.com> wrote: > I can create a native application in iOS today using Apple's most basic > > > template, create a UIViewController subclass from there, programmatically > > manage my UIView and UIWebView, get full rotation and status bar > > management, and all of this with literally half a dozen lines of custom > > code or less. There's no fussing with autorotation, outside of initial > > configuration of supported modes. There's no managing the status bar > when > > determining the frame. There's no setting of the default view's frame at > > all, in fact: it defaults to the size of its superview (the UIWindow in > > this case), and automatically adjusts to the status bar. The status bar > > rotation is self-managed too. > > > > I don't see these problems you are seeing. Are you using 2.2.0? There is no > setting of the frame, it uses the screen bounds (see > AppDelegate.m). Autorotation is managed as well. The default template > dog-foods using Cordova as an embedded WebView as specified in the docs - > although the doc is outdated where it has to set the frame, the template > uses it differently in AppDelegate.m. We will have to update the doc. > > > > Conversely, all of these things are custom-managed and complicated in the > > CDVViewController and its related counterparts. And they don't play by > the > > rules of standard iOS behavior. You have to employ weird, wonky code to > > adjust the view to be under the status bar...conditionally. > Autorotation > > doesn't work if you present a view controller; you have to use wonky code > > to reset the parent view controller in its viewWillAppear as well, once > the > > modal vc has been dismissed. > > > > I've never seen that problem anymore though in 2.2.0 (statusbar over the > view) - only saw that with one of your pull requests that got fixed with > some other code (to be honest I don't know what was going on there). That > problem (reset parent viewcontroller) is fixed with this bug fix in 2.2.0 > https://issues.apache.org/jira/browse/CB-1465 -- the viewcontroller size > is > only set once in that case. > > I don't know if the required manual management of these things is a legacy > > of older versions of iOS. But I know that that requirement is older than > > our oldest supported version of iOS. That stuff is difficult to maintain > > and extend, and I'd venture that 80% of it needs to be done away with, > > outright. > > > > Some of it is 3 year old code, so there might be inertia there. > > > > I'll probably save the splash screen for another post, though it's > related. > > I turn that thing off by default in every app, because if its tenuous > > working condition across CDVViewController deallocations and > > re-initializations. And it's another item whose existence I can't > > understand outside of legacy considerations that no longer apply to our > > base iOS version. > > > > The existence of the splashscreen is a hack to hide the white flash that is > generated when the UIWebView starts up. If we solve that, we can do away > with the splashscreen. Our splashscreen implementation is to "extend" the > length of time for the splashscreen that is loaded automatically by iOS to > fix the aformentioned problem. >
