Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of shazron@gmail.com designates
 209.85.160.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMNA1nhOYuHsTnEC0dOOjF+5W-OZXzkE8viLF=TpZoyCMJjM9A@mail.gmail.com>
References: 
 <CAMNA1ngp88wrr1BHLL-g++TAU61BK47YFs5LeA9JsMOCdrmkWQ@mail.gmail.com>
 <CAE6O_-ZfrdoiJaP5XhKfSq+dLY=FSJ4Zwb+iHgvvGEVeTQoM5A@mail.gmail.com>
 <CAMNA1nhOYuHsTnEC0dOOjF+5W-OZXzkE8viLF=TpZoyCMJjM9A@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Thu, 8 Nov 2012 12:50:14 -0800
Message-ID: 
 <CAE6O_-abSnfsJDu_zdA_a5h60+BpMqW2iztXxUBRWsg81k7PxQ@mail.gmail.com>
Subject: Re: iOS: Can we clean up the view lifecycle in 2.3?
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b33d07ec2dd8d04ce01fd8d

--047d7b33d07ec2dd8d04ce01fd8d
Content-Type: text/plain; charset=ISO-8859-1

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.
> >
>

--047d7b33d07ec2dd8d04ce01fd8d--