Socks, Dregs and Bacon Roll

Safely reusing Singleton classes in multi-instance apps

Wisdom seems to have it that in general Singletons are mostly bad. The actual usecase where you need “one and only one” instance in an application are few are far between. The web is awash with opinion about the pros and cons of using Signletons, that is not my aim here.

This post is aimed at anyone who has built up a library of code over a number of projects and have some useful logic wrapped up in Sinlgeton classes which are being used as the only instance in those apps.

I have a particular Singleton that I have used in quite a few apps and its always been the case that one instance per app is exactly what I needed. In a new project I’m working on I released that I’d like to use the class, but I have clear divisions in my app that would logically take one instance of their own of the class curretly wrapped by the Singleton pattern.

My options here were:

• Option A: Rewrite the class as a non-Singleton and face having to refactor my other applications to work with the new way when I come to make a new release.
• Option B: Duplicate the logic into another non-Singleton class so I dont break the compiles of my other apps.
• Option C: None of the above.

Option A is a pain but at least I could address compile issues on a per case basis when I make new builds, though it will be a somewhat tedious process, and in some cases I actually really do want “one and only one” so the Singleton really makes sense. Option B, would grate… seriously, I would continue to feel sullied until the situation was rectified

So onto Option C. A very simple idea occured to me. What if my Singleton’s default behaviour was to return the one and only instance, but the class could be updated to generate more than one named instance if required. This way all my old apps would go on using the Singleton instance and my new app could instantiate the multiple named instances required without breaking things or duplicating code.

Heres an example:

As you can see the default behaviour of the getInstance() method is to return the Singleton instance, but now the class will also maintain a hash map of other named instances requested via the optional identifier parameter. The class now become something of a self instantiating Factory, but still encapsulates access to the instances.

Flash Player 10.1 will kill HTML5

I’ve never made a habbit of link blogging (ie just posting links to other blogs without making any sort of intellegent comment), but this one is too important to be missed and speaks well enough for itself.

Fabio ftw.

SystemClockChangeWatcher

When dealing with time sensitive applications (pretty much anything that needs to compare local times and/or remote server time) changes in the system clock can at best make for a bad user experience and at worst provide a means of circumventing critical business logic.

Consider the situation where a user or system event is scheduled for a particular date/time. The most common implementation would be to calculate the time in milliseconds between now and the scheduled event and start a timeout with a delay equal to that time.

The problem with this approach is that in the conversion from the specific date to a length in milliseconds we lose information about the actual date requested. This means that changes to system clock (event legitimate ones such as daylight savings) will mean the previously calculated time is now invalid. For example: Its 2PM and we schedule an event for 4:30PM, we calculate the time between now and then to be 2.5 hours (9000000ms), at some point the system clock changes back 30 minutes. This means that the scheduled event will now occur (according to the new time) 30 minutes too late (note: this example assumes that its important to make things happen at the apparent local time).

A different implementation would be to have a timer which, upon each tick, evaluates whether the scheduled time has arrived. This works fine for a single event, but becomes very wasteful with many events and perhaps your application needs to know about changes to the system clock even when you don’t have a time based event scheduled.

Step up the SystemClockChangeWatcher. I’m not touting this a fix-all for the use cases discussed above, the logic the class encapsulates would be better implemented as a part of a wider scheduling system. Encapsulated as below you lose the ability to manage the Timer instance with your other scheduling Timers. However, as a functioning example of how to solve the problem it works well and would fit nicely into applications with few other Timers.

Here it is:

Forgive me Father…

Its been 6 months… make that 7 months since my last blog post. Its not like I’m a prolific blogger at the best of times, but I set out to come up with at least one interesting post a month. So much for that. I still have a fire burning in my belly for the Flash Platform though so thats not what is stopping me…

Other than being generally busy at work, the arrival of my second son Isaac in October pretty much reduced “me time” to zero. Not that I’m complaining… ok well maybe I am complaining a little bit, but its still amazing having my two little coders in waiting!

Anyway, the great news (for me) is that Liam my boss persuaded me (didn’t take much persuading) to take a couple of weeks off, so here I am finding the time to blog…

GOD I’M BORED!

I’m beginning to find the prospect of “time off” a little daunting when I think about all the personal projects and tinkerings that have been clammering for attention and getting none. Watch this space, you never know I might do some coding

Now for the obligatory “Flash v The rest of the World bit”:

I feel the need to say my piece, given the buzz about the future of all things webby at the moment. I’ve been decent enough to hide my opinion behind a not related sounding post title so hopefully I wont contribute to the flame wars.

The only thing I’ll say is this (and you can read into this what you like): In my work for the BBC I get to talk / work with some key players of the Flash Platform at Adobe and there is nothing but hard work being put in and great things to come. Competition is truly a great thing.

Adobe AIR is dead… long live Adobe AIR.

I’ve read a couple of posts today about Adobe AIR suggesting that the honeymoon period for Adobe AIR is over. Sarah Perez Over at ReadWriteWeb asks “Are you over AIR Applications?” citing AIR apps like TweetDeck, Seesmic and DeskTube as apps that have no good reason to be desktop apps saying “there’s no reason why these apps couldn’t just run in a browser instead”. Im not going to jump to the defence of AIR here, she’s right.

But what did people think? You have a couple of million web developers who all of a sudden can start installing their webservice consuming widgets and maybe use the file system. It was a revolution, but I agree that its over now. However, contrary to Sarah’s opinion I dont think AIR is no more. This first rush of fancy widgets was bound to happen and to be honest was never really about the users it was about the developers!

What AIR is about is desktop applications, it is not about website widgets that you can install. Adobe Platform Evangelist Ryan Stewart has made a valiant effort at defending his companies interests, but the two main points he uses are the same ones we were hearing when Adobe AIR was being marketed: “Web developers can leverage their skills” and “hey you can get at the file system” (not direct quotes).

Fear not the Ryan, Adobe AIR isn’t over, its maturing. These typical “selling points” of AIR seem more targetted at developers still. I think the massive avalanche of apps made by hobbyist developers has proven that you’ve won that battle now Adobe.

AIR is about rapidly making grown up, feature rich, engaging desktop applications. Being web aware shouldnt be “THE” selling point, its only a strength. The marketing effort should now be focused on the people with the money who can hire those hobbyist developers to make the next generation of desktop experiences.

I’m lucky enough to be involved in the making of an AIR app that strikes a good balance between web and offline. The BBC iPlayer desktop is all about the offline experience. Naturally, you need a network connection to download the content – and the website is all about discovering new content. The two sit next to each other neither trying to do the job the other is so great at doing (and its set to get better still in the future – sorry no spoilers would be more than my job is worth!).

There will always be developers who jump from one “next big thing” to next and inevitably there will be some good work done and happy users to boot. Its whether the move is made from developer novelty toy to serious commercial contender that will be key for Adobe AIR – there are plenty of signs that this is happening and lots more potential for growth, but whether Adobe AIR can shake off any negative connotations and go from strength to strength remains to be seen.

SyntAction Update – Viral ActionScript

Last weekend I blogged about the widget I’ve named SyntAction. I’ve made an addition and a couple minor improvements.

The main thing I’ve added is a footer which has two links. One just shows the latest version and links page to the SyntAction page. The other one copies the embed code used to display the code and colour highlighting onto the clipboard ready for embeding on your blog. This could be useful when commenting on code someone else has blogged about – just copy and embed their code from its location and blog away and help make someones ActionScript become viral!

To demonstrate the new features I’ve embeded the TextLink class I created for the footer buttons.

TextLink.as (as used in SyntAction)