We designed and developed an application for Xbox 360. Recently, we were asked to build the Amazon Fire TV version of the same application.
The Amazon Fire TV Device
Amazon Fire TV is a newcomer in the world of what is often called the “10 foot experience,” i.e. applications running on a large screen (typically a TV). It is actuated from a distance of approximately 10 feet using alternative input devices such as a game controller, a TV remote, a Kinect sensor, etc.
The Amazon Fire TV device is a small box (115 mm x 115 mm x 17.5 mm), with a few essential ports: Power, HDMI out (including audio), optical audio, Ethernet and USB. Additionally, it can be connected to a WiFi network. Out of the box, the device supports H.263, H.264, MPEG4-SP, VC1 video, and AAC, AC-3, E-AC-3, HE-A, PCM, MP3 audio. It can also display pictures in JPG and PNG format. It outputs video in 720p and 1080p (full HD). The device is available on Amazon for $99. Typically, it is used with an Amazon Prime subscription.
In addition to streaming videos and music from the Amazon Prime service, the device can also run applications downloaded from the app store. The downloaded applications do not require an Amazon Prime subscription. The device runs Android (currently V4.2.2) with the addition of an Amazon SDK whose main focus is to support the Fire TV game controller and to integrate into the Amazon notification system.
Because it is an Android device, the developer of an application for the Amazon Fire TV device can of course choose the standard Android development environment and write applications in Java. Very fast however, we decided to give Xamarin Android a try on a “real life” project. One of the specific advantages was that we could reuse part of the Xbox 360 application’s code.
Because of differences in the Xbox 360 architecture (such as the lack of async/await in Xbox 360) and the way that the UI operates, we decided to develop a new application and cherry pick the relevant model code from the Xbox app. This allowed us to reuse the code connecting to the video catalog service, the code that prepared the URI for the streaming videos, as well as most of the code used to display ads in the application. Thanks to this “quickstart,” we were able to get the catalog of video streams to be shown on the application’s main page on the first day, and then worked on playing the video’s HLS stream, which was very easy thanks to the native Android video player (wrapped into Xamarin’s VideoView element).
Thanks to the choice of Xamarin, the great tools available (such as on-device debugging from Visual Studio, simulator, visual designer), the usage of familiar architecture and programming concepts such as the Model View ViewModel (MVVM) pattern and the MVVM Light Toolkit, we were able to get first results within a couple of days, have a beta version after two weeks, and a first production release (for certification to the Amazon store) within 4 weeks including intensive QA testing.
Note: HLS (HTTP Live Streaming) is a popular standard for video streaming created by Apple. It is interesting to note the difference in HLS support between Android and Windows systems. On Windows, HLS is not supported natively and we had to invest many resources into making the HLS stream play correctly without memory leaks when switching streams (for example, to display ads). On Android however, HLS is supported natively. Because the ads on the application are in MP4 format, we had to switch during runtime between adaptive streams (HLS) and progressive download (MP4) which the Android video player in the Fire TV device managed seamlessly.
Architecture and implementation
We built this application using the MVVM Light Toolkit which was recently made available for Xamarin. Most of the MVVM Light components are used by the application, including the new data binding framework that is now a part of the toolkit.
Navigation and usability with the remote control
The Amazon Fire TV can be used with a remote control (included in the delivery) or with a game controller (to be purchased separately). Both devices have a dedicated back button which made it unnecessary to add a UI element to go back to the previous page.
In the software, the navigation is performed by the system’s navigation service, which is abstracted, as usual in the MVVM architecture, by an INavigationService that can be shared between the various platforms that C# supports. This will prove useful when porting the application to different platforms such as Windows 8 and Windows Phone for instance.
In addition to the SimpleIoc IOC container provided by the MVVM Light Toolkit, this kind of service abstraction is very convenient and easy to use, and easy to adapt on various platforms.
Consequences of using MVVM and Xamarin
Thanks to the MVVM architecture, the usage of the MVVM Light Toolkit and Xamarin, we think that porting the client’s application to Windows Store and Windows Phone will be a very short operation. Additionally, we believe we can cover more platforms in a limited time, as long as we are able to use C# (and possibly XAML). In fact, even an iOS application would be relatively easy to build, thanks to the reuse of the Model and ViewModel layers in the Xamarin iOS version. Creating a new UI would be the biggest effort and would allow us to concentrate our design expertise on providing an excellent experience to the user of each platform without compromises.
The user interface
Thanks to IdentityMine’s extensive experience with “10 foot devices” such as the Xbox 360 and Xbox One devices, creating a compelling and easy-to-use experience for the Amazon Fire TV device was seamless. It was simply a matter of adapting the existing Xbox 360 design to the particular Fire TV device, complying with the Amazon design guidelines and making sure that we are offering the best possible experience for users of Amazon Fire TV.
The Amazon design guidelines are not very extensive and as an effect they give quite a lot of freedom to the designers. Nonetheless, we studied multiple existing Amazon Fire TV applications and offer a familiar experience to existing users.
What about the learning curve?
Thanks to the use of C# and of the familiar tools, getting them up to speed was very easy. Once the development environment was installed and a quick “hello world” application was running, we concentrated our efforts on two activities:
- Integrating the code from the Xbox 360 and making sure that everything was working fine. This was standard C# code and the learning curve here was nonexistent.
- Building the user interface. This was new for the team but is was close enough from XAML (Android uses XML as the markup language for the UI) that getting our integrators up to speed was in fact surprisingly easy. Using the Xamarin Studio visual designer allowed us to work in relative comfort and to make great progress fast.
All in all –considering that we started with one semi-experienced developer and two “newbies,” we were able to complete the full application (including QA) in four weeks. I would say that the learning curve for experienced XAML/C# developers is very low.
The client’s application was our first production Xamarin project and we were positively surprised at how fast we were able to create a production-grade application corresponding to the very high standards that we at IdentityMine set to ourselves on every project. Having a team of C# experts made the learning curve very low and we managed to become confident with the code and to provide a user experience without compromises. At the same time, we were able to leverage a large portion of existing code from the Xbox 360 version of the application.
In retrospect I can say that this project went just great. We are already looking forward to more Xamarin and especially Fire TV projects!