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 Wed, 21 Nov 2012 19:35:10 GMT
Finally got these patches merged in. Thanks for spearheading this Kevin!


On Thu, Nov 8, 2012 at 5:00 PM, Kevin Hawkins <
kevin.hawkins.cordova@gmail.com> 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 <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