Hi Kenneth,
We do have an app template, and it does include the code to hide the splash
screen in the intel.xdk.device.ready event listener. We don't recommend the
setTimeout method of extending the splash screen. The splash screen hides
itself in 3 seconds if the user doesn't hide it earlier. That's the current
behavior. The guy who got himself in trouble didn't use the template.
The splash screen shown under emulation is just a simulation of a splash
screen. It's not the real splash screen that would be shown by the container
when the app runs as a packaged app. It doesn't matter how this compares with
style guidelines; it's just a placeholder.
It sounds like the distinction between a splash screen and a launch image is in
the appearance of the image itself. From a tools perspective they are the same
thing. Neither the emulator nor the container care what the image looks like;
we just display whatever the user gives us.
The APIs themselves are known to the editor in the XDK, and we provide hints
and auto-completion automatically.
Julian
-----Original Message-----
From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
Sent: Tuesday, December 31, 2013 11:33 AM
To: Horn, Julian C
Cc: Wang, Shiliu; He, Xinchao; Li, Guangzhen;
crosswalk-dev@lists.crosswalk-project.org
Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for xwalk
based application.
Hi,
On Tue, Dec 31, 2013 at 4:57 PM, Horn, Julian C <julian.c.h...@intel.com> wrote:
>> I don't see why it would simulate a splash screen that has to be explicitly
>> hidden if the user didn't ask for one. Especially not one that has to be
>> explicitly hidden. A default splash screen is possible but it should then be
>> teared down automatically when the DOM readyState changes to "interactive"
>> (initial layout complete).
>> As said above, if the user didn't request a splash screen, it should
>> automatically be hidden (on the correct DOM readyState).
>
> That's not what we're doing. The Device Emulator imitates the behavior that
> the program would exhibit when it runs as a built app. When you build your
> HTML5 sources into an app using the XDK build service, your code is bound
> with an Intel-supplied container. The splash screen is initiated by the
> container initialization sequence, not by actions in the user source.
> Nevertheless user source has to take action to tear it down. Every app that
> uses the Cordova or Intel XDK APIs pretty much requires a splash screen
> because it has to wait for the deviceready/intel.xdk.device.ready event
> before it can use the API services. Splash screens are unconditional when
> you use the Intel XDK container.
I suppose your create a app template, why don't you create a default event
listener for the deviceready and let that call the method to hide the
splashscreen? Advanced developers can just remove that default implementation.
Or you could even create your own setTimeout that calls a method to hide it
after 3 seconds.
> The only thing that's different under emulation is that the emulator provides
> the splash screen image rather than showing the splash sequence image that
> will be used by the built app. That message I described appears in a view
> that covers the entire display area. In other words, that text *is* the
> splash screen when you run under emulation.
Sounds bad... also the iOS guide clearly states to never use text on
launch/waiting screens.
> One could argue that the emulator should use the real image. This is part of
> a long-standing argument about whether the emulator is emulating the
> container and the target OS services or just the user app and the APIs it
> uses. I'd rather not rehash that whole thing here.
I would just show Intel branding :-) Many find it important to show their own
branding, so they will quickly research how to replace that
:-) *kidding*.
> This won't work for hybrid apps. The fact that the DOM readyState has
> changed to inactive just means the document has finished parsing. That
> doesn't guarantee that native device drivers have finished their asynchronous
> initialization sequence or that the Cordova API has initialized itself and
> injected itself into the global name space. You have to wait for the
> deviceready event before using Cordova APIs. If you use multiple frameworks
> (like Intel XDK and Cordova currently are), then you have to wait for
> multiple events.
Just make your default app template listen to the deviceready and tear it
down... you can even add comments in the code template.
>> Tools can be pretty good at educating and providing links to further
>> documentation. Saying that no one reads documentation anymore is wrong; I
>> know a lot of people reading documentation and I do so myself.
>
> Some people read some documentation. Most people use documentation as
> reference material when they have a question. My point is that relying on
> people to read the documentation often leads to disappointing results. We
> spend a lot of time trying to write good documentation and provide links to
> documentation throughout. API documentation gets read more than tool
> documentation.
API documentation is great, especially when integrated into tooling where you
can quickly get hints and look up relevant info.
> I think we're in agreement here that the splash screen user experience is
> poor. There is a current issue in our bug database asking that the splash
> screen experience be redesigned to be more intuitive.
>
> I read your link to the iOS style guides regarding "launch images". As far
> as I can tell, a launch image and a splash screen are the same thing: it's an
> image you see immediately when the app starts up that goes away when the
> first screen of the app appears. In fact it says the purpose of the launch
> image is to provide 'An "app entry experience," such as a splash screen'.
Sure, they are related... the difference is that a "splash screen" is something
which draws attention (ie shows branding, text etc) where as the "launch
screen" just shows a line out of the final UI. Of course the implementation
will be similar, though it is harder to do the latter in a responsive [design]
way.
My current manifest extension:
https://docs.google.com/document/d/17PuNuHRTQuREUpaCvj-eEx7uYi2avd-VW-oaMXMpvwo/edit#
Kenneth
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
