Dynamic Content

From Oxygen.next Wiki

[edit] Overview

You want automatic Weather forecasts, Newstickers, Interactive Kiosk Apps, ect. !? Well, then you need Dynamic Content. Dynamic Content are applications that run as Content inside Oxygen.next.

They can be feed with information by the internal Oxygen Message Bus who makes it easy to build great Application with less coding. So you can focus on Design and Viewing Experience!

[edit] Suppported Frameworks

There are several Frameworks to create Dynamic Content. You can build your Content with:

• Adobe Flash
• Microsoft Silverlight
• HTML/CSS/JavaScript
• Microsoft WPF Webbrowser Applications
• Sun Microsystems Java JRE

As you can see we have a huge bandwith of possible Frameworks for you to choose of.

[edit] How to

Flash is supported nativly inside the Player. That means you can take your swf file and simple upload it as Content. All other Frameworks are wrapped through the MS Internet Explorer which is used internally by the Player. To upload these you simply zip your builded project and rename the extension from ".zip" to ".webcontainer" and then upload it as content.

[edit] Feeding your Content with "Content"

There are 3 ways to transfer specific data to the player:

1. Get it directly

Build your Application so that it directly gets updates from your servers. While this is easy to implement it has a lot of drawbacks related to bad internet connections (3G or WiFi) or your server availability.

2. Feed System

Each newsfeed that is assigned to a player or player group via the OMS can be queried locally. This option is appropriate for data that is often changed (resp. that shall be updated automatically (via RSS import or Oxygen_REST_API)) resp. that is the same for many players (since assignment via player groups is possible).

For that purpose the URL http://localhost/getdata.php is available on the player. The following parameters are possible:

• http://localhost/getdata.php?get=list

Returns an XML-formatted list of all newsfeeds available on the system.

Format:

<Feeds>
<Feed>Feed #1</Feed>
<Feed>Another Feed</Feed>
…
</Feeds>

• http://localhost/getdata.php?get=feed&feedName=NAME

Returns the content of the most recent entry in the newsfeed NAME (older entries will be ignored).

Format:

Unformattet, whatever has been transferred as news content will be returned.

• http://localhost/getdata.php?get=feedComplete&feedName=NAME

Returns all entries from the newsfeed NAME.

Format:

<Feed>
     <Message>
          <Title>Entry title</Title>
          <Text>Entry content</Text>
          <PublishDate>Entry date</PublishDate>
     </Message>
     <Message>
          …
     </Message>
     …
</Feed>

3. Location specific data

The feature "Location specific data" is good for data that is meant for one specific player only and is not changed regulary. It allows to make any kind of files available on the player.

For that purpose a player must be selected in the OMS admin section "User/Player". On the tab "Information" please click "Edit" below "Location specific data". A window pops up that allows to upload a ZIP file (max. 10 MB) which may contain any kind of data (e.g. a "zip-code.txt" indicating the player location's zip code). This ZIP file will be transferred to the player via the ContentUpdater and will be locally unzipped into the folder (exact local path depends on your setup) „d:\Oxygen Content\LocationInfo\“. The transferred "zip-code.txt" is then available in „d:\Oxygen Content\LocationInfo\plz.txt“.

Furthermore this folder is available via http at http://localhost/content/LocationInfo/ (the "download path" for "zip-code.txt" would be http://localhost/content/LocationInfo/zip-code.txt then).

[edit] Rules to code by

For best performance:

  * Be conscious of system memory, check availability and limitations when running Flash. Consume only what is necessary and test for memory leaks!!!
  * Handle errors or crashes gracefully with proper recovery messaging.

Perceived vs. actual performance

Users are the ultimate judges of whether your content performs well. Developers may measure application performance in terms of how long certain operations take or how many instances of objects are created. However, those metrics aren't important to end users. Sometimes users measure performance by different criteria. For example, does the application operate quickly and smoothly, and respond quickly to input? Does it have a negative effect on the performance of the system as a whole?

Ask yourself the following questions to measure perceived performance:

  * Are animations smooth or choppy?
  * Does video content look smooth or choppy?
  * Do audioclips play continuously, or do they pause and resume?
  * Does the window flicker or turn blank during long operations?
  * Do other applications respond poorly when the application is running?

The distinction between perceived performance and actual performance is important. The way to achieve the best perceived performance isn't always the same as the way to get the absolute fastest performance. Make sure your application never executes So much code that the runtime isn't able to frequently update the screen and gather user input. In some cases, achieving this balance involves dividing up a program task into parts So that, between parts, the runtime updates the screen.

Using bitmaps

Using vectors, especially in large numbers, dramatically increases the need for CPU or GPU resources. Using bitmaps is a good way to optimize rendering, because for example the Flash player needs fewer processing resources to draw pixels on the screen than to render vector content.

Tweening syndrome

Limit the use of tweening to save CPU processing and memory. Designers and developers producing content for Flash tend to use many motion tweens in their applications. Try to minimize the use of motion tweens to help your content run faster.

Some flash guidelines referenced from Adobe, Inc.