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 <[email protected]> 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" <[email protected]> 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 > ><[email protected]>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 > >> <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> >> wrote: > >> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald > >> >> > >> > <[email protected]>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 > >> >> > >> > >> >> > > >> >> > > >> >> > >> > >
