awesome
On Wed, Apr 25, 2012 at 8:48 AM, Simon MacDonald <simon.macdon...@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 <f...@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" <simon.macdon...@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 >> ><curtis.br...@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 >> >> <simon.macdon...@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 <bows...@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 <f...@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" <bows...@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 <bows...@gmail.com> >> >> >> wrote: >> >> >> > >> > On Tue, Apr 24, 2012 at 7:40 AM, Simon MacDonald >> >> >> > >> > <simon.macdon...@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 >> >> >> > >> >> >> >> > >> >> >> > >> >> >> >> >> >> >>
