incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: Better Splash Screen?
Date Wed, 25 Apr 2012 15:48:40 GMT
Okay, I'm going to check in my change to 1.7 as:

a) It does not change the way developers setup a splash screen on Android.
b) It does not change the current behaviour.
c) It does not look any different.
d) It fixes CB-423: Problem displaying patch-9 splash screen
e) It provides the benefit that the html/js/css load while the splash
screen is display. Which is better than our current blocking splash screen.

If y'all think it shouldn't go into 1.7 I will revert the change.

Then I'll look at doing the <splashscreen/> tag for Android.

Simon Mac Donald
http://hi.im/simonmacdonald


On Tue, Apr 24, 2012 at 4:52 PM, Filip Maj <fil@adobe.com> wrote:

> I am a big fan of the WebWorks splash screen approach. Declarative and
> easy to understand. Everything you would need in a splash screen
> controllable by attributes.
>
> That said, if we go the XML route, does the splash screen stuff qualify as
> a plugin? Or does it then factor into the "core framework"?
>
> On 4/24/12 1:44 PM, "Simon MacDonald" <simon.macdonald@gmail.com> wrote:
>
> >That should be completely doable but I think it makes more sense to add a
> ><splashscreen/> tag to the cordova.xml file. This way the developer will
> >be
> >able to specify the image name and timeout of the splash screen. Something
> >along the lines of what BB does:
> >
> ><rim:loadingScreen backgroundImage="images/splash.png"
> >foregroundImage="images/splash.png" onFirstLaunch="true">
> >    <rim:transitionEffect type="slideOver" duration="1000"
> >direction="left"/>
> ></rim:loadingScreen>
> >
> >or BB on Playbook:
> >
> >
> ><splashscreen>img/spalsh_landscape.jpg:img/splash_portrait.jpg</splashscre
> >en>
> >
> >Simon Mac Donald
> >http://hi.im/simonmacdonald
> >
> >
> >On Tue, Apr 24, 2012 at 4:26 PM, Bryce Curtis
> ><curtis.bryce@gmail.com>wrote:
> >
> >> While not everyone likes splash screens they are required for some
> >> products.  Thus, they should be optional.  When used, they need to be
> >> displayed as soon as possible - before any HTML/JS code has been
> >> loaded would be best.  Different apps require they are dismissed at
> >> different times.
> >>
> >> If it works, the plugin route would have these features.  You could
> >> have the splash screen load at app start by setting onload="true" in
> >> the plugins.xml.  Then you dismiss it by calling the only plugin
> >> api... hide().
> >>
> >> Sound do-able?
> >>
> >> On Tue, Apr 24, 2012 at 2:53 PM, Simon MacDonald
> >> <simon.macdonald@gmail.com> wrote:
> >> > Okay, conf call done. Lemme catch up on this thread.
> >> >
> >> > @Brian - I was able to find a layout to use for the dialog that covers
> >> the
> >> > entire screen so we can remove that problem from the minus category. I
> >> was
> >> > able to test it on a phone, phablet and tablet screen sizes. The new
> >> splash
> >> > screen functionality looks exactly the same as what we have currently
> >>it
> >> > just does it differently under the hood.
> >> >
> >> > @Fil & @Joe - Yeah, I think splash screens are a waste of time too
> >>but in
> >> > our case they make sense. With the splash screen in place we can load
> >>the
> >> > app in the background and we will get rid of that problem where people
> >> > complain the app starts up with a black screen then the web view is
> >> created
> >> > causing a white flash before the app is loaded. I just want the
> >>Android
> >> > platform to have the same functionality as iOS.
> >> >
> >> > @Joe - I didn't want to use an ImageView as then we'd have to get into
> >> > starting a new activity and all the other fun that entails.
> >> >
> >> > @Fil - Do you think we should make it optional for the splash screen
> >>to
> >> be
> >> > dismissed on "deviceready"? Some folks might want to let the splash be
> >> > displayed for the full timeout value provided in the loadUrl call.
> >> >
> >> > This change on Android can go in for 1.7 or 1.8. Whatever folks want.
> >> >
> >> > Simon Mac Donald
> >> > http://hi.im/simonmacdonald
> >> >
> >> >
> >> > On Tue, Apr 24, 2012 at 3:37 PM, Joe Bowser <bowserj@gmail.com>
> wrote:
> >> >
> >> >> Sounds good!  Let's create some tickets in JIRA and hash this out.
> >> >>
> >> >> On Tue, Apr 24, 2012 at 10:16 AM, Filip Maj <fil@adobe.com> wrote:
> >> >>
> >> >> > I am in HUGE favor of creating a Splash Screen plugin (iOS does
> >>this
> >> >> > already, it looks like Simon is going down that path) that we
make
> >> work
> >> >> > consistently across platforms.
> >> >> >
> >> >> > Would be a good exercise in plugin authoring, something that we
> >>need
> >> to
> >> >> > work out details for for 2.0 anyways (but that's a separate
> >>thread).
> >> >> >
> >> >> > Finally: the JS for the Splash Screen plugin would be dead simple.
> >>At
> >> its
> >> >> > simplest:
> >> >> >
> >> >> > cordova.onDeviceReady.subscribeOnce(function() { exec(function(){},
> >> >> > function(){}, 'splashscreen', 'hide', []); });
> >> >> >
> >> >> > Or, more complex, we could expose as a core cordova API and offer
> >>APIs
> >> >> for
> >> >> > showing and hiding.
> >> >> >
> >> >> > On 4/24/12 9:37 AM, "Joe Bowser" <bowserj@gmail.com> wrote:
> >> >> >
> >> >> > >OK, here's where I go against what I've been saying for years
> >>about
> >> >> > >Spashscreens being a stupid exercise in branding and come
out in
> >> defence
> >> >> > >of
> >> >> > >this approach.  That being said, does it have to be a dialog,
or
> >>can
> >> we
> >> >> do
> >> >> > >something tricky with an ImageView in the background.  I agree
> >>that
> >> our
> >> >> > >splashscreen is janky, and needs to be fixed, but we should
make
> >>it
> >> so
> >> >> > >that
> >> >> > >you can't tell it's a Cordova app.
> >> >> > >
> >> >> > >But yeah, I'm fine with this code being put into the
> >>CordovaWebView
> >> >> branch
> >> >> > >and tickets being added to get it here.
> >> >> > >
> >> >> > >On Tue, Apr 24, 2012 at 9:23 AM, Brian LeRoux <b@brian.io>
wrote:
> >> >> > >
> >> >> > >> Woah, hold up:
> >> >> > >>
> >> >> > >> "The only downside is the dialog does not fully cover
the
> >>screen."
> >> >> > >>
> >> >> > >> Not in a spot to test this yet but how much is covered
/ how
> >>big is
> >> >> > >> the visual change?
> >> >> > >>
> >> >> > >> If its at all different would we not want to deprecate
the old
> >> >> > >> functionality and warn of the new behavior?
> >> >> > >>
> >> >> > >> Final thought, perhaps we could consider axing splash
screens
> >> >> > >> altogether. It kinda should be handled by the client
code and
> >>not
> >> the
> >> >> > >> native side, imo.
> >> >> > >>
> >> >> > >>
> >> >> > >> On Tue, Apr 24, 2012 at 8:21 AM, Joe Bowser <bowserj@gmail.com>
> >> >> wrote:
> >> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> >> >> > >> > <simon.macdonald@gmail.com>wrote:
> >> >> > >> >
> >> >> > >> >> Hey,
> >> >> > >> >>
> >> >> > >> >> I did a bit of a refactor on the Android splash
screen. I
> >>didn't
> >> >> like
> >> >> > >> the
> >> >> > >> >> fact that when you do a:
> >> >> > >> >>
> >> >> > >> >> *super*.setIntegerProperty("splashscreen",
> >>R.drawable.*splash)*;
> >> >> > >> >>
> >> >> > >> >> *super*.loadUrl("file:///android_asset/www/conn.html",
5000);
> >> >> > >> >> The splash screen is shown for 5 seconds then
the web view
> >> begins
> >> >> to
> >> >> > >> load
> >> >> > >> >> the page. That is, the splash screen is a blocking
call.
> >> >> > >> >>
> >> >> > >> >> I believe I've made this better by changing
the way we
> >>display
> >> the
> >> >> > >> splash
> >> >> > >> >> screen to a dialog box. This way the web view
underneath the
> >> dialog
> >> >> > >>can
> >> >> > >> >> continue to load the web page while splash screen
is being
> >> >> displayed.
> >> >> > >> >> Additionally, I've added a splash screen plugin
to Android so
> >> you
> >> >> can
> >> >> > >> call
> >> >> > >> >> it's hide method to make the splash screen go
away in your
> >> >> > >>onDeviceReady
> >> >> > >> >> handler. For developers using our API I haven't
changed the
> >>way
> >> the
> >> >> > >> splash
> >> >> > >> >> screen is setup so they won't be required to
change their
> >>code.
> >> The
> >> >> > >>only
> >> >> > >> >> downside is the dialog does not fully cover
the screen.
> >> >> > >> >>
> >> >> > >> >> Here is the commit:
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >>
> >> >> > >>
> >> >> >
> >> >>
> >>
> >>
> https://github.com/macdonst/cordova-android/commit/d359eaf4534dc0eed91cda
> >> >> > >>c7e9e0bd23ab36bc46
> >> >> > >> >>
> >> >> > >> >> Comments? Is this something I should push into
the Android
> >>repo
> >> for
> >> >> > >>1.8?
> >> >> > >> >> Can we hook something in the common JS so folks
can call
> >>hide on
> >> >> the
> >> >> > >> splash
> >> >> > >> >> screen plugin on Android and iOS?
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> > Looks good, and it solves a problem that we've been
having
> >>with
> >> the
> >> >> > >>way
> >> >> > >> we
> >> >> > >> > do splashscreens.  We may need to add exception
handling for
> >>the
> >> >> > >>plugin
> >> >> > >> if
> >> >> > >> > people do something stupid like use it with a CordovaWebView,
> >>but
> >> >> > >>other
> >> >> > >> > than that it looks good and is much easier to read
than the
> >> current
> >> >> > >>code.
> >> >> > >> > Please push this into the Android repo for 1.8.
 Let me know
> >>if
> >> >> > >>there's
> >> >> > >> > problems merging it with the CordovaWebView branch.
> >> >> > >> >
> >> >> > >> > Joe
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >>
>
>

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