Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Tuesday 6 November 2012

Combining Different Versions of Dojo

During a project I've been working on for the past couple of months my office mate and I needed to work out how to combine a recent version of Dojo and use it on a page where an old version of Dojo was already present.  Our reasons were simple, we were writing a Dojo Mobile app and hence required the use of a new version of Dojo.  However, we were displaying content within our app from a product that embeds an older version of Dojo.

With not much in the way of documentation on how to do this available, I asked our local Dojo guru for some advice and he pointed me towards the "noGlobals" option in dojoConfig.  This is the key to getting things working as it stops the new version of Dojo from writing to the global name space i.e. when you include the old version of Dojo it sets up a global variable called "dojo" if you simply include the new version of Dojo it will also write to the "dojo" global variable.  That means which ever version of Dojo you include last will always be the one you're using when you reference the "dojo" variable.  With the "noGlboals" option in place (which is adhered to by Dojo 1.7 and above I believe) you can continue to use old versions of Dojo from the global name space in conjunction with locally scoped newer versions of Dojo.

It appears there's still not a great deal of examples out there on how to do this so this is my attempt to put together a simple example to show how it's done by combining the ancient Dojo 1.3.3 with the latest at the time of writing Dojo 1.8.1:

<html>
<head>
<title>Dojo Mix-Up</title>

<!-- 
  lets start by including a really old version of Dojo 
-->
<script type="text/javascript" 
  data-dojo-config="isDebug: false, parseOnLoad: false" 
  src="dojo-release-1.3.3/dojo/dojo.js">
</script>

<!-- 
  configure Dojo to load without trampling the global namespace
-->
<script language="JavaScript" type="text/javascript">
  var dojoConfig = {
    noGlobals : true,
  };
</script>

<!-- 
  load the latest version of dojo
-->
<script type="text/javascript" 
  data-dojo-config="isDebug: false, parseOnLoad: false"
  src="dojo-release-1.8.1/dojo/dojo.js">
</script>

</head>

<body>

<!--
  Shove in a couple of divs to write to
-->
<div id="oldDojo"></div>
<div id="newDojo"></div>

<script type="text/javascript">
  // output our global namespace Dojo version (1.3.3)
  dojo.byId("oldDojo").innerHTML = dojo.version;
  
  // output our new Dojo version (1.8.1)
  require(["dojo/dom", "dojo"], function(dom,dojo){
    dom.byId("newDojo").innerHTML = dojo.version;
  });
</script>

</body>
</html>

Friday 11 February 2011

Building Native-like Web Apps for Mobile

Sencha Touch
I spent a few months at the back end of last year working on a project to bring company information down to mobile devices within that company.  I took the decision early on in the project to implement the solution using a web browser to host the application and a Javascript tool kit to fake the look and feel of a native application inside the web browser.  It's this technique and tool kit that I want to focus on here.

The first key decision in a project such as this is whether to go with a native application or an app delivered through the browser.  Since in this particular case the people I was writing for all used iPhones, perhaps the natural choice would have been to write a native iPhone application.  They could, however, just as easily have been using Android or a whole host of other devices.  The real benefit of the native application (aside from speed perhaps) is the ability to interact with the hardware on the device your application will be running on.  Since I did not require access to a camera, GPS, accelerometers or any other phone features, delivery through a web browser was a very realistic option.  In giving up the ability to access these hardware features you gain the ability (if done carefully) to write-once run-anywhere.  That is, the application I came up with would be able to run on an iPhone and Android or pretty much any device with a web-kit based browser and a decent touch screen interface, but at the cost of not being able to use, for example, a bar code scanner.

There are probably others but to the best of my knowledge there are currently three Javascript toolkits positioning themselves for the mobile space.  Dojo MobileJQuery Mobile and Sencha Touch.  Did I just say positioning for mobile space?  Lucky you, if you're playing buzzword bingo, sorry!  At the time of creation, Dojo and JQuery weren't options, they are both only now ramping up development in this area and in the case of JQuery releasing early alpha drops.  Sencha Touch was much more advanced and already at a 0.90 beta when I first started playing with it.  I followed it through the beta development cycle over the summer months in 2010.  Fortunately, it seemed the timing of the production release of Sencha Touch was likely to be at the same time the first phase of my customer work went live so it became the obvious choice.

As a bit of background (and again this is my understanding so may not be absolutely accurate) Sencha was formed by the merger of JQ Touch and the EXT JS toolkit when the original author of JQ Touch, David Kaneda, joined forces with EXT development.  Essentially, Sencha Touch is the next generation version of JQ Touch but now has a small army of developers, a community, and a company behind it to provide a support network.

I quite like the approach of delivery mobile apps through the web browser, where it's appropriate to do so of course.  I've already discussed that in my view you can develop a web app in the browser if you don't need access to the device hardware.  If you don't require that sort of access, it's hard to see why you'd want to develop any other way.  As an Android user, I often get frustrated when apps (pointless or otherwise) are released only for the iPhone simply because that's what an iPhone user expects.  One example I had recently was while reading through my subscription of BBC Good Food magazine who seem to provide only an iPhone or iPad application.  In fact if you go to their web site they also provide a Chrome app and a Samsung Wave app, why I wonder?  The magazine simply displays content with little or no interaction from the user, sure the online versions contain video and other features you can't put down on paper but there's nothing there to suggest the maintenance of a myriad of different apps for different mobile platforms is worthwhile.  Not to mention my surprise that an organisation such as the beeb are carving up their community by device type rather than, as we'd expect, supporting the masses as we saw with iPlayer coming to Mac and Linux after their early Windows only versions.  Surely, a javascript toolkit approach here would be better?

In the early days of my playing around with the Sencha Touch beta code I wrote a mobile version of a badminton web site I maintain.  It's not particularly advanced and certainly not representative of all the things you can do with a toolkit like this but thought I'd put it out there anyway.  It should, at the time of writing work with iPhone, iPad, Android and Blackberry devices and quite probably with others too.  If you're trying on your desktop then make sure you're using a WebKit based browser such as Google Chrome or Safari, or for something a little bit different the great little browser Midori.  For a better selection of demos take a look at the Sencha Touch Demo page and for a developer perspective on the widgets and options available in the toolkit have a look at their Kitchen Sink demo which gives a simple overview of many of the components.