Re: Use case: Splash Screen ? Re: starting point: manifests, configs, and the such

On Friday, 25 November 2011 at 01:07, Filip Maj wrote:

> One more idea I had about this whole thing about splash screens is how the
> <content type="blah"> element fits into this question.
>  
> What is the use case for the type attribute in the context of a content
> element?

it's for generated content, where the type is can't be derived from the file extension:

<content src="foo.fum.cgi" type="application/xhtml+xml"/>  

(side not… do we need mime type overrides? ala Apache .htaccess AddType?)
> Could we leverage <content type="image/jpeg"> or other type="image/format"
> and have the user agent parse through them and show splash screens if the
> right content type is defined?

no need :) widgets automagically do content-type sniffing of file types.  
> Seems kind of roundabout to me... But maybe
> that is the initial idea behind enabling the type attribute in the first
> place?

I'll answer more fully tomorrow (as it's 2am here), but I think HTML's video poster attribute holds the key… though it's not very accessible. I'm thinking:  

<widget ...>
<content splash="img.png"/>
 </widget>

 As its always just show for 1-2 seconds. Position, transitions, etc. left to implementation.  

thoughts?


> On 11-11-24 4:02 PM, "Filip Maj" <fil@adobe.com (mailto:fil@adobe.com)> wrote:
>  
> > > >  
> > > > > I see, but why is this not done with HTML? Is there performance issues
> > > > > or
> > > > > something?  
> > > > > > Again, RIM addressed this problem
> > > > > > in their Web-based SDK as well [3].
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > Seems like they are defining a mini-layout and styling language. If
> > > > that
> > > > > grows, then you just end up at HTML again, no? :(
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > Yeah, performance. The webview doesn't instantiate fast enough by the
> > > > time
> > > > the JS runtime is ready and your app is ready to go. So we have to dive
> > > > into native and
> > > >  
> > > > A) set up an overlay with a gif or image of your splash screen
> > > > B) go through set up ceremony in phonegap
> > > > C) fire an event ('deviceready') that phonegap users attach to to start
> > > > running their own app init / checks / etc.
> > > >  
> > > > Otherwise you basically see a black or white screen (depending on
> > > > platform) for a while, even if in the background some baseline JS is
> > > > executing to set up your app.
> > > >  
> > > > Presumably this may not be a problem down the road... But reality has
> > > > always taken a precedent in PhoneGap so we try to just make shit work
> > > > :P
> > >  
> > >  
> > >  
> > >  
> > > Ok, seems like a reasonable use case. I wonder if we can get an idea of
> > > what most developers are using here. If they mostly use an image, we can
> > > look at some simple model that we can build on.
> > >  
> > > What are the requirements?
> > > * include an image.
> > > * control the background color
> > > * orientation
> > > * position of image
> >  
> >  
> >  
> > I will say that 99% of splash screen use cases in the phonegap project is
> > just a simple image file (png or gif, animated or not) that is stretched
> > out over the dimensions of the device screen.
> >  
> > We've had an ask (maybe once or twice in the community) for splash screen
> > _videos_.
> >  
> > The RIM implementation exposes many more options, like background color,
> > positioning and fade effects. So perhaps the two approaches (PhoneGAp vs.
> > WebWorks) are two extremes in a spectrum of options. Can we tread a happy
> > middle path?
>

Received on Friday, 25 November 2011 01:04:17 UTC