Finally got these patches merged in. Thanks for spearheading this Kevin!
On Thu, Nov 8, 2012 at 5:00 PM, Kevin Hawkins < [email protected]> wrote: > I'll add the corresponding JIRA tasks, and put some pull requests together. > Not a lot of code changes involved. > > Thanks, > Kevin > > > On Thu, Nov 8, 2012 at 12:50 PM, Shazron <[email protected]> wrote: > > > 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. > > > > > > > > > >
