ActionScript 3.0 Design Patterns

Face the Facts: We've got to deal with Mobile

At this point in time I can easily create a script to determine whether a browser is mobile or non-mobile. I want to get to the point where I can put together a Chain of Responsibility pattern so that I have a flexible design for tweaking a specific kind of mobile device (e.g., calling up appropriate CSS). This requires OOP JavaScript, and so I had to revisit my old JavaScript work. One of the best books on both OOP and JavaScript is Javascript Objects: Object Use and Data Manipulation with JavaScript by Alenander Nakhimovsky and Tom Myers published by Wrox in 1998. It was written by a couple of professors at Colgate University and is pitched at a pretty high level that most readers of this blog will appreciate. (You can still get it from Amazon, and it’s a gem to have no matter what language you favor.) Another good book that deals with JavaScript objects is Douglas Crockford’s JavaScript: The Good Parts (O’Reilly, 2008). Crockford understands JavaScript down to the metal and has great explanations and examples.

So the question is:

Can JavaScript handle OOP and Design Patterns?

To find out, I started writing some prototype classes but found I’d have to spend some more time trying to cobble something together that was both reasonable (it maintains the DP value of flexibility, update and reuse) and real (I didn’t want to make a phony DP with hack classes.) However, it didn’t take long to put together a little code that works to filter out both different mobile devices and non-mobile devices. My plan is to take this code and change it so that I can do the same thing with a Chain of Responsibility design pattern. Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

// JavaScript Document
var sniffer=new Object();
var agentNow=navigator.userAgent.toLowerCase();
sniffer.android=(agentNow.search("android")>=0);
sniffer.series60=(agentNow.search("series60")>=0);
sniffer.iphone=(agentNow.search("iphone")>=0);
sniffer.blackberry=(agentNow.search("blackberry")>=0);
sniffer.windowsce=(agentNow.search("windows ce")>=0);
var counter=0;
var flag=new Object();
flag.nonMobile=true;
for(var mobile in sniffer)
{
	if(sniffer[mobile])
	{
		switch(counter) {
		case 0:
		document.write("android<br/>");
		flag.nonMobile=false;
		break;
		case 1:
		document.write("series60<br/>");
		flag.nonMobile=false;
		break;
		case 2:
		document.write("iphone<br/>");
		flag.nonMobile=false;
		break;
		case 3:
		document.write("blackberry<br/>");
		flag.nonMobile=false;
		break;
		case 4:
		document.write("windows ce<br/>");
		flag.nonMobile=false;
		break;
		}
	}
	counter++;
}
if(flag.nonMobile)
{
		document.write("Non-mobile or unrecognized device.");
		document.write("<br/>");
}

Before you say anything (or think anything), I realize that this code is about as flexible as a rebar (AKA: reinforcing bar), and if you’re into JavaScript, you can think of 10 ways that this can be done better. However, the goal is to see if this can be refactored into a design pattern. Here’s my plan:

1. Set up a dummy Chain of Responsibility that links the different kinds of responsibilities.
2. Have each responsibility be actions taken for different kinds of mobile devices or a desktop.
3. Use JavaScript objects to do the work of the concrete handlers

However, before I get started on this project, I’d really like to hear from you and even better, see what you can do with this challenge. So between now and the next post on this topic, let’s hear from you! Also feel free to add different kinds of mobile devices such as tablets and other phone OSs.

If you think everyone is heading for HTML5 now, you're nuts!

According to The Economist (Oct 8-14, 2011), in 1993 there were 100 million PCs. By 2008, PCs had topped 1 billion. Many of us tapped into that market one way or another, and some of us came out well rewarded—Adobe certainly did. By 2020 (barely 8 years from now), they expect 10 billion mobile connected devices. In looking at the number consider this: The current #1 Free App on iOS devices is called ‘Hair Plucker’ and who knows how many people bought ‘Angry Birds’, 2010′s top paid for app? Among other apps I saw was a ‘Halloween Mouth’ selling for 99¢–it’s a picture of a mouth you hold up to your face. (How long would that take to create?) Another popular app is not one, but several, that make farting sounds–with prices ranging from free to $1.99.

Latest Update on Flex’s Fate!: Because so many questions about Flex were asked (e.g. Is this the end of Flex?) Adobe posed the following:

Adobe settles concerns about Flex and Flash.

Now let’s say, that you create a simple app using a Factory Method. You’ve got 10 billion units out there. We’ll say that you have a ‘Sneezing App’ that makes different sneezing sounds, and it sells for 99¢. If just 1% of 1% of 1% of 1% of 1% of 1% bought your app, that’s $10,000–a half million Indian rupees. If 1 person in 10,000 bought that app, you’d be a millionaire. (The good thing about language-independent apps like the ‘Halloween Mouth’ and ‘Fart Factory’ is that they are language independent.)

20 Billion Mobile Connected Devices Can’t Be Wrong!

I have no idea how many people will be using PCs as we know them. Maybe they’ll go the way of the 5 1/4 inch floppy and all we’ll have is some kind of tablet that we can connect up to the Internet. Development may be done with apps that we rent from a cloud. What is important and key now and later are mobile devices. At this point in time very few Web developers are actively developing apps for mobile devices, and tools like AIR for iOS, Android and Blackberry provide us with a key opportunity.

So, you can be certain that Adobe did not bow out of the Flash-Player-in-the-Mobile-Browser market because they thought it was not going to be a huge market. Look for Dreamweaver to be optimized for HTML5 and some HTML5 development tools. The development tool from Adobe for mobile, though, will be Flash Builder and Flash Pro working with AIR.

A Browser/AIR Mobile Strategy

Keeping in mind that I have nothing against HTML5 and it’s ability to do many things Flash has done for years—Canvas features some great elements and attributes—let’s look at a new strategy for development in Flash (including AS3 and the different flavors of AIR).

First off, if you’ve done much with with mobile browsers, you must have learned they have little to offer, and they are a mixed bag of HTML5 implementation. (The non-mobile browsers are an equal mixed bag as far as having implemented HTML5.) It’s only the mobile browsers that Adobe is no longer supporting. Not too many years ago, there were no mobile browsers; so basically, Adobe is doing what it has always done as far as providing a Flash plugin for the browsers on our computers. It’s just not going to make them for mobile browsers. I developed several apps for iOS, and while most have been simple and small, I was able to use the same programming structures I did for “regular” AS3.

Second, Adobe has been making big strides with Flash Builder and Flash Professional in creating AIR tools for working with mobile devices. This allows us to create ActionScirpt 3.0 apps for mobile devices—forget Web pages. Imagine knocking together an app that does something useful (like calculating the best point in relationship to a parabolic mirror to place a kettle to boil water) that can be used worldwide. Or even a game using some of the little structures we’ve been developing and discussing on this blog that you can sell for 99¢ (or more!). So quit thinking of yourself as just a “Web site developer/designer.” You’re an app developer/designer.

Everyone Runs to HTML5! Not!

Earlier this year I wrote a book (Smashing HTML5) published by Wiley, and one of the chores I encountered was testing the examples against several different browsers, including mobile ones. There was not a lot of compatibility, and most mobile browsers were successful with only a small subset of the HTML5 elements. Over time, let’s hope this improves because if it doesn’t we’ll enter the Second Dark Age of incompatible browsers.

In order to get most of the cooler stuff to work, you need either JavaScript or PHP, and so I included chapters on both. (PHP seems to be more compatible for all browsers than anything else–probably because of the simpler subset of HTML it generates.) I added as much OOP to both as possible, and some of the reviewers didn’t like the fact that it was not more oriented to the DOM or that I didn’t use more procedural examples in the PHP/JavaScript section. What I was trying to do was to write an HTML5 book for 2011 and not 2001, which meant that I used several examples of dealing with a mobile environment. Further, some OOP in JavaScript/PHP is a good thing; so I hope that will move some folks towards structure in both JavaScript and PHP.

However, without Flash in the mix, creating Web apps and pages is frustrating, not because JavaScript and PHP aren’t good programming tools but rather because of browser incompatibility. I’ve got a feeling that to effectively use HTML5 and all of the related CSS3, developers are going to be spending a lot of JavaScript code determining which browser is being used and making the appropriate accommodations. Who wants to sub-code for every possible browser? This includes mobile browsers. My hunch is that they’ll all head for the lowest common denominator, which is probably one of the mobile browsers that is just slightly better than HTML4.

So, I’ve started thinking “Build an App; Not a Web Page.” Let’s hear your thoughts on Adobe’s decisions.