TypeScript-first application code
Write screens, state, services and product logic in TypeScript, with types and language tooling available throughout the application layer.
FROM FOUNDATIONS TO FINISHING TOUCHES
Explore the architecture, workflows and native capabilities available for building and evolving products across platforms.
Product model
The foundations that keep product intent readable, testable and portable as the application grows.
Write screens, state, services and product logic in TypeScript, with types and language tooling available throughout the application layer.
Describe a view tree in code and let Hosanna create, update and dispose the target-specific rendering objects behind it.
Connect typed state to view output so a product change is expressed as an application-state change rather than a trail of manual node mutations.
Add, remove, reorder and reuse children as state changes while Hosanna reconciles the live target view tree and preserves clean lifecycle boundaries.
Compose screens from maintainable view classes with explicit mount, unmount, focus, observation and disposal hooks that run in a defined order.
Register and resolve shared services through the IoC container, keeping platform facilities and product code behind clear interfaces.
Model shared state with observable objects so screens and services can respond to typed changes without tightly coupling their implementations.
Use typed publish/subscribe notifications and a central action manager to coordinate navigation, playback, analytics and state changes.
Keep the product model shared while placing genuinely platform-specific behaviour in named adapters, extensions and target files.
Async and background work
Commands, task pools and function pointers make background execution a first-class part of the product model instead of a platform-specific afterthought.
Turn an exported class method into background work by adding command category and command annotations, while Hosanna generates the handler map and command contract around it.
Dispatch named work through generated command constants and typed payloads instead of hand-wired strings or platform-specific worker messages.
Declare named worker pools and their concurrency in build configuration, including dedicated lanes for analytics, storage or other workloads that must not compete.
Route a command to a chosen task category or task instance when ordering, isolation or predictable use of a background thread matters.
Use HsPromise with then, catch, finally, all, race and allSettled, plus parallel and sequential helpers, across Hosanna's supported runtimes.
Write supported async functions with await in application code while the Hosanna compiler lowers them to promise-backed BrightScript state machines, including branching and try/catch.
Observe progress and completion, cancel work that is no longer relevant, and pause or resume commands whose handlers support it.
Pass exported function pointers into background work and resolve them safely inside task-local execution contexts without capturing a UI closure or its this binding.
HTTP and data transport
The shared HTTP layer covers ordinary API calls, response processing, tests, diagnostics and durable file transfer without blocking the render path.
Make GET, POST, PUT, PATCH, DELETE and HEAD requests through one command contract with consistent behaviour across supported targets.
Dispatch network work through Hosanna's async command system so request and response handling do not stall focus, animation or rendering.
Set headers, bodies, credentials and timeouts, retain error bodies when needed, and cancel an in-flight request when its result is no longer useful.
Receive one response shape for status, headers, JSON, text, success state, resolved IP address and caller-supplied context data.
Pass an exported postProcessFunction and contextData with a request so response-specific work can run safely on the background task before control returns to the caller.
Register responses by HTTP method and URL, then exercise the same command and post-processing path without a live service.
Download through a temporary partial file that is renamed only after success, clean up failures, and inspect a reproducible curl form of each request when debugging.
Configuration and DSL
AppConfig carries presentation, reusable view fragments and target variations separately from the stable application core.
Keep design tokens, control variants, fragments, CollectionView settings, translations and device-specific presentation in a declarative product file.
Centralise colours, fonts, shapes, sizes and other product values in one style system shared by every target.
Resolve named styles, extend shared definitions and apply local overrides instead of repeating presentation objects throughout screen code.
Define reusable fragments as configured view trees, then mount them through FragmentView or use them as CollectionView cells.
Bind item data into fragment fields and use explicit providers or callbacks when a configured component needs derived behaviour.
Pin, fill, inset and size fragment children and CollectionView cells from inline constraints that can respond to cell size, screen metrics and safe areas.
Derive fragment fields and constraint arguments from declarative inputs while keeping the resolved result visible to tooling and the runtime.
Start with a base AppConfig, then inherit focused phone, tablet, TV, web or platform variants without copying the whole product configuration.
Resolve base, environment, platform and named developer-profile overlays into one runtime build configuration with a traceable merge order.
Merge company and developer secret overlays at build or dev-server time while keeping source secret files out of the packaged application.
Maintain explicit development, QA and production configurations, with platform-specific overlays and opt-in developer profiles for local work.
Collections
CollectionView handles the scale and behaviour of rails, grids and mixed content without turning each screen into a bespoke renderer.
Build rails, grids and mixed collection screens from an ordered data source and reusable row and cell definitions.
Combine row types, cell sizes, spacing, headers and per-row settings in the same scrolling experience.
Compose each CollectionView row with configurable header and footer fragments, data mapping and layout constraints instead of limiting row chrome to a fixed label.
Own ordered rows, stable row IDs, versions, loading state and pending change notifications in a dedicated runtime model.
Create and retain only the visible working set needed for the current viewport rather than mounting an entire catalogue at once.
Reuse rendered nodes and replay configured default field values so recycled cells do not leak visual state between items.
Apply row and item changes without rebuilding the entire page, and batch related work to reduce layout and render churn.
Configure request parameters, headers, bodies, loading state and dynamic row behaviour for collections backed by remote data.
Load collection rows from HTTP or a func:// callback, pass parameters and context, choose eager or lazy paging, cancel stale work and post-process results through the same data-source model.
Respond to focus, selection and lifecycle events, then jump or scroll to known rows and items through explicit APIs.
Use a complete Hosanna view as a custom row when standard horizontal, list and grid rows are not enough for the product experience.
Register product-owned row types, loaders, triggers, post-processors and callbacks while retaining the same JSON-driven collection model.
Run named or TypeScript callbacks on row mount, content readiness and variable-width layout to add behaviour without forking CollectionView.
React to mount, unmount, data changes and normal, focused, selected or disabled status inside configured cells and fragments.
Render modest lists, grids and nested repeated content without adopting a full CollectionView, with constant or variable item sizes and scroll-aware virtualisation when needed.
Build two-dimensional schedules with channel rows, variable-duration programme cells, time headers and synchronised channel and timeline overlays.
Choose how content moves around the focused item in each direction, including fixed, floating, hybrid and closest-item behaviours for deliberate television navigation.
Keep navigation or header rows anchored while content scrolls, and lay out rails whose cells derive their width from the item rather than a single fixed template.
UI and controls
Primitive views, composed controls, text entry and motion share the same state, style and focus model.
Create labels, multi-style and vertical text, rectangles, images, video players, loading skeletons and native keyboard surfaces from typed view builders.
Lay out children with HGroup, VGroup and GridGroup while retaining direct control over spacing, sizing and translation.
Resolve packaged, downloaded and remote image sources through the platform layer and represent pending content with reusable skeleton rectangles and circles.
Choose image display modes, dimensions and tinting from shared view state, with resolution-aware assets and nine-patch scaling for stretchable product artwork.
Cache remote artwork, expose load status, supply loading and failure images, and retry failed or stalled requests with configurable delays and timeouts.
Use buttons, button groups, checkboxes, comboboxes, label lists and tags without rebuilding basic interaction semantics.
Choose text boxes, mini keyboards, native keyboards and platform-appropriate text entry while keeping the form model shared.
Scroll smaller raw view trees directly when a full virtualised CollectionView would be unnecessary.
Present modal product moments with popup, dialog, keyboard-dialog and PIN-pad building blocks that participate in navigation and focus.
Animate view properties and configure push, pop, replace and tab transitions through Hosanna and ViewJSON animation systems.
Define reusable vector shape styles in JSON or create them from typed builders, then render the same shape intent across supported targets.
Generate shape assets just in time, embed them in the application package or deliver precompiled shapes through asset bundles to match the product's startup and deployment needs.
Clip images, video and composed view trees with reusable masks, including shape-backed masks in configured CollectionView fragments.
Present structured rich text, long-form scrollable copy and ordinary labels through the same view, font and focus systems.
Drive individual renderer fields or coordinated view-tree states from typed code and JSON-friendly animation definitions.
Load and control Rive files as Hosanna views, including state-driven playback and animation progress linked to CollectionView focus.
Host an allow-listed web page or inline HTML on web and supported touch devices, exchange messages with the app and fall back explicitly on television targets.
Localisation, accessibility and assets
Localised copy, audio guidance and versioned assets are configured capabilities rather than late platform patches.
Store i18n keys in AppConfig and resolve them from views, JSON data maps and application settings instead of hardcoding copy into screen logic.
Change the active locale at runtime and resolve language-specific copy and @locale asset paths from the same configuration.
Declare reading direction by locale and use target-aware layout configuration for right-to-left product variants.
Queue and prioritise spoken guidance through the text-to-speech manager, with flushing and debugger controls for the Roku audio-guide path.
Use voice text buttons and native voice text editing controls where a target makes speech input available.
Register theme fonts once, resolve font keys in configured views and map them to web or native target resources.
Resolve packaged, locale-specific and downloaded resources through stable asset references instead of scattering target paths through code.
Download bounded asset bundles with concurrency control, gate rendering on required files, invalidate by version and start from packaged or cached configuration when offline.
Keep colours, fonts, shapes, spacing and component variants in shared AppConfig styles while renderers resolve the target-specific details.
Platforms
Hosanna shares application structure without pretending every target has the same renderer, input hardware or native services.
Run the product in a fast browser loop with selectable television, phone and tablet device profiles.
Compile the Hosanna application into BrightScript and SceneGraph structures that run as a native Roku channel rather than a web view.
Run shared Hosanna JavaScript through the Apple platform shell on iPhone and iPad, with explicit bridges to iOS facilities.
Target tvOS with television input, playback and native extension points while preserving the shared application model.
Build and launch the product for Android phones and tablets using the shared runtime and Kotlin or Java bridge boundary.
Use the Android television path with remote input, television layouts and target-specific native services.
Keep Samsung-specific runtime and packaging concerns behind the platform target while sharing the application and configuration layers.
Query target capabilities and route input, media, sharing, storage and other services through typed per-platform implementations.
Read live safe-area insets and content bounds through the shared device model so phone cutouts and television overscan do not require scattered platform checks.
Create and operate SceneGraph nodes directly when a Roku experience needs a native surface beyond Hosanna's higher-level views.
Native services and media
Shared TypeScript can call explicit platform services, and unusual requirements can still reach native APIs directly.
Define command payloads and results at the shared boundary, then implement them in Swift, Kotlin, JavaScript or Roku target code.
Connect shared product controls to platform video, native media-session state and target-specific playback integrations.
Drive HLS and DASH playback through the shared video model, including DRM headers and target-specific protected-stream implementations where the device supports them.
Expose audio and subtitle tracks, scrub-preview thumbnails, playback speed and playlist position through observable shared player state.
Use shared Audio and SoundEffect contracts for long-form playback and short product sounds while each runtime selects its native audio implementation.
Expose WebKit AirPlay and Apple-native media capabilities through the platform video service where the target supports them.
Use the Chromecast Web Sender or a native cast bridge while keeping cast availability and session state in the shared service contract.
Open the platform sharing surface from shared product code and receive a typed completion result.
Integrate Roku ChannelStore and native billing or in-app-purchase SDKs behind a product-owned store boundary.
Connect the SDKs your product already uses without moving analytics, identity or persistence concerns into screen code.
Handle launch data, network status, notification registration and foreground or background transitions through shared interfaces and target event listeners.
Use shared APIs for purchases, notifications, action sheets, sharing, casting, storage and other common device features while keeping direct native access available.
Read, write, rename and remove local files, persist typed key-value state, and download or upload files through shared service contracts with target implementations.
Start, observe, pause, resume, list and delete native downloads on supported mobile targets, with progress snapshots and a playback URL when the platform can play before completion.
Use base64 and URL-safe encoding, SHA-256 hashing, symmetric encryption and device-bound encryption from TypeScript without hiding platform-specific security constraints.
Developer workflow
The development loop is designed around TypeScript, local project tooling and commands that remain scriptable in CI and by agents.
Use the versioned Hosanna tools package declared by the app instead of depending on an untracked global installation.
Launch the web runtime quickly for ordinary UI work before moving the same product scenario to the hardware that matters.
Use the supported refresh path on web and hot-reload launch modes on Apple and Android targets during active development.
Validate, build, launch, test and package web, Roku, Apple and Android targets through consistent hst commands and project scripts.
List available browsers, profiles, simulators, emulators and physical devices, then select an explicit target for a run.
Translate supported TypeScript application code into BrightScript while generating the Roku structures the target runtime needs.
Lint application code, AppConfig and bundle files with Hosanna-aware rules, catch unsupported or expensive target patterns early, and map generated failures back to the source engineers own.
Navigate style links and configuration references from the editor while keeping AppConfig and application code connected.
Use readable build flags such as development, production and target flags to remove inactive branches while compiling each product variant.
Choose the emitted log level, remove remote logging and timing calls, or strip console output entirely for leaner release builds.
Run generation, diagnostics, linting, unit and integration tests, target builds, metadata stamping and final packaging locally or in CI.
Debugging and observability
Hosanna debugging joins application state with target output so investigation does not stop at a console message.
Connect the browser extension to a running Hosanna application for remote control, inspection, recording and diagnostics.
Inspect the framework view tree, IDs, state and ownership on web and Roku without reconstructing the screen from source alone.
Inspect both Hosanna and SceneGraph-style hierarchy context on web; on Roku use the serialisable Hosanna hierarchy with device logs, focus and runtime state.
Read the focused view, focus ancestry and directional graph to diagnose navigation that feels wrong on a remote.
Inspect visible rows, virtual positions, focused items, translations and data-source state while a collection is running.
Drive the current target with directional input, capture its visible result and retain the exact frame involved in a bug.
Collect searchable application and device logs, monitor chosen views and inspect registry, service or pooled-renderer state relevant to an investigation.
Record focus, collection, handler, render and watched-view changes as a searchable timeline, then export JSON or a reviewable HTML report.
Inject remote debugging, MCP, test mode, logging and product-specific diagnostic switches from explicit debug profiles rather than shipping them accidentally.
Connect web and device builds to the same proxy so DevTools and MCP can work from a consistent state, input, screenshot and log contract.
Route product-specific debug commands through the application boundary and add focused MCP tools as new runtime capabilities need to become operable.
Testing and delivery
The same toolchain supports fast logic tests, deterministic UI scenarios and target build matrices suitable for CI.
Test product logic, state transitions and isolated view behaviour in the normal JavaScript or TypeScript development environment.
Exercise complete journeys through a running application instead of limiting validation to isolated functions.
Replay known input sequences and assert visible or inspectable product state with stable scenario definitions.
Use the browser for speed, then run the important journey on Roku hardware rather than treating the simulator as final proof.
Validate iOS, Apple TV, Android and Android TV builds through non-interactive simulator or emulator commands.
Keep the evidence attached to a run so reviewers can understand what changed without repeating the entire investigation.
Track representative collection and runtime workloads against measurable baselines rather than relying on subjective smoothness alone.
Run lint, build, tests and target packaging in automation with explicit SDK versions and release-oriented project commands.
Record Apple simulators, Roku capture cards and macOS windows from the CLI, tests or MCP, then attach the MP4 and capture metadata to reports, tickets or pull requests.
Replace selected HTTP and service responses in development and tests so empty, error, delayed and recovery paths can be exercised without changing production code.
AI readiness and conformance
Hosanna exposes a bounded application operating surface while deterministic checks and retained evidence remain the acceptance layer.
Expose the running Hosanna application through documented Model Context Protocol tools rather than asking an agent to infer runtime behaviour from files.
Use get_state to obtain focus, route and CollectionView context in one bounded response before taking an action.
Let an authorised agent reproduce a journey with remote keys, focus changes and application navigation on the active target.
Give agents access to the same bounded hierarchy, focus, collection, log, screenshot and trace evidence used by engineers.
Allow test workflows to send deep links, read text-to-speech state and toggle the TTS path when validating a scenario.
Support the complete engineering loop around a well-scoped ticket instead of ending the agent workflow at code generation.
Use compiler rules, lint diagnostics, tests and target builds as machine-readable constraints on generated changes.
Keep code, screenshots, logs, state and deterministic regression results available for an engineer to accept or reject.
Performance
Hosanna combines native target output, bounded rendering work and diagnostics that make performance behaviour visible.
Produce BrightScript and SceneGraph output for Roku so the final channel uses the platform renderer and lifecycle directly.
Limit row and cell creation to the useful viewport and preload window even when the underlying catalogue is much larger.
Reuse compatible nodes and cells to reduce allocation pressure during repeated television scrolling.
Delay work until content is needed and combine related updates to reduce unnecessary render passes.
Tune list behaviour, pool defaults and retained data with documented memory and collection optimisation guidance.
Configure low, medium and high device tiers in AppConfig for pool sizes, graphics, animation and aggregate-view hibernation, then select the appropriate experience at runtime.
Record state mutations, rebuilds, handler consumption and selected property writes around an interaction.
Use renderer, view-tree and Rive animation paths with traceable state changes and performance evidence when motion becomes demanding.
Run racing, action, puzzle and multiplayer samples as demanding evidence of headroom beyond ordinary menu screens.
Games and real-time experiences
The standalone game samples exercise deterministic simulation, input, sprites, audio and persistence across web and Roku.
Run the same Hosanna game architecture in the browser development loop and the native Roku package path.
Keep gameplay rules in a pure, tick-driven model that can produce repeatable snapshots independently from the renderer.
Build real-time scenes from reusable sprite resources, atlas mappings and tile-based world data.
Translate remote, keyboard and supported controller input into a stable game input state consumed by the simulation.
Package and trigger named game audio resources alongside deterministic gameplay and rendered scenes.
Persist progression and connect entitlements or consumable fulfilment to the platform store model where a game needs it.
Exercise multiple simultaneous players and views in real-time samples that put meaningful pressure on input and rendering.
Explore racing, mini-golf, tennis, shooters, dungeon, puzzle and platform game examples with tests and standalone launchers.
Choose a 30 or 60 FPS runtime target and let the game loop accumulate frame time cleanly instead of wasting work between useful updates.
Host a controller page from the game, show a pairing QR code and turn a phone or other viable browser device into a local game controller.
Give each game its own controller layout, button labels, motion mapping and live state display while the transport stays game-agnostic.
Build gameplay, scenes, sprites, input and performance settings in TypeScript while the runtime handles the specialised Roku rendering path.
Ownership and extensibility
The framework provides leverage without hiding the source context or closing off the platform-specific work real products eventually need.
Licensed client projects can include the framework TypeScript sources, giving engineers the context required to inspect and debug the application.
Drop below the shared abstraction when the product needs a native API, SDK or SceneGraph capability that is not yet generalised.
Add a small typed adapter for a new service without restructuring every screen or waiting for a monolithic framework release.
Author reusable Roku nodes, tasks and native component libraries from the TypeScript toolchain, with generated wrappers for the target package.
Provide web, Apple or Android stubs for a SceneGraph or native extension so shared screens and automated journeys can continue on other targets.
Package TypeScript controls, player inlays, analytics, domain services and component libraries for reuse across products, including Roku consumers.
Hand engineers task-focused guides, runnable application samples and generated API material alongside the framework source.
Keep application code in a modern language with explicit service seams, repeatable tooling and regression evidence another team can continue to own.
Build shared code and component libraries for Roku consumers through the normal TypeScript toolchain without maintaining a separate specialist implementation.
Submit compiler or framework issues through a focused support form and bring a Hosanna engineer into the loop, with an under-one-hour resolution target.
See how Hosanna UI brings shared architecture, native performance and modern tooling together across every screen.