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.
