Tips, issues, ideas, possible future platforms.

[jbreemhaar]

Hi raphamorim,

I'm building/have build multiple Smart TV apps with React and TVOS with react-native. I didn't want to comment in every issue, but I have a couple of things to share which could be helpful. I love you're trying to unify building react apps for Smart tvs.

Samsung Toast

Have you looked at Samsung Toast? It's a builder (based on Cordova) and sets up a unified API for Samsung Orsay, Samsung Tizen and LG WebOS. To be honest I think it's pretty terrible to setup, but having tons of legacy stuff unified is great.

I think, if you just rip out the actual toast library, and possibly rip out the build system (creating config.xml, etc) you could have Orsay and Tizen support very fast.

Vewd/Opera TV

Opera TV, since 3 months known as Vewd, is another Smart TV app supply platform. They work (imho) with/on the lower-end spectrum of smart tvs (HiSense, some Sony tvs, Panasonic, Vestel, TP Vision, etc.). It's pretty easy to build apps since their API is pretty much the same as web (window.close, etc, but use a specific keycode set you have to get from the global window (;()). They don't use 'hosted' apps like lg and Samsung, but use urls. What I think is plausible is to use react-tv to build a Vewd app, and let the creator/user host it themselves.

Amazon Firestick

Same as Vewd, not hosted but application urls. Very, very close to web API. Could work with a almost identical build as Vewd, but some different keycodes, eventlisteners.

Chromecast

Chromecast, besides streaming, can run complete JS applications. Also works with application urls. It has very basic HDMI-CEC support (although afaik they're working on it, it doesn't have navigational support). It's very doable to setup a virtual remote control (in web/app) to publish keyevents to the chromecast app. Maybe it's not really the target of this library, but it could be very cool.

Metrological

I don't think it's doable, but it could be researched. They have their own Metrological SDK, which is very limiting. They run on tons of set-top-boxes, e.g. Comcast, Liberty Global with KPN and Ziggo (Dutch), ooredoo (Qatar).

React Native tvOS

I'm/we're using an almost completely sharable codebase between React native for tvOS and web. It's very doable to write a cross platform abstraction layer for views and device/web api.

React Native Samsung

Samsung and Microsoft promised to team up with Facebook to deliver support for React Native on Tizen. This was more than a year ago but only Microsoft delivered. I haven't read any news coming from Samsung since then, but... drumsounds... I've just noticed this repo was created 10 days ago. So maybe they're going to start?

Spatial navigation

I've written a custom implementation for spatial navigation, but thinking/working towards transitioning to Luke Chang's Spatial Navigation. I've already seen it mentioned in the issues here, I personally think react-tv should work towards getting that to work instead of going for a custom solution. It can take a lot of time to build something custom, and it will probably suck. Atleast two issues should be fixed in spatial-navigation; custom keyEvents and continuing in grids (last of row in grid > first of next row in grid instead of a full stop).

Debugging

Maybe you've already ran into the issue of debuggers not working, working crappy, I've switched to Weinre to atleast have one reliable debugging tool cross platform.

So, this is what I currently could think of. I'll definitely keep checking out the progress. Please let me know if you're stuck on stuff! Sorry about the title of this issue, I couldn't think of anything better.

Edit. Typos etc.

[raphamorim]

I love it.
Thanks for sharing it with me.

I think that's the future.

Samsung Toast

Seems promising.

Vewd

Make sense to support it in next react-tv versions.

Amazon Firestick, Chromecast, Metrological

definitely I'll make some experiments <3

React Native Samsung

Whoa, seems promising. Let's wait to see.

Spatial navigation

Yup, I agree with you. Spatial Navigation in draft on React-TV

[raphamorim]

I saved your ideas in a note @jeroentradecast. Thank you for sharing it.

[hizo]

@jeroentradecast @raphamorim another remote debugger tool we use is http://www.vorlonjs.io

[jbreemhaar]

@hizo Thanks! I'll definitely check it out.

[jfrux]

Here are my composed thoughts as of today on where I think I'm looking to be and what I think this space needs in a library or cross-platform environment... Also, sorry if this has been discussed heavily already.. I'm not experienced with react or react-tv but I'm wanting to find more efficient ways to write my interface and code to make it run better on the "Web URL's" category of TV / Devices as per below so that's why I'm interested in this.

First off...
Not liking any mentions of using Toast. Forcing our tool to use another external build tool seems kind of odd, when React ecosystem has plenty to offer in this area. Unfortunately their scope is small and Cordova is overkill for these types of things. As I see it, there are only a hand-full of top tier platforms that require you to actually build files into a package and upload to their (mostly) shitty seller stores... Samsung, LG, AppleTV, FireTV, and Roku. The vast majority of the other platforms (if you care to get your app on EVERYTHING for ultimate brand saturation) will require you to maintain a library similar (but not) to BBC's TAL where you have some sort of hybrid SSR/client app that understands the platform its on and appropriately injects modules needed to make them work.

I'm currently working with several young platforms with big returns, Vizio SmartCast and HiSense. We've seen amazing adoption of our app in SmartCast very early on. Even more significant numbers than we have seen on FireTV which surprised us. These platforms, should be EASY... but you must understand there are three key issues that I think must be configurable easily per platform for adoption of react-tv to work.

Three "Types" of OTT / ConnectedTV platform builds needed.

For full saturation, ideally, we would only maintain a single code-base for these.

Zipped up locally ran static web files

These platforms are basically Samsung and LG, I'm sure there are others but you basically need a platform specific config template that gets overridden with react-tv-cli commands, and then will run the external CLI tools to build it into a package, run it in an emulator, etc.

Proprietary language platforms

Roku and AppleTV. Although AppleTV has TVML, its still not "just web" in the end.
I think someone could somehow solve the Roku problem with React Native somehow I'd imagine, although I'm not a React expert. I would think we could translate (with enough effort) a specific React structure, over to Roku SceneGraph and those things if we thought long and hard on it.

(I think these two should be second-class citizens in the scope of React-TV, but SHOULD BE in the pipeline at some point)

Web URL (easiest of all)

If we truly want brand saturation, and I think that would be the ultimate goal if you're building OTT apps in general, the framework should support the DOM in some form.
I'm not sure if React-TV supports this, or why it wouldn't, or doesn't already?

I think its really just a matter of packaging.

I have an Ember app I'm maintaining now that works in all of these different platforms and has a unified command-line deployment for Samsung Tizen, LG WebOS, and Everything Else (aside from AppleTV and Roku).

ember deploy webos-production-patch
ember deploy samsung-production-patch
ember deploy smartcast-production-patch

These webos uses webOS cli, samsung uses tizen commands, and smartcast / xboxone / windows / hisense / element all deploy via SCP (S3 static sites currently but I might combine them all into a single SSR app with React to speed things up)

Configs

Configs probably shouldn't and won't be just a JSON file.
More like, a "platform" class that injects any JS lib that is required for that platform, and each platform class will need one of the 3 types mentioned above specified so that the CLI knows how to proceed during building. If its not a built platform, and it falls into webURL, then it really just has to worry about injecting the platform-specific JS SDK libraries needed to make things work.

Base Structure to Pass QA

Generally every TV app will need these types of files as base classes.

Each platform will need:

• MediaPlayer class (combination of state / ui)
  - This would literally just abstract out the platform-specific SDK versus the HTML5 Video/Audio API's and use whichever the class extends from. Probably would default to HTML5 obviously.
• Network class (just state mainly, but will probably have some spinners / error messages that will dispatch to an overlay component somewhere.)
  - Monitors network up / down state, if they pull the network cable, or wifi drops, needs ways to dispatch these events. Most apps won't pass QA without these. Samsung / LG are pretty strict on apps that will be promoted or get mainstream attention.
• Input class (for state, event binding, and key configuration importing (this could be from a json config I'd guess)
• Device class (this might be optional, I use it for things like device information, UDID, serial number, stuff like this if somebody needs it for things. Possibly even supported resolutions, features, TV settings that are enabled / disabled such as TTS, etc.

I'm sure I'm missing some stuff but I wanted to just document my thoughts before I forget.

And we can override them per platform: