Forem: Eric Elikplim Sunu

From Kotlin to BrightScript: How I Ported a Modern Android TV App to Roku

Eric Elikplim Sunu — Fri, 06 Feb 2026 14:05:17 +0000

We were having our daily standup when my boss dropped a suggestion that would define my next three months.

"We need to tap more into the US market," he said. "We should really build this on Roku."

We built LiveSpaces, a digital signage solution that turns screens into remotely controlled billboards. We already had a polished, modern Android TV app built with Kotlin and Jetpack Compose. It was reactive, declarative, and beautiful.

Then came the kicker. "How hard can it be?" I thought to myself as the meeting wrapped up. "Roku holds roughly 50% of the connected TV market in the United States. If we’re targeting the waiting room or the hotel lobby in the West, we can't ignore the purple box. I’ll probably just find a cross-platform library, wrap our existing logic, and ship it."

I was dead wrong.

First Contact: No IDE, Just a Zip File

I went to download the SDK, expecting an installer like Android Studio or Xcode. Instead, the documentation just said:

"To get started, download the Hello World sample app and unzip it..."

That was it. No heavy environment. Just a folder structure that looked like this:

components/: The XML files that define the layout (SceneGraph).
source/: The BrightScript code (the logic).
images/: Assets and splash screens.
manifest: The app configuration.

It felt raw. To write code, I couldn't use a dedicated Roku IDE because one doesn't really exist. I fired up VS Code and installed the BrightScript Extension.

The docs pitched it as a "suite of tools," and to be fair, the community extension for VS Code is a lifesaver: it gives you debugging, code formatting, and a telnet log. But coming from the rich, auto-completing embrace of Android Studio, I felt like I had been handed a text editor and a prayer

The Stack: A Primer for Web & Android Devs

Before diving into the bugs, you need to understand what "Native Roku Development" actually looks like. It relies on two pillars: BrightScript and SceneGraph.

If you come from the Web World, think of SceneGraph as the HTML DOM. It is a tree of nodes defined in XML. BrightScript is the JavaScript, it’s the scripting language used to manipulate those nodes. But unlike React or Vue, there is no Virtual DOM or data binding engine. You are manually selecting nodes and updating their properties, closer to the days of jQuery.

If you come from Android, think of SceneGraph as the old res/layout XML system, but strictly enforced. There is no Jetpack Compose here. BrightScript is your Java/Kotlin, but with syntax that looks like Visual Basic. It’s case-insensitive, uses End Sub and End If, and has no concept of generic types.

The Paradigm Shift: Reactive vs. The Node Tree

The hardest part of the migration was the shift in mental model. In Android, I live in a world of Coroutines, Flow, and StateFlow. If I want to update the UI, I update the state, and the UI reacts.

Roku uses SceneGraph. It’s a node-based architecture. But here is the catch: Threading is manual and strict.

1. Concurrency: Coroutines vs. Task Nodes

In Android, fetching data is a simple suspend function.

Android (Kotlin):

// Modern and clean
viewModelScope.launch {
    val data = repository.fetchPlaylist()
    _uiState.value = data
}

On Roku, you can't just run a background thread. You have to create a Task Node (literally an XML file representing a thread), spin it up, pass it data, and then have your main thread observe a field on that task to see when it changes.

Roku (BrightScript):

' 1. Create the task object
m.contentTask = CreateObject("roSGNode", "ContentTask")

' 2. Set the observer (callback)
m.contentTask.observeField("response", "onContentResponse")

' 3. Trigger the task
m.contentTask.control = "RUN"

2. The Missing Operators

I caught myself constantly trying to use Kotlin conveniences.
I’d type:

m.top.posterUri = item.thumbnail_url ?? "pkg:/images/placeholder.png"

BrightScript: "We don't do that here."

I had to write helper functions just to check if a string was valid without crashing the app.

The Trenches: 3 Bugs That Almost Broke Me

Developing for digital signage is different from developing a streaming app like Netflix. Netflix expects you to watch for 2 hours and turn it off. Digital signage runs 24/7. It must never sleep, never crash, and never complain.

Here are the specific technical hurdles I hit, and the "MacGyver" workarounds I used to fix them.

Bug #1: The "Double JSON" Parsing Error

The Issue: One of the data streams we consumed had a serialization inconsistency. Specifically, JSON data sometimes arrived as native JSON objects, and other times as Strings containing JSON.

Scenario A: API returns "{ 'id': 1 }" (String)

Scenario B: API returns { 'id': 1 } (Object)

The Roku Crash: Roku's ParseJson() is strict. If you pass it an object that is already parsed, or try to access properties on a string as if it were an object, the app crashes immediately.

The Fix: I implemented "Defensive Parsing" logic that checks the type at runtime.

' The "Double Parse" Workaround
if type(serverData.payload) = "roString"
    ' It is a string, so we must parse it manually
    serverData.payload = ParseJson(serverData.payload)
else if type(serverData.payload) = "roAssociativeArray"
    ' It is already an object, do nothing
end if

Bug #2: The Battle Against the Screensaver

The Issue: Roku is aggressive about preventing screen burn-in. If no user input is detected for 10 minutes, the screensaver kicks in. For a digital signage app, this is a death sentence.

The Complication: While we advise our users to maximize their screensaver timeout settings, many Roku devices generally do not offer a "Never" option in the consumer menu. The OS will eventually force a sleep mode if no media is playing.

The Failed Attempt: I tried setting screensaver_mode=disabled in the manifest. While documented, this flag is often ignored by the OS or flagged by the Store Certification team as a policy violation.

The Solution: I found a legendary hack deep in the developer forums. The 1x1 Pixel Ghost Video.

Roku will not trigger the screensaver if a video is playing. So, I created a component that plays a video that is invisible to the human eye but visible to the OS.

<!-- MainScene.xml -->
<Video 
    id="keepAwakeVideo" 
    uri="pkg:/images/silent_1sec_black.mp4" 
    width="1" 
    height="1" 
    translation="[-10, -10]" 
    opacity="0.01" 
    loop="true" />

Logic: It’s 1 pixel wide, 99% transparent, positioned off-screen, and loops forever.

Result: The Roku thinks, "The user is watching a movie," and keeps the screen awake 24/7.

Bug #3: No WebViews Allowed

The Issue: Our Android app relies heavily on WebView components to render dynamic web dashboards, embedded presentation slides, and third-party widgets.

The Reality: Roku does not support WebViews. Period. There is no HTML rendering engine available to developers in the SDK. You cannot simply "embed" a website.

The Workaround: We had to implement a simple fallback system.

If the content type is "Web Page," the Roku app automatically generates a QR Code using an external API (api.qrserver.com).

The UI displays a message: "Web content not natively supported on Roku. Scan to view on mobile."

It wasn't the seamless experience we had on Android, but it saved the feature from being cut entirely.

UI Limitations: The Font Struggle

Polishing the UI made me miss Jetpack Compose dearly.

In Compose, if I want a text header to be 24sp, I just write fontSize = 24.sp.

On Roku, you technically can use custom fonts, but the implementation is incredibly verbose. According to the docs, you have to define a Font node, set the URI to a .ttf file, and assign it to the label.

<!-- The XML way -->
<Label>
  <Font role="font" uri="pkg:/fonts/my_font.ttf" size="24" />
</Label>

But what if you just want to use the System font, but slightly bigger?

Roku provides presets like MediumBoldSystemFont or LargeSystemFont. But if Large is too small and ExtraLarge is too big, you are stuck.

To get our branding right without importing custom TTF files for every single variation, I ended up using a programmatic override in the BrightScript logic:

' The BrightScript way: Manually instantiating nodes
label = CreateObject("roSGNode", "Label")
font  = CreateObject("roSGNode", "Font")
font.uri = "font:MediumBoldSystemFont" ' Start with a preset
font.size = 58 ' Override the size manually
label.font = font

It works, but it’s 5 lines of code for what takes 1 line in Compose.

The Verdict: Android vs. Roku

After three months of wrestling with the emulator and finally testing on a real TV, I created this mental map for any Android dev attempting this migration:

Feature	Android TV (Kotlin)	Roku (BrightScript)
Threading	Coroutines (Easy)	Task Nodes (Manual, XML-based)
State	StateFlow / LiveData	observeField (Callback hell)
HTML	WebView (Full support)	Unsupported (QR Code fallback)
Fonts	.ttf / Dynamic Sizing	Verbose XML setup or Manual overrides
Memory	Robust Garbage Collection	Strict ref-counting (Watch for mem leaks!!)
Background	WorkManager	None (App freezes on exit)

My Advice to My Past Self

If I could travel back in time back to November, I would tell myself:

"Don't fight the platform. It is not Android."

In the beginning, I tried to force Android architecture patterns (MVVM, Repositories) into BrightScript, and it caused nothing but friction. Once I accepted SceneGraph for what it was: a hierarchical, event-driven state machine, the code started to flow.

It’s like learning a language from a different era. It requires patience, but there is a strange satisfaction in mastering its strict rules. Plus, seeing our app running flawlessly on a $25 device in a busy hotel lobby? That makes the struggle worth it.

Building a Comprehensive E2E Test Suite with Playwright: Lessons from 100+ Test Cases

Eric Elikplim Sunu — Mon, 24 Nov 2025 23:51:43 +0000

The Journey

While developing the platform for LiveSpaces, I identified a critical gap in our delivery workflow. As the application grew, our reliance on manual verification and our existing CI/CD checks proved insufficient. We needed a way to streamline release cycles without sacrificing quality.

I took the initiative to build a comprehensive End-to-End (E2E) test suite using Playwright, but I underestimated the complexity. It wasn't just about clicking buttons; it was about handling authentication flows, managing device states, and dealing with third-party integrations securely and reliably.

From authentication flows to device management, every feature presented unique challenges. Here is a retrospective on the architecture I built to solve these bottlenecks, the decisions I made, and the lessons I learned.

Prerequisites

This post focuses on advanced patterns and architectural decisions rather than basic installation. I assume you are familiar with the basics of Playwright or similar E2E tools (Cypress, Selenium).

If you are brand new to Playwright, I highly recommend checking out the official documentation first.

Quick Context:
The examples below use:

Framework: Playwright (Node.js)
Language: JavaScript/TypeScript
Pattern: Page Object Model (POM)

What I Built

100+ Test Cases Across 6 Major Areas

Email Signup Flow — The complete journey from registration to business setup.
OAuth Integration — Signup and signin flows with comprehensive mocking.
Device Pairing — Device pairing logic using 6-character OTP codes.
Device Management — Renaming, deleting, and managing device settings.
Account Type Selection — Complex modal handling for onboarding flows.
Business Information Forms — Industry, demographics, and capacity selection logic.

Key Challenges & Solutions

Challenge 1: Email Verification in Tests

The Problem: I could not access real email inboxes (Gmail/Outlook) reliably in automated tests. Using real inboxes made the tests slow, flaky, and prone to security blocks.

The Solution: I implemented a smart mocking strategy.

Development: I mocked the email verification endpoint to return a fixed success response.
Production/Integration: I documented hooks for services like Mailosaur for when real delivery testing is strictly necessary.

Code Example:

// Mock the verification code endpoint to bypass email delivery
await page.route('**/api/verification/send', route => {
  route.fulfill({
    status: 200,
    body: JSON.stringify({
      success: true,
      code: '123456' // Fixed mock code for testing
    })
  });
});

Challenge 2: OAuth Testing

The Problem: Automating third-party providers (Google, Facebook) is often a violation of their Terms of Service. Furthermore, dealing with 2FA, captchas, or external popups leads to incredibly flaky tests.

The Solution: Comprehensive OAuth flow mocking. Instead of visiting the provider, I intercepted the callback that the provider would have sent to our application.

Code Example:

// Mock the OAuth callback
await page.route('**/api/auth/oauth/callback**', route => {
  const url = new URL(route.request().url());

  // If the app is trying to exchange a token, give it a mock user
  if (url.searchParams.has('access_token')) {
    route.fulfill({
      status: 200,
      body: JSON.stringify({
        jwt: 'mock_jwt_token',
        user: { id: 123, email: 'test@example.com' }
      })
    });
  }
});

Challenge 3: Integration vs. Mocked Tests

The Problem: I needed fast feedback loops during development (mocks) but actual verification before deployment (integration). I didn't want to maintain two separate test suites.

The Solution: Dual-mode test files. I designed the tests to auto-detect the presence of an authentication token in the environment variables to decide whether to mock network requests or hit the real backend.

The Logic Flow:

Code Example:

const AUTH_TOKEN = process.env.AUTH_TOKEN;
const USE_REAL_BACKEND = !!AUTH_TOKEN;

test.beforeEach(async ({ page }) => {
  if (USE_REAL_BACKEND) {
    console.log('Using REAL backend');
    // No mocks; allow requests to pass through
  } else {
    console.log('Using MOCKED mode');
    // Apply mocks defined in separate helper files
    await applyNetworkMocks(page); 
  }
});

Challenge 4: Test Data Cleanup

The Problem: Integration tests running against a real backend leave behind "zombie" data (e.g., created devices), causing subsequent tests to fail due to duplicate name errors or database bloat.

The Solution:

Strict try/finally blocks for guaranteed cleanup within the test.
(Pro Tip: For larger suites, moving this logic into Playwright Fixtures is the preferred pattern).

Code Example:

test('should create and manage device', async ({ page, request }) => {
  let testDeviceId = null;

  try {
    // 1. Create test device via API
    const response = await request.post(`${API_URL}/devices`, {
      headers: { Authorization: `Bearer ${AUTH_TOKEN}` },
      data: { name: 'Test Device', code: 'TEST123' }
    });
    testDeviceId = (await response.json()).data.id;

    // 2. Test the UI flow interacting with this device...
    await page.reload();
    await expect(page.getByText('Test Device')).toBeVisible();

  } finally {
    // 3. Always cleanup, even if the assertion above fails
    if (testDeviceId) {
      await request.delete(`${API_URL}/devices/${testDeviceId}`, {
        headers: { Authorization: `Bearer ${AUTH_TOKEN}` }
      });
    }
  }
});

Challenge 5: Async Component Loading

Problem: Third-party components (maps, custom dropdowns, modals) load asynchronously. Tests were failing because they tried to interact with elements before they were truly interactive.

Solution:

Use explicit synchronization points with locator.waitFor()
Avoid waitForTimeout (hard sleeps)
Distinguish between assertions (expect) and waiting (waitFor)

Result: Reliable tests that handle real-world timing without flakiness.

Code Example:

const mapInput = page.getByTestId('map-input');

// ❌ Bad Practice: Hard wait
// await page.waitForTimeout(1000);

// ❌ Common Mistake: Using assertion as a wait
// await expect(mapInput).toBeVisible(); // This is an assertion, not a strict wait step

// ✅ Best Practice: Explicit synchronization
// Wait specifically for the element to be ready before proceeding
await mapInput.waitFor({ state: 'visible', timeout: 10000 });

// Now safe to interact
await mapInput.click();

Update: Thanks to @dirtydiesel46 in the comments for pointing out the distinction between expect (assertion) and waitFor (synchronization). The examples above have been updated to reflect this best practice.

Challenge 6: Portal-Based UI Components

The Problem: Modern UI libraries (like Radix UI or Headless UI) often render dropdowns and modals in "portals" at the bottom of the <body> tag, physically outside the component that triggered them.

The Solution:

I used specific ARIA roles.
I scoped locators correctly to escape the current container and search the document root.

Code Example:

// The dropdown trigger is in the main container
await page.getByRole('button', { name: 'Options' }).click();

// The menu itself is in a portal at the document root
// We wait for the menu specifically to be visible
const menu = page.getByRole('menu');
await expect(menu).toBeVisible();

// Click the item inside the menu
await menu.getByRole('menuitem', { name: 'Rename' }).click();

What Worked Really Well

1. Page Object Model (POM) Pattern

Centralizing selectors in reusable classes was the single highest-ROI decision I made. When the UI changed (and it did often), I updated one file instead of 20.

The Architecture:

Code Example:

// pages/AuthPage.js
export class AuthPage {
  constructor(page) {
    this.page = page;
    this.emailInput = page.getByPlaceholder('name@example.com');
    this.loginButton = page.getByRole('button', { name: 'Login' });
  }

  async login(email, password) {
    await this.emailInput.fill(email);
    await this.loginButton.click();
  }
}

2. Comprehensive Documentation

Tests without documentation become legacy code the moment they are written. I created 15+ markdown files covering "How to run," "How to mock," and "How to debug." This dramatically reduced onboarding time for future developers and prevented "fear of the test suite."

3. Error Case Testing

Testing the "Happy Path" is easy. Testing the "Sad Path" is where value lies. I systematically mocked 404s, 500s, and network timeouts to ensure the UI handled errors gracefully (e.g., showing Toast notifications) rather than crashing.

4. Dual-Mode Testing

By using environment variables to switch between Mocks and Real Backends, a single test file serves as both a Unit-like Test (Mocked: fast, stable, deterministic) and an Integration Test (Real: slower, verifies backend contracts).

Key Learnings & Tips

Mock External Services: Never test Google's login page. Mock the OIDC response. You are testing your app, not Google's uptime.
Prioritize User-Visible Locators: Use getByRole and getByText over CSS classes (.btn-primary). This mimics how users find elements and makes tests resilient to styling refactors.
Always Cleanup: Test data pollution causes flaky tests. If you create it, delete it (preferably in a finally block or a fixture).
Wait Properly: Never use waitForTimeout(5000). If you find yourself doing this, you are likely missing a proper state assertion or an await expect(...).

The Numbers

Test Files: 10+
Test Cases: 100+
Lines of Code: ~5,000+
Coverage Areas: 6 major features
Confidence Level: High

Forem: Eric Elikplim Sunu

From Kotlin to BrightScript: How I Ported a Modern Android TV App to Roku

First Contact: No IDE, Just a Zip File

The Stack: A Primer for Web & Android Devs

The Paradigm Shift: Reactive vs. The Node Tree

1. Concurrency: Coroutines vs. Task Nodes

2. The Missing Operators

The Trenches: 3 Bugs That Almost Broke Me

Bug #1: The "Double JSON" Parsing Error

Bug #2: The Battle Against the Screensaver

Bug #3: No WebViews Allowed

UI Limitations: The Font Struggle

The Verdict: Android vs. Roku

My Advice to My Past Self

Building a Comprehensive E2E Test Suite with Playwright: Lessons from 100+ Test Cases

The Journey

Prerequisites

What I Built

100+ Test Cases Across 6 Major Areas

Key Challenges & Solutions

Challenge 1: Email Verification in Tests

Challenge 2: OAuth Testing

Challenge 3: Integration vs. Mocked Tests

Challenge 4: Test Data Cleanup

Challenge 5: Async Component Loading

Challenge 6: Portal-Based UI Components

What Worked Really Well

1. Page Object Model (POM) Pattern

2. Comprehensive Documentation

3. Error Case Testing

4. Dual-Mode Testing

Key Learnings & Tips

The Numbers

Further Reading