cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: iOS: Can we clean up the view lifecycle in 2.3?
Date Thu, 08 Nov 2012 21:39:35 GMT
Yeah, really nice findings here Kevin!


On Thu, Nov 8, 2012 at 3:50 PM, Shazron <shazron@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.cordova@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 <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