Lifecycle Integration

The Senza platform operates in three modes:

1. In foreground mode, your web app runs in a browser in the cloud, and the user interface is streamed to the cloud connector.
2. In background mode, the browser stops updating the screen, while the JavaScript engine keeps running.
   1. If a video is playing, then it is streamed directly from the CDN to the cloud connector.
   2. Otherwise, Senza continues showing the last frame rendered by the browser.
3. In suspended mode, the JavaScript engine stops running. Otherwise it is the same as background mode.

When your app is running in the browser in foreground mode, it consumes CPU and GPU resources. When you switch to background mode, the GPU shuts down but the CPU continues to be used. In suspended mode, the CPU stops running as well. Usage is calculated based on the time spent in each of these modes, so you'll want to adapt your app to use background and suspended modes as much as possible.

Background and suspended modes are primarily used for playing video streams, but you can also use them if you are not playing a video. If the remote player does not have a video loaded, or the video is not currently playing, the cloud connector will continue to display the last frame rendered by the web browser. This is ideal for saving resources if the content on the screen is does not need to be changed for a period of time.

When resuming from suspended mode, your web app will be restarted. As a result, any in-memory context will be reset. To preserve the state of the user interface, you'll need to save the context to session storage and restore it when resuming. When your app starts up, you can check the connection reason to understand if the app is resuming from suspended mode and the context should be restored.

You can use the Lifecycle object to switch between modes, and can also configure it to switch modes automatically after a period of inactivity. See Switching Modes for more details.

When to use foreground mode

When the user is interacting with your app

In this case your web app runs as normal in the browser in the cloud. When the user presses buttons on the remote control, user input events are sent to your app as key presses, and your app can update the interface in real time to respond to their commands.

When you want to combine video with other elements

Your app may want to present video full screen combined with other HTML user interface elements layered on top, such as playback controls, content metadata, or augmented experiences. In this case you would stay in foreground mode so that the browser can composite the video and other elements.

When content on the screen is changing

In non-interactive use cases such as digital signage, your app may need to update the content on the screen periodically or display animations. Any time your app needs to update the contents of the web page, you'll need to do so in foreground mode.

When to use background mode

When the viewer is watching full screen video

When your app is ready to play video without other user interface elements, switch to background mode. Video will then stream directly to the cloud connector. In background mode, video plays at higher quality because it does not have to be re-encoded, and is more resilient to network conditions because it has a 30-second playback buffer.

During periods of inactivity

Users typically interact with your app intermittently. They may actively use the remote control to navigate the user interface, lean back to watch content, or simply walk away from the TV. Whenever the user is not actively interacting with the app, you should move to background mode after 15 to 60 seconds to save resources. Depending upon the functionality of your app, you can either:

• Move to background mode without playing a video, which will simply freeze the screen. Switching between foreground and background modes is seamless and nearly instant. However, you'll see that any videos or animations will stop moving when the screen is frozen.
• Play a video in background mode. For example, you could resume playing the most recent video stream where the viewer left off.

If your app needs to continue updating the web content on the screen you can stay in foreground mode, but this consumes more resources.

When the content on screen isn't changing

In non-interactive use cases, if your app will display the same content on screen for a period of time without needing to update it, you can switch to background mode to save resources. If you want to update the screen later after a period of time, you can switch back to foreground mode.

When to use suspended mode

Suspended mode is like background mode, but is even cheaper because the CPU can be released. Because the browser stops running your app while in suspended mode, your app will restart when switching back to background or foreground mode. It's similar to hitting the reload button in a regular web browser.

In order to preserve the user experience, the app should save and restore its state. Before entering suspended mode, it should save its state to session storage. When resuming, it should read the state back from session storage and restore the user interface. See Preserving State for more details.

The amount of effort required to save and restore state depends upon the complexity of the app and the frameworks that it uses. Simple apps with little or no state can simply save any global variables as required. Modern apps that use state management frameworks may be able to serialize the app's entire state so that it can be saved and restored.

It takes a moment to reallocate the required server resources before the app starts up again. It is also important to consider the amount of time required for an app to restore its state once it restarts. Apps that display a progress bar while loading a large amount of data at startup may not be able to resume quickly enough. Whether it makes sense to use background mode, suspended mode or a combination of both depends upon your app.

Comparison

Here is a table that compares some aspects of the three modes.

Development journey

As you integrate your app with the Senza platform, a typical journey would look like this:

1. Foreground mode: You can test how well your app works without making significant modifications. This is great for getting started with development, but it's not a good solution for deployment because foreground mode costs more, and the video must be re-encoded when streaming.
2. Background mode: With the Senza Shaka Player and Auto Background features, you can integrate your app to take full advantage of background mode using just a few lines of code. This is a great solution if your app needs to keep running all the time.
3. Suspended mode: If you can update your app to support saving and preserving state so that it can be quickly restarted, you can further take advantage of suspended mode to save additional cost. You'll need to update your control flow, replacing timers with calls to Alarm Manager.

Programming techniques

• Switching Modes: shows how to switch between foreground, background and suspended modes, including doing this automatically by configuring timeouts.
• Lifecycle Events: shows how your app can be notified when the lifecycle changes modes, the user has been inactive, or the session has disconnected.
• Preserving State: shows how to save the current state to session storage or local storage and restore it when the app restarts.

Example Apps

• Playing Video: A step-by-step guide to the reference implementation.
• Program Guide: Demonstrates how to integrate a full featured app with just a few lines of code.
• Video Signage: Shows how to make a digital signage app that takes advantage of background mode.