Top reasons TV app developers should use native Android APKs instead of WebView

I have worked in web development for a long time, building rich web-based TV app before the term AJAX was coined! It was shortly after JavaScript became a more widely valued programming language that I started working for ActiveVideo. Building web-based HTML5 applications for TV became my bread and butter, and I’ve been living and breathing TV app since. 

In the last three years, I’ve been working more and more with non-web-based apps, specifically apps made for Android TV, and while at first, I believed that you could do things better using a shared HTML5-based application wrapped in a WebView, I just can’t say that anymore.

And there are four reasons why:

Reason 1: Video playback is too hard to get right

I’ve built TV app using all the major video players (hls.js, VideoJS, Shaka Player, dash.js, etc). Each has its strengths, and supported formats. But you can’t do it all with one player, and just when you think you can, when you try it on a different device like a Comcast FLEX or Vizio TV, issues arise and you find yourself debugging for days or even weeks. And then you need to add new features – it could be to incorporate VAST ads, or server-side ads with additional plugins – and the video playback portion of the app needs re-architecting.

Even a WebView wrapped web-app that delegates video playback to ExoPlayer will notice immediate benefits. Faster initial playback, smoother transitions between videos, easier maintenance when the streaming format needs to be swapped out (switching from HLS to MPEG-Dash), or swapping out advertising solutions. While ExoPlayer is not the only native player, it is used by most of the heavy hitters, and is hands down the most stable, quick, and fully-featured player to use when building apps for Android TV.

Reason 2: Snappy user experience

When building a web-based TV app, developers have spent hours of anguish when dropping it onto a new device and finding the key response time exceeds half a second or more. Sluggishness is a plague. And the solutions we resort to? On the lowest of target devices, we will disable animations altogether, or rewrite our entire application and optimize it to the umpteenth degree until our application resembles something from 2003. And if we get it just right, there is no guarantee that those optimizations will cut it or map 1-to-1 onto another target device.

This simply is not true for native Android interfaces on TV. Say yes to animations. Say yes to speed-scrolling, and not just something called speed-scroll, no – your app will literally fly through rows of movie posters.

Reason 3: Animations are back!

I touched on this above briefly, but this deserves its own shout-out. Many major content providers rely on WebView to bring their web-based applications to Android, and other frameworks such as Lightning (HTML 5 & WebGL). Getting animations right is something that is done for each target device one animation at a time – and the result is often navigation that uses watered-down animations or even worse, completely disabled animations! Some do get it right, but they must do this exercise over and over, and it is very difficult to keep a consistent brand experience across devices.

Going into native Android layouts, almost immediately you will find that animations relying on natural feeling physics are available almost out of the box, and the frame rates are night-and-day in comparison to a web-based UI/UX. It’s safe to say most of us always knew this, but we try so hard to make our web-based applications extend to Android devices to save time, but in the end, we sacrifice in terms of end-user experience.

Reason 4: Workflow and debugging

Let me start with a story about a device I recently had to integrate which shipped with a variant of Opera from 2016. If you think that is not realistic, well – this device is in hundreds of thousands of homes. On receiving the device, the documentation points to a serial port connection. With a good USB-to-Serial adapter, I install CoolTerm, configure some settings, and see some garble printed. With an RSA dongle, and after several days or multiple calls and emails with support, I unlock the device via my serial connection. Then I load my web application in the browser, and it complains about SSL (need to manually set the date of the device each time it reboots), unsupported web APIs, and when it finally loads, my application which ran amazingly on a Vizio TV doesn’t even render. The next two weeks are spent making the application compatible with this device. In the end, I had to disable most animations, replaced the HLS.js based video player with the proprietary player this device ships with, and finally, after three weeks, I have something I can even call a usable experience. And wait until you see what happens when this same device runs at 1920×1080! Painful. Debugging web applications is NOT always easier. Sure, when the stars align and we are given a modern development environment and device, we can get right to work, but more often than not we are dealing with a unique setup for each device.

This is where the Android Emulator and Android Debug Bridge come in. With these, developers can target different API versions, devices, and resource constraints, or connect directly to the device. We can create a wide variety of emulated devices that more closely mimic the actual device, allowing us a much more full-featured integrated development environment than when we are building for chromium WebViews on the same devices.

Conclusion

Those who have built web-based applications and leaned all-in have a lot to lose if they can’t get their apps to work on par with native Android-based applications on smart TVs and devices. We did this for mobile with mixed results, and we are doing it again for TV, and it does “work”. But developers want their apps to do more than just reach the users. They want those users to have snappy and smooth navigational experiences across the board, with video playback that is best-of-class. In my experience, if I’m aiming to do that, on the widest range of devices, I am going to build it as a native Android app.

But there is still the question of how to maximize the devices I can deliver an Android app to? Through virtualization and a cloud-native approach its possible. The native Android app runs natively, but in the cloud, using virtualization technology, to the user and the local player in the device it appears as if everything is running natively on the device, For the content, the video stream is still delivered directly to the device, decoded and rendered at the device.

For more you can contact our team

Blog Source- https://www.activevideo.com/blog/top-reasons-tv-app-developers-should-use-native-android-apks-instead-of-webview