A good friend of mine suggested to me that I should web-enable my TV guide application, so that it would operate cross-platform.
Seeing as I'm still considering a low cost Linux based PC as a mediacentre, this definitely sparked my interest.
In this blog, I've previously covered my exploits with trying to get the guide to run natively under Mono which would immediately enable it to be run on Linux and the Mac. Although that has potential, my initial work with it has not produced a reliable enough version of my guide which will run on Linux (yet).
Keeping it running on a Windows machine and having it served up to a browser however does initially sound like a great idea. Why bother worrying about getting it to run natively on a non-Windows machine?
The issue with this is that providing the same level of graphical appearance and interaction is not straightforward using HTML and JavaScript. Google have got it down, with their Calendar, Mail, Word Processor and Spreadsheet applications, but they have a few more developers available to them than I do ;-)
Generally, my experience of JavaScript and the associated web development has been painful - browser wars aside - I feel JavaScript is a poor competitor to languages such as Java and C#. I'm not saying it can't be done in JavaScript with enough effort, but in comparison with how quickly I can put together an application in other languages, I find JavaScript too big a hill to climb.
That's not to say that a lot of what the TV Guide provides cannot be web-enabled. Setting up recording rules and searching for programmes etc can easily fit into a less graphical interface. I'm an experienced ASP.NET developer, and there's no issue with me writing that functionality on top of my existing core guide functionality.
The key area however which requires the interaction is the main guide display..
Alternatives to JavaScript
Seeing as I am a software developer by profession, and have invested much time in the Microsoft camp, the recent announcement of Silverlight has me very interested. Silverlight is Microsoft's answer to Flash, which some are reporting has the potential to be a flash killer. That remains to be seen however (it's very early days), and Adobe are bound to have something to say about it.
In its present incarnation (1.0), Silverlight provides mainly flash-like capabilities such as animation and video playback. Programmatically, Silverlight currently uses JavaScript which is not ideal for me for the reasons above. In Silverlight's next incarnation (1.1) however it will bring .NET language support (VB and C#). That will be a real change of direction for Microsoft, as they have already produced the Silverlight plugin for the Mac and are working with Novell and the Mono project for the Linux version. Scott Guthrie (the General Manager of the .NET development teams at Microsoft) recently confirmed this partnership.
I'm hoping that Silverlight 1.1 will allow me to produce cross-platform, flash-like quality graphics and interaction using C# which will require minimal changes to my existing C# code base. 1.1 is due out early 2008, but I will probably play around with the beta before then, which is out now.
In the meantime, I'm left with just one cross-platform contender - Java.
Java and .NET interaction
I have always tried to keep the span of technology for my guide to the minimum. It's harder to maintain multiple code streams in multiple language technologies, so what has changed my mind? Simply that I can produce a Java applet that displays the graphical portion of my TV guide in only a few days. Behind the scenes, the data is still provided by my .NET server code base, and made available to the applet via a .NET XML web service. I've already written much of that connectivity code in a past project, so grabbing it for this makes that part of the project much quicker.
The remainder of the Java code is regarding the drawing of the guide, the display of programme details on double-click, and the ability to set recordings. Beyond that, as I see it, the rest can be implemented using traditional ASP.NET web pages rather than in Java - keeping my cross-language code to a minimum. Hopefully to the web user this will be transparent, as the applet will itself just be embedded in one of the web pages.
I've started this Java project as an exercise, and already have the guide displaying with my required interactivity inside a web page. I have yet to try it on other platforms, but as long as Java can be installed on the Mac or Linux, it should work without issue. The benefit of that cross-platform ability vs the cost of maintaining two sets of code in my mind is not an issue as the majority of the code is still behind the server, and not in the applet.
I'll post more about this project as I finish parts of it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment