Well then you should allow comments on the document Kenneth
On Tue, Jan 7, 2014 at 9:04 AM, Li, Guangzhen <guangzhen...@intel.com> wrote: > Hi all, > I have wrote a design doc for Launch Screen implementation on Android. > > https://docs.google.com/a/intel.com/document/d/1YLajlZC7CkBOtEvzD6p6yeBr0HrPsaIGX8Eqhr3oTF4/edit?usp=sharing > > Please help to review, and fell free to add comments there. > > Br. > Guangzhen > > -----Original Message----- > From: Crosswalk-dev > [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of Li, > Guangzhen > Sent: Thursday, January 2, 2014 2:52 PM > To: Horn, Julian C; Kenneth Rohde Christiansen > Cc: crosswalk-dev@lists.crosswalk-project.org > Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for xwalk > based application. > > Hi Julian and Kenneth, > I have investigated splash screen feature on Android Crosswalk, and want to > provide proposal for XDK Android Crosswalk integration. > (1) Show splash screen > As I have found in github: crosswalk-project / > crosswalk-cordova-android, The splash screen will be shown as a Dialog before > load url. > I think it's a little late to show splash screen, There will be > still around 1 second of blank screen displayed after user tap on app icon. > My proposal: > 1) Set splash image as background of main activity. Eg. <item name= > " android:windowBackground"> @drawable/splash</item> > 2) Set the splash screen image as background of splash screen > Dialog. dialog.getWindow().setBackgroundDrawableResource(res_id); > I think this part should be better implemented on engine side, better > align with other tools in the future. > PS: > I have installed latest XDK tool, and tried to build a simple > application. There is no splash screen displayed, only a black screen, I > don't know whether I made something wrong. > (2) Hide splash screen > I think it's better to hide the splash screen (launch image) > automatically by the engine when the first visible page updated on the > screen, just as iOS do.. > Because it's hard for developers to determine the exact time when the > first visible page available only using JS event, 'document.readystate' or > Cordova 'device.ready' are a little early to dismiss the splash screen. > I have tested HexGL-desktop-version on my Android device, it will take > around 3 seconds to render the game page on the screen after receive > 'document.readystate = complete' event. During this 3 seconds, a mess page > will be displayed. > For a very simplified page, After receive 'document.readystate=complege' > event, it will take around 200ms to update the web page on the screen. > So the scenario should be. > 1) Dismiss the splash screen automatically when first visible page > updated on the screen after 'document.readystate=complete' event received, > engine should have callback to notify screen has been updated.. > 2) We can also provide timeout, when the first visible page takes too > long to display, just dismiss the splash screen, a mess page or white screen > will be displayed on the web page. > > For the apps which will take too long time to initialize, such as games, > they need to have their own "Loading page" as first page, and it will be > displayed after the splash screen. > For more detailed implementation on Android, I want to create a google > doc, we can discuss there. > > Br. > Guangzhen > > -----Original Message----- > From: Horn, Julian C > Sent: Wednesday, January 1, 2014 12:52 AM > To: Kenneth Rohde Christiansen > 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 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 -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆ _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
