10 hours = desktop and mobile app for YouTube remote controller (hackathon)

The stack:

  • Angular JS
  • SignalR
  • MVC 5
  • VS 2013
  • MongoDB
  • Zurb Foundation 5.0
  • Android Client

The Mission:

  • Create a remote you tube player (android device like TV, tablet)that is controlled from a web site


  • 1 day (10 hours)
  • 2 teams: .NET (my team) and Android


Nugget the good parts

Since we already had a fair experience with SignalR, Mongo and of course MVC the wiring was pretty easy. Installing nugget packages for signalR, Mongo and Unity gave us a quick head start setting a repository pattern for mongo and simple hub for signalR

Nugget the bad parts

Too many flavors for each package: Finding the right packages is hell and feels like sending your hand to find a Coca-Cola bottle inside a bucket full of beers. Many packages have 3-5 (in a good day) flavors, and cause much confusion and web-searching… it seems like that most of the vendors has more than one flavor for the same package. This is just wrong; instead of a simple description and single packages the confusion is vast. In most cases you find yourself creating a side projects just to see what the packages gives you and what the difference from other flavors is. For instance “Unity boostrapper for ASP.NET Web API” and “Unity boostrapper for ASP.NET MVC” – now, what if you are using both in your MVC project – this is just wrong.

No option to set package location: there is no option to set where each package files should be installed, it just sets the files where ever the package creator thought they should be – again, this is just wrong since there is a very simple solution for this.

Angular JS the good parts

Organizing the project: Getting started with angular was quite easy, all though you need to read at least the entire tutorial before you can get started with it. I liked that it organizes your project pretty good and does not leave you room to think how and where to place every file.

You can chose from feature base to component base organization, and since I’m coming from the WPF world – feature base it is.

Scopes: scopes are pretty cool, since they act as your view mode. Although angular is more of an MVC and lacks the good parts of a true mvvm FW, it’s still pretty easy to get along.

Angular JS the bad parts

Bindings: I wish angular was more like knockout, but I get it the google guys wanted to keep their fields clean without having to declare each field as observable and turning them into functions. Still the binding and the digest model can become very heavy, and the need for $apply is just cumbersome. Especially when working with YouTube API (or any external PAI for that matter) you get to call $apply a lot, and that’s just wrong (againJ)

Service, Factory, and Provider: the difference between provider and factory is pretty clear. The difference between factory and service is not clear at all. If one of Tikal’s gurus wouldn’t explain that services provide a contractor and factory just return a singleton instance I wouldn’t have understand it till today. Still it’s not that clear to me.

Moreover I think that the naming (service, provider, factory) are much the same in the plane kind of way that most programmers get them. Really: what is the difference between a provider and a service? Doesn’t a service provide data?

Zurb Foundation the good parts

Mobile first: although bootstrap 3 is mobile first by nature it seems to me that bootstrap is not 100% that way and I’m still not sure the EM vs Pixels are well implemented. It was very easy to get started and the documentation is a breeze

Zurb Foundation the bad parts

Templates: there are no templates for foundation, not even close to what bootstrap has to offer

Android Clients integration

Now, this is the interesting part. I thought it’s going to be real hard to do the integration but it was rather simple. The android app implemented a native player since playing using HTML5 and the browsers is not that recommended. Even google pass you to the YouTube app from the browser when you want to play a movie.

So the deal was to build a hybrid app, one that displays a native player surrounded with HTML content. This seems like a good future for the app development echo system. Where you can focus on HTML for compatibility between OS’s and leaves the hard parts for the native OS to do.

The basic idea was that the app will consume a SignalR service and implement the SignalR proxy for every method. We wasn’t sure that the android app can implement JS method at runtime and we finally came up with a different approach:

   1:  ytRemotePlayerApp.controller('PlayerCtrl', ['$scope', '$http', '$rootScope', 'remotePlayerService',
   2:    function ($scope, $http, $rootScope, remotePlayerService) {
   4:        var client = remotePlayerService.getClientProxy();
   5:        var playingVideoId;
   7:        client.receivePlayCommand = function (videoId) {
   8:            console.log('receivePlayCommand ' + videoId);
  10:            if (window.JBridge) {
  11:                if (videoId == playingVideoId) {
  12:                    window.JBridge.play();
  13:                } else {
  14:                    playingVideoId = videoId;
  15:                    window.JBridge.start(videoId);
  16:                }
  17:            }
  18:        };
  20:        client.receivePauseCommand = function (videoId) {
  21:            console.log('receivePauseCommand ' + videoId);
  23:            if (window.JBridge) {
  24:                window.JBridge.pause();
  25:            }
  26:        };
  28:    }]);

Notice that we look for the window.JBridge which is pushed to the page by the android app. So the desktop version is not prone to errors and once the bridge is alive we can call methods that where implemented on via the bridge.

So combining SignalR and android was easy. See the repo for more details – the master mind behind this is Michael who came up with this setup.




Thank you for your interest!

We will contact you as soon as possible.

Want to Know More?

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com
Thank you for your interest!

We will contact you as soon as possible.

Let's talk

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com