Call Encore now on +44 (0) 1273 722 544 or contact us
Sunday 20th, May 2012

Archive for March, 2009

Shu updater

Posted by Jethro Grassie on March 12, 2009

Our most recent version of Shu allows a standard Adobe AIR application to have the same AIR install experience but with the benefits of extra commands missing from the AIR runtime.

With this new version, one thing we are often asked is:

“Can I update my Shu application like a normal AIR app?”

While the simple answer is “yes”, a little more explanation is needed to implement.

The first thing to note is that any new version of the application needs shipping as a new Shu Packaged application, not just an updated AIR file.

The application output via the Shu Packager is a installer which installs AIR (if not already present) followed by installing the AIR file. It then performs a little magic to enable the extra commands.
If you just delivered the new AIR file, the last bit of magic would not be performed and you would lose all the Shu commands.

The second thing to note is that in your update descriptor XML file, you need to point the <url> element to the Shu output installer, not to the AIR file.

Lastly its important that we prevent the air.update.ApplicationUpdater from actually attempting to install the downloaded update (after all, its expecting an AIR file not our native installer).
Instead, we want to do this bit ourselves, and luckily, because we are a running Shu based AIR application, we can execute the installer using shu.System.execAsync!

So, I have created a little class to deal with this last step.

It can be used as a direct replacement of ApplicationUpdater.
Whilst this class will be included in the next version of Shu, for now, download here.

Shu enhancements and price changes

Posted by Neil Mather on March 4, 2009

Here at Encore, from our experience of commercial software and our use of (and contributions to) open-source, we recognise the importance of a community around a program.

For our latest updates to Shu, released today, we’ve listened to our community and responded.

Many of you have let us know that while you really like Shu and feel it fulfils your application needs, the pricing of Shu has been hard to pass on to
your clients.

As a result, we’ve restructured our prices, and we hope they’re more in line with your needs.  The changes: Shu and Shu SA now cost $185 and Shu SA Lite is a snip at $45.

On top of that, today we also rolled out a very useful update to a couple of our most popular Shu commands — exec and execAsync — to enhance the way they behave when executing GUI vs. non-GUI external applications on Windows.  Our updates let you easily display GUI apps, but without having to worry about the dreaded console window when you do launch a non-GUI utility command.

There’s plenty more updates in the pipeline for Shu.  We love to hear feedback at Encore as to how people are using our software, and their views on how it could be improved, so please keep your comments and suggestions coming to help us know which improvements the community is most interested in.

NSNotificationCenter JavaFX port

Posted by Jethro Grassie on March 3, 2009

Following on from my last post, here I have now added a JavaFX port!

Download the latest zip which has actionscript 3, C/C++ and now also JavaFX version of the super NSNotificationCenter.

A better way

Posted by Jethro Grassie on March 2, 2009

In my previous post, I described how the architectural frameworks that have sprung up for flex/actionscript developers are not the best thing since sliced bread for implementing well designed applications.

They attempt to take the design pattern, MVC, along with some other design patterns and bring them all together into one monolithic architectural framework.

However, you do not need to use these frameworks to program using the MVC pattern or indeed any of the other patterns used in these frameworks.

So for those developers who understand the various design patterns already, and are opting not to use these architectural frameworks, I present something I feel rather useful in terms of actionscript and the MVC pattern inparticular.

As you will already be aware, in the MVC pattern, you ideally want the actors (the Model, the View and the Controller) highly decoupled.
Therefore its common to see the coupling achieved via notifications (the observer pattern AKA publish-subscribe) or some other kind of eventing.
In actionscript 3, its a very common practice to make use of events, as the event model (an implementation of the W3C DOM event model) is built in.
However, the bubbling and capture phases of the event flow only work when the dispatchers are part of the display list. This means events can only flow when the dispatcher is a view element.
Therefore anywhere else, you need to tightly couple to the dispatcher in order to receive events from it. Not ideal.

This brings me onto the Objective-C/C++ NSNotificationCenter found in Apple’s Cocoa API (and of course the GNUstep framework).
This a very elegant, lightweight, fast and easy to use class.
The usage is simple…

  1. Any object which wishes to send a notification, can easily send one via the NSNotificationCenter’s postNotification method (or its variations).
  2. Any object wishing to observe notifications can observe via NSNotificationCenter’s addObserver method.

The most useful part of this is that the observer can choose to listen for specifically named notifications, specific senders of notifications, both by name and sender or listen for *all* notifications regardless of name or sender.
It is up to the developer what level of coupling to use.

Users of the NSNotificationCenter most commonly make you of a static instance retrieved via NSNotificationCenter’s defaultCenter class method, though of course a more compartmented usage can be achieved via instantiating multiple NSNotificationCenter’s. One such usage could be a more modular application whereby a module wishes to have certain module private notifications, yet also publish and subscribe to the rest of the application.

Actual notifications can either be NSNotification instances or instances of sub-classes of NSNotification.
By creating sub-classes, you achieve a stricter interface, though as you see in Cocoa, this is an uncommon practice.

I am sure anyone already familiar with these classes will understand, they can be very useful indeed.
As such, I have ported NSNotificationCenter (and as such also NSNotification), into actionscript 3 (and also into C/C++ while I was at it) for all to use.

Full source code including example/test applications for download here.

Update: Download link now also contains JavaFX version as well.

Like what you see? Then get in touch;
t. +44 (0) 1273 722 544   e. contact us