
Splash Screen Scenarios in Detail
Download Progress
A common scenario for a splash screen is to display a visual progress indicator. The most basic and familiar progress indicator to many users is the progress bar. A typical progress bar design shows a horizontally extended rectangular area that initially appears white or empty. As a download or action progresses, the empty area is gradually filled by a darker bar, and progress is complete as soon as the darker bar totally fills the rectangle. Sometimes this visual is accompanied by a text area that displays a numeric percentage.
In the Silverlight splash screen model, the means to determine the download progress is by reading the value of the Progress property from within a OnSourceDownloadProgressChanged handler's event data.
Although a progress bar might visually appear similar to an animation, you do not generally need to use the Silverlight animation API in order to build a progress bar. Instead, you simply use some factor of Progress from each iteration of OnSourceDownloadProgressChanged to update some property.
For instance, the following XAML defines a simple version of such a bar:
<Canvas Background="Black" Width="302" Height="52">
<Rectangle Canvas.Left="1" Canvas.Top="1" Width="300" Height="30" Fill="White"/>
<Rectangle x:Name="progressBarFill" Canvas.Left="1" Canvas.Top="1" Height="30" Fill="Blue"/>
</Canvas>
To produce the progress visual, you would reset the value of the fill bar on each iteration of by setting the width of progressBarFill in the handler. progress is a value between 0 and 1, so you use it as a factor against the total possible width of the progress bar area.
function onProgressChanged(sender, eventArgs)
{
var slPlugin = sender.getHost();
slPlugin.content.findName("progressBarFill").width = eventArgs.progress * 300;
}
Animation is not required, because the Silverlight rendering system detects run-time changed property values in the object tree and redraws the visuals accordingly.
Animations
Another common scenario for a splash screen is to display a cycling animation. The intention of the cycling animation is to indicate to the user that the application and the browser are still running and capable of rendering updates, and that nothing unexpected has happened (browser crash, connection error, etc.).
For these types of animations, the total animation duration is indeterminate, because the intention is to run the animation during the time the user waits for the download to complete. Therefore the best type of animation to use is one that has a natural cycling behavior and one that has a run time of Forever. The animation will "stop" when the entire XAML page is unloaded, and the Silverlight plug-in loads the content from the download-complete package.
Animations can generally be composed entirely in XAML. To run the animation, you can use EventTrigger containment of the Storyboard in the XAML markup to run the animation when it is first loaded. Or you can handle an object lifetime event such as Loaded on the root element, under the JavaScript API, retrieve the relevant Storyboard from a Resources collection, and call Storyboard..::.Begin on the Storyboard to start the animation.
For more information on how to compose animations and how animations work in general, see Animation Overview. Note that the Animation Overview topic is written primarily for users of the managed API, and may not have code examples or specific information that address the JavaScript API scenarios. Read the overview for a conceptual understanding. Some of the XAML examples provided in the overviews are probably useful after some minimal work to remove managed API specifics such as x:Class. Then, if necessary, you can learn more from the following topics in JavaScript API for Silverlight Reference:
You can also use key-frame animations for more fine-tuned animations with nonlinear interpolations for position and speed. These might be useful for very simple physics simulations in a splash screen, such as a bouncing ball. For more information, see Key-Frame Animations. The same provisos apply as far as the emphasis on managed programming and possible application of XAML samples. See also the following topics from JavaScript API for Silverlight Reference:
Branding
A traditional splash screen in many application models displays nothing more than a single large bitmap, and perhaps a progress indicator as a smaller part of the UI. The usual goal of such a splash screen is to prominently display the product branding information. There is nothing preventing you from employing this approach for a Silverlight splash screen. At the simplest level, your splash screen XAML could consist of nothing more than a single Image element that displays a bitmap. This might not be the ideal approach though, because if the bitmap is large, the image source downloads asynchronously and then even your splash screen might have a slight delay before it is displayed.
A better approach that uses the feature strengths of Silverlight is to compose your splash screen as vector graphics. You can import existing vector information in some cases using the pathway described in the topic Path Markup Syntax. Or you can use design tools that produce XAML markup that is compatible with Silverlight, such as Microsoft Expression Design. Also, you can either integrate any animations produced at design-time by such a tool, or add animations to the graphics later, by targeting certain properties of the fixed vector graphics set and animating those with storyboards.
Product Information
Your splash screen may want to display an area that primarily contains text. To simplify localization, you might want to keep that text out of the vector graphics portion of your content. The JavaScript API does not have as mature of a localization framework as the managed API does, but even so it will be useful to isolate the localization requirements to certain controls in the overall markup.
When you display text for a splash screen, you are limited to the text elements that are available to the JavaScript API. There are two possible techniques for read-only text: TextBlock, or Glyphs.
TextBlock is probably the lighter-weight technique, particularly if you are only targeting Latin alphabet cultures. You specify the TextBlock content as a string. Within the TextBlock, you can do some basic text formatting such as sizing, applying colors or brushes, as well as block-level formatting using LineBreak. If you want to use fonts beyond the defaults described in TextBlock, you must download the font; see SetFontSource.
Glyphs is a more versatile technique because you can supply a subsetted font as well as a UnicodeString, which makes it easier to use Far East fonts and character strings. The only complication is that you do need tools that can produce both subsetted fonts and compatible Unicode indices/strings. A technique for using XPS output from Microsoft Word is described in Glyphs.