RIA’s revolution and Mobile Devices (Rant)

There’s been an explosion of the web and cloud related development tools and services such as Web 2.0, RIA’s, Silverlight, multiple cloud services, AZURE etc… Big companies (including Microsoft) have been pushing to move away from fat clients to a thinner clients consisting mostly of the browser. This is all great and understandable however looking at all these developments from the point of utilizing all this power on the Mobile Devices, there are all lacking acknowledgement of a few important issues.  The first one is the device connectivity.  The reality is that DEVICES ARE NOT ALWAYS CONNECTED… period. So if you are running this fabulous AJAX and JSON (or Silverlight) enabled application in the browser, as soon as the device goes in the area with no wireless reception (travelling, blind spots, subway, basement, elevator, hiking, etc…) your application becomes un-useful unless… there’s an ABILITY TO CACHE THE DATA ON THE DEVICE. This is in most cases restricted by the browser sandbox.

Oh wait there more… What if you would want to detect the connectivity or make use of all these magnificent peripheral devices (Bluetooth, GSP, orientation sensor, etc…) that are becoming a part of most of the smart mobile gadgets these days? Nope. You can’t do it either. The point of this rant is that in the middle of the noise and the hype of the advancing technology; let’s not forget about may be more complex but important solutions that have been proven to work for many years in the past – Rich Client applications that allow full access to the local resources with a combination of data syncing and caching technologies. The user experience matter. If the application becomes unresponsive just because I am in the elevator, it’s a bad user experience. If the application displays “Page not found” error while in the middle of retrieving customer data, it’s a bad user experience. So let’s be realistic.

Comments (3)
  1. jhardman says:

    I hope you have not discovered something about Windows Mobile 7 using Silverlight and that it must be a web app.  If that is the case then I would not be able to use it in my development and can see that we would probably change to a different platform.  My boss has already hinted at keeping an eye on the iPhone.  

    I am hoping that it would be like WPF in that it is a rich client app.  I need to be able to grab data and go without always being connected.  Most of our clients do not have devices with the phone and hence rely on WiFi or ActiveSync for connectivity.  As you can imagine there would be large periods of time where they are not connected.

  2. I think the iPhone app store and what it has done to the mobile application landscape demonstrates that regular people prefer rich clients. With Bing for the iPhone and Google’s suite of apps for it I see the big guns acknowledging that fact. Hopefully this lesson will not be forgotten.

    Oh, and incidentally, what happens when you take a web 2.0 app (like gmail) and give it the ability to put data on the client (gears) so it can run offline. Well now you’ve got a rich client app that was written in javascript (what a nightmare!) and runs in the browser. Right back where we started. Heh!

    "There’s an app for that" is the future (or at least it ought to be) 🙂

  3. Kevin Daly says:

    I think you’re being unfair in the case of Silverlight (while I can only speak about the desktop version, since that’s the only one that exists beyond trials for the favoured): as of version 3 it supports local installation, and it can certainly detect connection status. Silverlight 4 greatly expands what out-of-browser apps can do in terms of interacting with the local system and its resources and facilities. If Windows 7 can include an implementation of Silverlight with those features I really don’t see that it will suffer from the problems you mention (my great fear however is that they’ll take the cop-out route and ditch managed code as they did with the embedded version…that would be the last straw for me).

Comments are closed.

Skip to main content