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 <shaz...@gmail.com> 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 < > kevin.hawkins.cord...@gmail.com> 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 <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. > > > > > >
