Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of curtis.bryce@gmail.com
 designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAM1AYQB0vVEM9xC1XMSyJLzD+q0wqoHyEgrU0UUWpm77SbcO4w@mail.gmail.com>
References: 
 <CAOBL_k5NyJF9agTB91bYNrJ=WmUqaBHLyx91aox_w0aqd7c7-w@mail.gmail.com>
	<CBBC2BE5.4FF3%fil@adobe.com>
	<CAOBL_k6eKiez1z4ZuNm0t83_yrX_-8AqA2nYS_zEWALH_Rcu+A@mail.gmail.com>
	<CAM1AYQB0vVEM9xC1XMSyJLzD+q0wqoHyEgrU0UUWpm77SbcO4w@mail.gmail.com>
Date: Tue, 24 Apr 2012 15:26:48 -0500
Message-ID: 
 <CAMT1KGPfXW5eK7KtcF-2idUSVo69eH6ehSs7ZPO6Xyb4OzLhfA@mail.gmail.com>
Subject: Re: Better Splash Screen?
From: Bryce Curtis <curtis.bryce@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=3D"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 th=
e
> entire screen so we can remove that problem from the minus category. I wa=
s
> able to test it on a phone, phablet and tablet screen sizes. The new spla=
sh
> 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 creat=
ed
> 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 b=
e
> 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! =A0Let'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 wor=
k
>> > consistently across platforms.
>> >
>> > Would be a good exercise in plugin authoring, something that we need t=
o
>> > 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 defe=
nce
>> > >of
>> > >this approach. =A0That being said, does it have to be a dialog, or ca=
n we
>> do
>> > >something tricky with an ImageView in the background. =A0I agree that=
 our
>> > >splashscreen is janky, and needs to be fixed, but we should make it s=
o
>> > >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 t=
he
>> > >> 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 begin=
s
>> 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 t=
he
>> > >> splash
>> > >> >> screen to a dialog box. This way the web view underneath the dia=
log
>> > >>can
>> > >> >> continue to load the web page while splash screen is being
>> displayed.
>> > >> >> Additionally, I've added a splash screen plugin to Android so yo=
u
>> 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=
a
>> > >>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 t=
he
>> > >>way
>> > >> we
>> > >> > do splashscreens. =A0We may need to add exception handling for th=
e
>> > >>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 curre=
nt
>> > >>code.
>> > >> > Please push this into the Android repo for 1.8. =A0Let me know if
>> > >>there's
>> > >> > problems merging it with the CordovaWebView branch.
>> > >> >
>> > >> > Joe
>> > >>
>> >
>> >
>>