You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Simon MacDonald <si...@gmail.com> on 2012/04/24 16:40:19 UTC

Better Splash Screen?

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/d359eaf4534dc0eed91cdac7e9e0bd23ab36bc46

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?

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

Re: Better Splash Screen?

Posted by Brian LeRoux <b...@brian.io>.
interestingly this would be an example, I think, of a plugin that has
no js call ... and it inits before anything else

or am I missing something?

On Tue, Apr 24, 2012 at 12:42 PM, Filip Maj <fi...@adobe.com> wrote:
> I'd like to first hear what everyone else on the list thinks :)
>
> On 4/24/12 12:37 PM, "Joe Bowser" <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
>>>wrote:
>>> >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>>> >> > <si...@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
>>> >>
>>>
>>>
>

Re: Better Splash Screen?

Posted by Joe Bowser <bo...@gmail.com>.
On Tue, Apr 24, 2012 at 12:53 PM, Simon MacDonald <simon.macdonald@gmail.com
> wrote:

> Okay, conf call done. Lemme catch up on this thread.
>
> @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.
>
>
Not necessarily. There are two approaches that you can take to avoid
activities, but really only one good one.

1. Change LinearLayoutKeyboardDetect to FrameLayoutKeyboardDetect.  This
would cause any view to be overlayed over the other view.  You can then
overlay the ImageView over the WebView then either remove the view or set
the visibility on the view.  I had to do this when working on an Android Ad
SDK
2. Use the AbsoluteLayout properties of the WebView to put the ImageView on
the WebView itself.  Don't do this.

I understand the business requirement for Splash Screens since there's
branding that companies want on that page.  Back when we directly hooked up
Java objects to the WebView, I thought it was extremely stupid because we
loaded so fast.  These days, I think there's more value.  But I'm pretty
much repeating what everyone eles has said.

Re: Better Splash Screen?

Posted by Simon MacDonald <si...@gmail.com>.
Yes, yes I am.
On Apr 26, 2012 3:23 PM, "Brian LeRoux" <b...@brian.io> wrote:

> awesome
>
> On Wed, Apr 25, 2012 at 8:48 AM, Simon MacDonald
> <si...@gmail.com> wrote:
> > 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 <fi...@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" <si...@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
> >> ><cu...@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
> >> >> <si...@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 <bo...@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 <fi...@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" <bo...@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
> >> >> >> > >> > <si...@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
> >> >> >> > >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >>
> >>
> >>
>

Re: Better Splash Screen?

Posted by Brian LeRoux <b...@brian.io>.
awesome

On Wed, Apr 25, 2012 at 8:48 AM, Simon MacDonald
<si...@gmail.com> wrote:
> 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 <fi...@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" <si...@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
>> ><cu...@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
>> >> <si...@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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
>> >> >> wrote:
>> >> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> >> >> > >> > <si...@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
>> >> >> > >>
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>>
>>

Re: Better Splash Screen?

Posted by Simon MacDonald <si...@gmail.com>.
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 <fi...@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" <si...@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
> ><cu...@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
> >> <si...@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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
> >> >> wrote:
> >> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> >> >> > >> > <si...@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
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >>
>
>

Re: Better Splash Screen?

Posted by Filip Maj <fi...@adobe.com>.
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" <si...@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
><cu...@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
>> <si...@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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
>> >> wrote:
>> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> >> > >> > <si...@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
>> >> > >>
>> >> >
>> >> >
>> >>
>>

Re: Better Splash Screen?

Posted by Simon MacDonald <si...@gmail.com>.
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</splashscreen>

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


On Tue, Apr 24, 2012 at 4:26 PM, Bryce Curtis <cu...@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
> <si...@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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
> >> wrote:
> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> >> > >> > <si...@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
> >> > >>
> >> >
> >> >
> >>
>

Re: Better Splash Screen?

Posted by Bryce Curtis <cu...@gmail.com>.
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
<si...@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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
>> wrote:
>> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> > >> > <si...@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
>> > >>
>> >
>> >
>>

Re: Better Splash Screen?

Posted by Simon MacDonald <si...@gmail.com>.
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 <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
> wrote:
> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> > >> > <si...@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
> > >>
> >
> >
>

Re: Better Splash Screen?

Posted by Filip Maj <fi...@adobe.com>.
I'd like to first hear what everyone else on the list thinks :)

On 4/24/12 12:37 PM, "Joe Bowser" <bo...@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 <fi...@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" <bo...@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 <bo...@gmail.com>
>>wrote:
>> >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> >> > <si...@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
>> >>
>>
>>

Re: Better Splash Screen?

Posted by Joe Bowser <bo...@gmail.com>.
Sounds good!  Let's create some tickets in JIRA and hash this out.

On Tue, Apr 24, 2012 at 10:16 AM, Filip Maj <fi...@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" <bo...@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 <bo...@gmail.com> wrote:
> >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> >> > <si...@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
> >>
>
>

Re: Better Splash Screen?

Posted by Filip Maj <fi...@adobe.com>.
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" <bo...@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 <bo...@gmail.com> wrote:
>> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> > <si...@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
>>

Re: Better Splash Screen?

Posted by Joe Bowser <bo...@gmail.com>.
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 <bo...@gmail.com> wrote:
> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> > <si...@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/d359eaf4534dc0eed91cdac7e9e0bd23ab36bc46
> >>
> >> 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
>

Re: Better Splash Screen?

Posted by Filip Maj <fi...@adobe.com>.
>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.

Although I agree with you on this point, the native implementations are
not a point yet where client HTML can handle this properly - we already
have a few "white flash / black flash" issues filed with the native impls
not showing the splash screen early enough / hiding it too early causing
flashes.

Even BB webworks does something like show an image until the web view
boots up (under the hood).

>
>
>On Tue, Apr 24, 2012 at 8:21 AM, Joe Bowser <bo...@gmail.com> wrote:
>> On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
>> <si...@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/d359eaf4534dc0eed91cd
>>>ac7e9e0bd23ab36bc46
>>>
>>> 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

Re: Better Splash Screen?

Posted by Brian LeRoux <b...@brian.io>.
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 <bo...@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
> <si...@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/d359eaf4534dc0eed91cdac7e9e0bd23ab36bc46
>>
>> 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

Re: Better Splash Screen?

Posted by Joe Bowser <bo...@gmail.com>.
On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald
<si...@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/d359eaf4534dc0eed91cdac7e9e0bd23ab36bc46
>
> 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