Thanks Kevin, this is great :) Once I have time I can put these into JIRA tasks or if you are inclined to file them as well, that will be great.
On Thu, Nov 8, 2012 at 11:47 AM, Kevin Hawkins < [email protected]> wrote: > 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 <[email protected]> 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. > > >
