incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Better Splash Screen?
Date Tue, 24 Apr 2012 20:52:37 GMT
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
View raw message