cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Hawkins <kevin.hawkins.cord...@gmail.com>
Subject Re: iOS: Can we clean up the view lifecycle in 2.3?
Date Thu, 08 Nov 2012 19:47:05 GMT
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 <shazron@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message