Skip to main content
The TitanOS application environment provides standard web mechanisms for storing data on the client-side, such as user sessions, preferences, and application state. Our platform supports Cookies and Local Storage, behaving identically to a modern, secure web browser. This guide outlines how to use these standard web APIs within your application.

​
LocalStorage

This method is used for storing persistent client-side data, such as JWT tokens, user settings (e.g., language preference), or application state. Data stored in LocalStorage is specific to your app’s origin and persists even after the TV is turned off and on again.
  • Characteristics: Persistent storage, larger capacity (typically 5-10 MB), data is not sent with every HTTP request.
  • Use via: Standard JavaScript window.localStorage API.
JavaScript Example: 
// Save a JWT token to LocalStorage
const jwtToken = 'your_auth_token_here';
localStorage.setItem('user_token', jwtToken);

// Retrieve the token later
const savedToken = localStorage.getItem('user_token');
if (savedToken) {
  console.log('User is authenticated!');
}

// Remove the token (e.g., on logout)
localStorage.removeItem('user_token');

​
Cookies

Cookies are also fully supported and work as they do in a standard web browser. They are primarily useful when your application’s authentication model requires the browser to automatically send session identifiers with every API request to your backend.
  • Characteristics: Can have an expiration date, smaller capacity (approx. 4 KB), data is sent with every HTTP request to your domain.
  • Use via: Standard JavaScript document.cookie API or via Set-Cookie HTTP headers from your server.
JavaScript Example: 
// Set a simple session cookie that expires in 1 day
const expiryDate = new Date();
expiryDate.setDate(expiryDate.getDate() + 1);
document.cookie = `session_id=abc123; expires=${expiryDate.toUTCString()}; path=/`;

​
Is there a preferable method to use?

Both LocalStorage and Cookies are fully supported on the TitanOS platform, and the choice of which to use depends on your application’s specific architecture and session management strategy. Your team should choose the mechanism that best fits your needs. However, for most modern client-side storage use cases on a Smart TV application, LocalStorage is generally the recommended method due to several key benefits: Larger Storage Capacity: LocalStorage offers a significantly larger storage capacity (typically 5-10 MB) compared to the 4 KB limit of cookies. This makes it ideal for caching application data, user profiles, or complex state information. Better Performance: Data stored in LocalStorage is not automatically sent with every HTTP request to your server. This reduces network overhead and can improve your application’s overall performance, which is especially important on embedded devices. Simpler API: The JavaScript API for LocalStorage (setItem(), getItem(), removeItem()) is much cleaner and more straightforward to use than the manual string parsing required for managing document.cookie. In summary, while both methods are available, we recommend LocalStorage for most use cases, such as managing JWT authentication tokens or caching user preferences. Cookies remain a perfectly valid option for traditional server-managed sessions or when specific features like HttpOnly security are a requirement.

​
Alternative Strategy: Server-Side Sessions

While client-side storage is fully supported and often sufficient, some partners may opt for a server-side session management strategy. In this model, the application state is stored on the partner’s backend servers and associated with a unique device identifier. TitanOS provides the Titan SDK through which your application can retrieve a unique deviceId. This ID can then be used to create and manage server-side sessions. This is a valid architectural choice that is fully enabled by our platform, but it is up to each application partner to decide if this model best fits their needs.
⌘I