How building a hybrid application using Native code (iOS, Android, Windows) and a WebView helped dailymotion gain time! [WebView]

All views here are my own.

As a native software engineer you will often hear me say that for mulitple reasons building a native application is usually better than building a cross platform application, however this is another subject, and not for today! Here we’ll see why building a Hybrid application can help you gain time.

Intro

Working for dailymotion has allowed me to build from the ground up 3 applications (for 3 different platforms), rebuild our internal API SDK, refactor 60/70% of our latest application and finish the development of one application (Windows Phone 8.1). As you can imagine the dailymotion applications are composed of HTTP calls to our API, the response is transformed into a model that we then transform it into a list of videos. We have to handle all user actions, and of course we have to manage this little thing called video playback (dash, hls, smooth streaming, mp4 , etc), because what is the point of building a video application if you can’t view videos!

Here is a quick visual guide as to what an API could look like exactly:

Web APIs, image from MS

The dailymotion player

The player has always been at the heart of dailymotion.

Let’s go back to 2014 when we (dailymotion) used to develop multitudes of players, we had one for the web, one for TVs, one for OTT, one for iOS, one for Android, and one for Windows. This would take A LOT of time because each platform had to skin its native player to look like the official dailymotion player. Also, for each player we had to make sure that we were loading the media element correctly and that the playback was working as expected.

As company we need to be able to make a living, this is were ads come in. Our monetization system here at dailymotion is based on ads, we will show you personalized ads before the video loads which is known as pre-rolls, if you see an ads during the video this would be called mid-rolls and if you see an ad at the end of a video this would be called post-rolls. This means that for all platforms we had to write custom code so that we supported pre-rolls/ mid rolls/ post rolls. And also as we needed to be able to track how the media/the ad was being played for how long, if the user had seeked, skipped, muted the video ,etc.

This would mean that in the following languages: JavaScript, C#, Java and Objective-C/swift we would convert/re-implement the same algorithm into our code, we would basically rewrite the same code n times for the number of platforms we had (not the best way to use your time IMO). When an issue arose on one platform we would have to dig into it to see if it was because of the streaming protocol, the native player that had changed something, or if we had accidentally added a feature that broke the app. When we had an issue with the player we never really knew where it was coming from. Was it our player code? The platforms’ streaming stack? The video stream itself?

Player HTML 5

Two years ago, dailymotion undertook an ambitious re-organisation. We decided to revamp not just our product and content strategy, but also our WHOLE infrastructure, video stream delivery process and applications. This meant that we were able to start from scratch and thus pick the best solutions. We migrated our API to GraphQL and we decided that our player would be managed by one team and this team developed this new player in HTML 5: one player that would work everywhere.

As you can imagine a lot of R&D was done for this HTML5 player to ensure its compatibility with all platforms and our player team has also grown quite a bit to ensure it works everywhere.

Having one player, and one dedicated team that manages our player has greatly improved my productivity as it has given me the opportunity to focus more on the architecture of the application and not how the video delivery and stream was working. This has allowed us to have one point of contact when we encounter issues. When design improvements are made to the player, the new design is effortlessly updated across all platforms. Same thing when a bug is found, the fix can quickly be deployed because no new release of the native applications is needed, we just need to update the player endpoint.

One can ague that you can do all of this in your native application, it’s not that hard to have one developer per platform working full time on a Video Player. However, this would mean (best case scenario) that we would have at least 5 developers (iOS, Android, Windows, Web, Smart TV) working full time on the video player. Because we have limited resources we prefer to consolidate the knowledge and expertise into one team that would have the most impact on the whole company (our player team), and thus use one common technology across the whole platform.

Now that I no longer have to skin the player, I don’t need to investigate the MSDN Windows UWP documentation to understand how to create a specific media slider, or play with the media element, or how the Windows media player framework might be better to stream HLS streams, or how I would need to implement the finger seek feature in our player. Thanks to the dailymotion HTML 5 player everything is done for me!

So great, we’re talking about having one player for all platforms but what does it mean as a developer? How do we add html code to the native application?

Hybrid application

This is where the fun begins!

Having a Hybrid application means that at some point you’re using a WebView to load content. In our case we could imagine that we load our WebView with this: https://www.dailymotion.com/embed/video/x5s90td?controls=1&autoplay=1.

Then, once you’ve instantiated that WebView and your player, we’ll start exchanging information and calling methods. To call these methods your WebView will need to be able to execute JavaScript on the WebView.

On Android this means:

MyWebView.loadUrl(“javacript:”, myJsMethod);

On iOS this means:

MyWebView.evaluateJavaScript(myJsMethod)

On Windows UWP this means:

MyWebView?.InvokeScriptAsync(“eval”, myJsMethod);

For example, if you wish to seek forward you’ll send the following JavaScript command:

player.seek(30);

Or, if you wish to load a video:

player.load(x5s90td);

You can find all the commands our player supports here.

The dailymotion Xbox application is built using XAML/C# for all of its views except for the video page where we have a WebView that will render the video. On top of these views we have XAML/C# to handle when the user interacts with the player. For the Android and iOS apps it the same this on each platforms the application are built natively with swift or Koltin/Java and the video view has a webview that loads our player.

What are the limits: offline

The only limit that I’ve found so far, after using a WebView for the player in the dailymotion application (for over 1 year), is that when the application is in Offline mode (no internet connection), the HTML5 player doesn’t work as one would expect…

This means that when you’re in Offline mode on the iOS, Android, and Windows platforms you won’t have the HTML 5 player but a custom native player which isn’t great. We’re currently exploring whether we could cache the HTML 5 player on Windows devices to try and fix this issue.

Final thought: My Opinion

At first, I was completely against having a WebView that would render the player. A WebView is going to consume more battery, more CPU and more memory, right?

Of course. It will however, also offer you the benefit of having one player shared across all platforms which means that all of the technology we put in our player (video streaming, skinning the UI, ads, tracking) won’t have to be re-implemented over and over again. And here comes the resources issue, even if you have a crazy amount of resources, this still means that you’ll need development resources to re-implement the player on each platform. In addition, you’ll also need the Design/UX Team to verify that the UI on each platform is correct, and once the Design Team has given their ok, the Quality Assurance Team will also need to check that the player is working as expected on each platform and test the different streams (hls, dash, smooth streaming, mp4, etc). Or, you can have a WebView that does all of this for you.

Having seen all the benefits of having an HTML 5 Player, I would choose this solution at the drop of a hat. Not only has this solution given the dailymotion native development teams more time to focus on code quality and application stability, it has also brought a certain peace of mind on player implementation and performance. Dailymotion being a video streaming platform, this is a huge win for us.

For me, this has allowed to stop worrying about the video stream and to focus more on the architecture of the application, which has allowed me to deliver dailymotion on Windows and Xbox very quickly.

Thanks for reading,