There is no doubt that web application development has branched onto mobile devices (ipad, iphone, android, blackberry, etc) with a new way of interfacing (touch screens – rollovers are irrelevant!). As a result, many of us are switching our developing minds into this new arena. As an instructor I am constantly making sure that I am teaching relevant material to my students (hence my whole struggle with the flash/javascript), so it was inevitable that I would be picking up a tablet for the first time and seeing what I could do with it. I thought I would share my thoughts.
- I used a Motorola Xoom Tablet running Android 3.0 Honeycomb for my first attempt at tablet development. This is currently one of the fastest/powerful tablets on the market, so I don’t feel like a lot of my issues were due to the hardware.
- I have to admit that I am disappointed with Android. I want to really like this mobile OS, but it feels like it was put together in a hap hazard and sloppy manner. Perhaps Google was in such a rush to get it to the masses that they were forced to cut loads of corners? I don’t have a lot of experience using iOS on the tablet, but I do own an iTouch and from my understanding it is very similar. I can say that I feel like iOS is much superior. This isn’t too surprising as Apple has had a number of more years to polish it, but also, Apple doesn’t generally let stuff out that isn’t perfect (“it just works”). Perhaps it would have been better for Google to adopt this ideology.
- Many of the applications that shipped with Android are riddled with bugs and poorly limited options (email client can only show the last month of emails? That is stupid!). The browser, for instance, doesn’t handle pop ups very well (I can only open the first one), and both Javascript and Flash don’t execute. I did a whole lot of “Is it is doing anything?” after clicking (touching) a link. On top of that, many flash apps out there aren’t designed to handle touch based interactivity and do weird things when you interact with them.
- I had to “force quit” more applications on Android 3 the first day of messing with it than I care to mention :S
- The process of programing an App for the Android OS is fairly straightforward. An API is provided and developers can use their beloved Java.
- Where the issue lies is in the packaging and deploying. It is a painful process involving lots of front end setup and batch file executions. It is not straightforward…it could be easier? I know there are a few tools that will streamline this, but it needs lots of work.
- The Android emulator is so slow it is borderline useless. My test machine is relatively good…and I could not effectively test my apps on it.
Keeping in mind that Android 3.0 is relatively young (it was only released a few months ago), I know that future updates may address some of these bugs and issues. But the consumer base is fickle and this could definitely hurt Google’s presence in the tablet market.
This is what my SWF looked like running in the emulator
This is a quick one to help others avoid hours of useless digging to get this to work. I’ve come across all sorts of documents on this subject, but of course many of them are lacking in detail and direction…so I wrote my own document to help me whenever I need to set this up.
To start you need loads of stuff:
Once you have everything above, follow the long setup instructions below. Hopefully this will get other developers up and running a lot quicker than I did 
ANDROID APP WORKFLOW AND SETUP FOR FLASHDEVELOP >
> follow these steps:
(1) copy the template for android Apps into flashDevelop v3.3 (or greater)
> this template will be used by flashDevelop to setup a project accordingly
> when you go into flashDevelop and create a new project "AIR AS3 Projector for Android" appears as a option
(2) unzip Adobe AIR 2.5 SDK into a common folder
> I usually put it in the tools folder of flashDevelop but it can be put in the Flash Builder SDK folder
(3) install Flex 4.5 SDK into a common folder
> note this will already be installed if system has Flash Builder installed
(4) install Android SDK
(5) there are several tools (exe) throughout these SDKs that may be needed via command line so it is best to add them to the path (via environment variables)
> add path to bin folders of the AIR 2.4 SDK (one to "bin" and another to "lib\android\bin")
Example:
C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;
C:\Program Files (x86)\FlashDevelop\Tools\airsdk\lib\android\bin;
(6) create a new android project in flashDevelop (under projects in menu)
> all android tablet apps should be at a resolution of 1280X800
(7) start the android emulator
> should be android 3.0 - API Level 11 (this is honeycomb, the tablet version of the os)
> add the cache parition size:66MB to the hardware
> add the device RAM size:1000MB to the hardware
> enable the snapshot; this saves the state of the android OS image when you shut down; slow shut down but faster startup
(8) create a self signed certificate
> in order to install an AIR application onto android (or any OS) it must have a self-signed certificate (digital) created
> edit the CreateCertificate.bat file (this batch file creates it)
> change the path to point to the AIR 2.5 SDK bin folder
Example:
set PATH=%PATH%;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;
> this is so the path is set to have access to adt.exe; this creates the Adobe AIR certificate as well as verifies it
later when you go to install the app
> adt.exe documentation: Adobe AIR Documentation on adt.exe
> change the name, password, and filename of the certificate
Example:
set NAME=testy
set PASSWORD=t
set CERTIFICATE=SelfSigned.p12
> run certificate and it should create a p12
> this only has to be done once for each project
> do not rebuild the certificate once you start developing or you will need to clear out the app from the android emulator snapshot
(9) create an APK
> this is the package that all android apps are distributed as
> it is this that will be installed on the android emulator
> edit the APK_PackagerApplication.bat file (this batch file creates it and uploads it to the emulator)
> set the path to AIR SDK binaries (one to "bin" and another to "lib\android\bin")
Example:
set PATH=%PATH%;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\lib\android\bin;
> this is so the batch file has access to the adt.exe and adb.exe tools
> adt.exe is used to verify the AIR app in order to install
> adb.exe installs the AIR app on the android OS
> set path to the Adobe AIR plugin that needs to be installed onto the android device before your app
can run; of course this is an APK and can be found in the AIR SDK folder
Example:
set AIR_INSTALLER=C:\Program Files (x86)\FlashDevelop\Tools\airsdk\runtimes\air\android\emulator\Runtime.apk
> note that I am pointing to the emulator version of the AIR Installer APK
> set the certificate to be the same name as the one you built previous
set CERTIFICATE=SelfSigned.p12
> set the APK to be the name you want it to be:
set APK_FILE=apk/testy.apk
> as long as your emulator is loading from the snapshot, then you only have to install the Adobe AIR plugin once
> therefore you can comment out the following lines by adding "::" in front:
echo.
Example:
:: Install on android device. Comment lines if you don't need.
:: echo the program will install Air runtime on android emulator
:: echo.
:: :: pause
:: echo.
:: adb -e install -r "%AIR_INSTALLER%"
:: echo.
:: if errorlevel 1 goto androidFailed
> after you run this batch file you should see your application in the MyApps section...run as per normal
Troubleshooting
> there are multiple ways that this process can mess up; but I find restarting the emulator helps along with making sure
it is running properly
> you can check to see if the emulator is running right by opening a command window and entering "adb devices"
> if you don't see your emulator in the list of android devices you need to restart the android server
> enter "adb kill-server" to stop the server and "adb start-server" to start again
> restart the emulator after doing this and try to deploy the APK of your app again
> most trouble will occur when using the APK_PackagerApplication.bat
> you will only deploy your app in the emulator at various times during testing; too slow to use for every test of your app
Introduction
It was about fifteen years ago. The internet was still in its awkward early teenage years. HTML was just starting to take form, the silly media still referred to the web as the “Information Super Highway” (duh!), and email really only meant you could contact complete strangers from far away places and ask them stupid questions (I actually had a welsh pen pal for awhile). So why the nostalgia? Because this was when I picked up my first book on Javascript.
It was a visual quickstart book that I had borrowed from one of my professors, however, it is still sitting in my bookcase at home today so I guess I actually stole it. Nonetheless, Javascript introduced me to a world where visual design, information, and interactivity could all be meshed together. I remember thinking that this was so much better than the apps I was building for my computer science courses. There is nothing more dull than building an application that simulates the file system of DOS with ASCII characters on the screen. I was desperate for something more creative. After a quick read I was hooked on Javascript and all the doors it opened in website development. I ended up doing a lot of cool things with it (things JQuery can now do with one line of code) and even made a few bucks on some contracts for the university in the process.
But as it goes in the IT industry, things changed. Flash technology came along and pushed Javascript to the side; and rightfully so. Flash was not only brilliant at web based animation (it was originally conceived as a web animation tool), but as it evolved its embedded scripting language become more and more powerful. This grew the Flash platform into a serious web application development tool. What can you build with it? There isn’t much it can’t do. Advanced game development, slick interfaces for web applications, etc. These were all standard affair when it came to Flash. And if that wasn’t enough, other tools that leveraged this power were added to the mix as well. The Flex framework was introduced to enable developers quick construction of Rich Internet Applications. AIR was added to enable desktop development with Flash. And so it grew in popularity. And with my love for “creative development”, I naturally embraced flash with open arms. I worked and toned my flash development skills over the span of ten years on various projects in the industry. I built e-Learning software, real time games, precise science simulations, and online tools for my students. After all these years I can say I know flash technology very, very well. And as all developers can relate, you tend to love the technology you know.
The IT industry is just like love – it is fickle and it forces you to make changes. The open source movement, coupled with a decrease of support for flash technology among many industry clients (thanks Apple) has forced me to start researching other avenues. Many of my students have been telling me about the power of Javascript over the last few school years, but I couldn’t imagine taking what I perceived as a giant step backwards in client side web app development. Nevertheless, I kept an open mind and dabbled in JQuery (an open source javascript framework) and made a few quick little apps to see what it could do. I was impressed, but it was really over the last few weeks that I have dedicated myself entirely to seeing what Javascript / JQuery / AJAX / and the HTML DOM have to offer. More importantly, I was interested in seeing how it ranked against Flash.
Step I : Converting a Simple Flash App Over To Javascript
I decided to start with converting a Rich Internet Application that I had developed using Flash into one implementing Javascript instead. This “portfolio” app was a class sample I use when I introduce students to the concept of dynamically generated XML (via server sided script) to populate a client side interface. Simple is always the best place to start…
Simple Portfolio RIA done with Flash
Simple Portfolio RIA done with JS
What did I learn?
- I used Javascript, AJAX, and the HTML DOM to implement this application and it was surprisingly easy to get up and running – Javascript has come a long, long way!
- Converting it over was much easier than I had originally thought – in fact, many of the lines of code in the Javascript version are exact duplicates of the Flash version. This isn’t too surprising since both languages are based on the same ECMA standard.
- There was no difference in speed between these two apps.
- The workflow for developing Javascript RIAs would definitely be much nicer for many developers since you are back using nice and cozy HTML / CSS for interface design (unlike the steep learning curve of flash’s timeline, symbols, etc).
- AJAX works really well and is just as good as the URLRequest / URLLoader classes of the AS framework.
Step II : Ramp it up! Converting an Advanced Flex App Over To Javascript
Ok, we might be on to something here…but this is a simple application. Let’s ramp it up. How about adding different views of the portfolio data and a progress/loading screen, etc? And while we are at it, let’s see how close it can match the functionality of a flash based application that was built using the powerful flex framework:
Advanced Portfolio done with Flex
Advanced Portfolio done with Javascript
What did I learn?
- For this sample I had to start using JQuery heavily. Although JQuery is a powerful framework, I find that I was most comfortable mixing some HTML DOM / Javascript concepts with it; however, it is not necessary. You can write entire applications without ever using traditional Javascript.
- JQuery is clearly designed to be a rapid development language, and as a result its syntax is highly recursive in nature in order to do a whole lot in less lines of code. I could envision it being somewhat difficult for some new learners to grasp at first.
- Having said that, JQuery is a godsend when it comes to targeting elements in your HTML; no need to mess with the getElementById() method all the time
- Many of the effects added to this application would not have been possible without the JQuery framework – not without losing my sanity that is…
- Every piece of functionality that I implemented with Flex could be redone using JQuery / Javascript – I am very impressed!
- This application included dynamically added elements to the “view all” view; although not done in an object oriented manner, it was still straight forward to implement
- Once again, no difference in speed between the two apps
Step III : Alright smart guy, what about an administration end?
The next logical step was to give AJAX a real run for its money by building a simple administration end. In order to do this I needed access to some new controls – but I am only limited to the controls of HTML, right? Wrong. JQuery UI comes to the rescue by providing a handful of new controls beyond the limitations of the <input> tag. Note: For security reasons this application does not actually update the content in the database – you’ll have to trust me that it works 
Portfolio Admin done with Flex
Portfolio Admin done with Javascript
What did I learn?
- JQuery UI provides a very powerful set of controls that not only are very versatile but can also be skinned using an online tool that outputs a stylized JS and CSS file – and the Accordian I decided to use for the Javascript version is quite elegant in its design and functionality. This control certainly rivals many of the rich controls offered in the Flex framework.
- AJAX handles sending XML just as nicely as receiving it
- In order to handle the live validation (something my flex version does not have) I had to actually go into the plugin I used and modify it. This isn’t uncommon in the flex framework as well, although I found working with JQuery plugins a lot easier since they aren’t dependent on multiple class files in a big long inheritance chain. I should note that messing with JQuery plugins is definitely not for the faint of heart
- Much like all the samples done so far, the code in the Javascript app was pretty close to the Flex app in both structure as well as syntax in most cases
Step IV : Apply it and dive into the deep end!
So far in my research Javascript technology has proven to be quite versatile and powerful and in all cases it measured up with Flash technology. But could it truly replace it? I needed to test this idea out. Over the years I have built many flash web applications, so it was really a matter of choosing one that would put Javascript (and my brain) through the gauntlet. I choose the event slider application I had developed for a local organization using flash technology. This application consisted of a sliding collection of company events that the user could explore. It was the perfect test as it incorporated XML fed data, loads of animation and effects, and a good level of interactivity.
Event Slider done with Flash
Event Slider down with Javascript
What did I learn?
- There were some serious challenges in developing this application. I used four separate plugins, and not one of them could be used as is – I have always found this with pre-built components. They don’t quite work exactly the way you need them to work and you are forced to go into them, figure them out, and tweak them. This process was somewhat daunting at times and I have to admit that during most of the development of this application I was wondering if it could actually be done…but I did succeed
- Cross browser tweaking was a pain and was something you don’t have to think about when using Flash. The flash player is the same no matter what platform you are on and you can therefore be sure that your SWF will always work. Javascript on the other hand is at the whims of the browser’s interpretation and we all know just how much browsers disagree with each other. W3C standards has tightened the gap up nicely, but I still uncovered a number of issues that had to be dealt with on a one by one basis for different browsers.
- The engines that run Javascript in some browsers are painfully slow and do not even come close to the speed of the Flash Player. For a while I had the event slider running perfectly on google chrome, but it would take up to 1 minute (along with the browser begging me to let it timeout) before it would load the XML and construct all the “blocks” of events on other browsers. I ended up fixing this by analyzing which functions were eating up the most cycles (one function took 37000 ms to complete!) and adjusted my code (just a note that the innerHTML property is a processor pig!). On top of that, it still doesn’t run as smoothly as I would like on Firefox and as of the time of this writing I am yet to test it on a MAC (I’m afraid to :S )
- Javascript, although supports objects, does not support classes which is a big step backwards in terms of re-usability of your code and could hinderance some developer’s code structure practises
- On the other hand, this event slider will now work on apple mobile devices!
- All the hype of HTML 5 is kinda lost on me now. Besides the new <video> tag I don’t see any advantage since you can implement a lot of the cooler features of HTML 5 using XHTML 1.1 and JQuery / Javascript.
- Firebug and Google Chrome Debugger tools are your best friend. Otherwise when you have a problem with your Javascript code the browser does nothing but stare back at you blankly.
Conclusion
My conclusion is pretty simple. Javascript technology has aggressively evolved throughout the years and is now a very powerful client side technology; largely due to the open source community. Eventually browsers will recognize that Javascript has become a pinnacle component of any webpage experience and the engines will speed up. Meanwhile, the W3C will continue to push compliancy making the cross browser development issues a thing of the past. But what is to become of my beloved Flash? Is this a flash killer? I don’t think so. As impressive as all this is, I believe that Flash will still reign in the web based game development arena for some time. As an instructor it makes sense to shift my delivery of flash technology into this discipline. But change is never an easy thing to do…especially with a technology that you love. But sometimes you have to set it free…
After spending a number of years teaching IT courses in a traditional classroom you tend to get dependent on many communication devices. Raised hands, confused looks, scribbling diagrams on the white board, pointing at computer screens, and even asking a student politely “Can I drive” while taking his/her mouse and demonstrating a concept to them right on their computer screen. Now imagine a teaching environment where none of these things no longer easily apply. A place where there are no more faces, confused or otherwise. This is the world of teaching a course online.
Over the past four months I have embarked on teaching my first online course with the Nova Scotia Community College. This introductory course is entitled Flash Fundamentals covering the basics of Adobe Flash design and development. Flash Fundamentals is a course I know well as I have delivered it on campus for a number of years, so I wasn’t terribly worried about the content. What I was worried about was if and how my teaching style would translate over this new medium, and ultimately, would I be any good at it?
These are just a few things I noticed:
Uhmmm…Dead Air…Uhmmm…
One thing I wanted to make sure I added into my first online course is a weekly live online session with all students attending (virtually that is!). A weekly session really helps build confidence and fight the feeling of isolation that many students in online courses battle. Surprisingly, I also found that it was also a great social device for the course as many students took this time to get to know each other.
Sound all great, right? The down side is that running a live online session is kind of cross between being a radio DJ and a live television producer. At NSCC we use a tool called Elluminate to hold live sessions which has all sorts of features like a live chat window, microphone support, and a virtual white board. As a moderator of the session, you find yourself juggling several things all at once. Firstly, you have to make sure that there is no dead air so that the flow of the session is smooth. Lesson flow is an important issue to me as a instructor as I believe that if a lesson’s concepts flow together logically and smoothly the connections and learning happens a lot more naturally. Secondly, while you are doing that, you have to continually monitor the classroom chat window, the whiteboard, as well as answer any questions coming in through the audio. It is sort of like digital juggling, except when you mess up balls don’t go everywhere; instead there is just a disjointed lesson that confuses more than helps.
You Need To Be Always On…
Teaching in a traditional classroom setting involves all sorts of lines of communication, but naturally, the most predominant is your class time with your students. This is that dedicated slice of time during the week when you have every student’s undivided attention (we hope anyways). In an online course you either no longer have this time or it is hindered greatly by the online technology. As a result, all other lines of communication that are usually secondary suddenly are predominant to the success and understanding of your students. Email, web boards, etc. become a major life line for all students. Unfortunately, these aren’t always the quickest means for a student to communicate with his/her instructor. Not to mention that for students that are really struggling with the course’s concepts the wait times between a question and an answer can be excruciating. As a result, I find that you really need to be monitoring these communication lines a lot – every single day. Going even a mere two days (like a Saturday and a Sunday) without checking in is equivalent to a student asking you a question face to face and you sitting their mute for two days looking uninterested before responding.
A Large Toolbox is Confusing for Anyone…
Technology has been the main reason online courses are possible today. And although it has made leaps and bounds over the last decade, I would still say that it is only about 60% of the way there. Problems with microphones, lagging internet connections, etc. have all occurred during my first online course. But the biggest issue I see is that although there are lots of applications that help in their own small way, there is no application that does it all. As a result, students have to learn and use a large collection of applications and tools, many having their own logins, quirks, and setups. For students who are weary about technology in the first place this can bury them before the course even really gets going. My advice is keep the list of applications as small as possible! Pick the ones that cover all the minimum requirements you need and work within those restraints. The not so techno-savy students will thank you for it.
Be a Dictator of Your Online Course…
Speaking of multiple communication tools, I have found that as an instructor you need to control the online course experience as much as possible or confusion can result. A good example is using a webboard. During my first online course delivery all the students had permission rights to create their own topics as well as add replies to any existing topics. The problem with this is that at any given time there were multiple topics on a specific lesson or concept each containing their own replies…the web board quickly began to get cluttered and confusing for students to even use effectively to find answers. I found it is best to limit topic creation permissions so that only I could create them. This way the webboard is kept much more tidy and kept as efficient as possible.
Snuggle Up With A Good Book/Resource…
As a result of missing out on that face to face instruction, quite often it is much easier for a student to become confused over a topic or concept. This is why it is really important to have a well written secondary resource to act as a backup for students when they need elaboration or help on a topic. I like to choose actual books as my resources mostly because it allows each student to review or go over concepts away from a computer. Since online courses require a high level of computer usage, I think of book resources as a nice break from the glare of the monitor. Something that everyone needs (even me) from time to time
I remember being a kid and in a mad rush to grab a hand full of cookies, pour a glass of milk, and run back to the TV before the commercial break was over…my father would always exclaim “Slow Down!”, and sure enough…there was always spilled milk.
It seems to me that information technology is moving in the same careless pattern. Technology companies are churning out new versions of their software at such a dizzying rate that there is a real disconnect from quality.
One company that seems to be the greatest offender of this is Adobe…I have been a college instructor for seven years and since then Adobe (Macromedia to a small extent) has released six versions of Flash…that’s right…six. Flash MX, MX2004, 8, CS3, CS4, CS5, blah, blah, blah! I understand that the IT industry is pretty ruthless and cutthroat (Steve Jobs), but there is real value in providing time for the development community to become efficient with a technology before new stuff is added to it again; or it is completely overhauled. Flash CS5/Flash Player 10 is riddled with inconsistencies with ActionScript behaviour, timeline glitches, and general weirdness. In fact, it is so bad that the animation department on my campus is seriously looking into other alternatives for 2D animation.
So, dear Adobe…get some patches out, fix these issues…and in the words of my father, “Slow Down”! Developers don’t appreciate spilled milk.
If you are a stickler like me then you are all about making sure everything you develop is compliant to W3C standards. This is as important as starting every sentence with a capital – ignore the rules and you look unprofessional and sloppy.
This can get challenging when working with server side scripting languages that render a lot of the HTML for you, like ASP.NET. Although .NET 4 does a pretty good job adhering to the XHTML 1.0 strict rules (although I would prefer XHTML 1.1) it breaks it when you have a radiobutton server control in your web app that is disabled. To disable it, the .NET 4 runtime adds a <span> tag around the <input type="radio"> tag. Wrong, Wrong, Wrong! The disabled attribute can’t be inside a span tag.
I still really wanted to disable the radio buttons (duh!) so to get around it I used JQuery. This is definately a hacky of a solution, but when it comes to W3C validation tactics it is in good company.
First I linked in the JQuery library:
<script type="text/javascript" src="resources/jquery-1.4.2.min.js"></script>
Second I setup the JQuery to disable four radio buttons INSIDE a panel and set its visible property to false so it isn’t rendered into the HTML until I want it to…
<asp:Panel ID="pnlJQuery" Visible="false" runat="server">
<script type="text/javascript">
$(document).ready(function () {
$("[type='radio']").attr("disabled", "disabled");
});
</script>
</asp:Panel>
Whenever I want to disable all the radio buttons on the page all I need to do is set the panel to be visible (visible = true). The JQuery inside will then be rendered into the page’s HTML and the browser will happily execute it – thus disabled radio buttons!
pnlJQuery.Visible = True
With the onset of graphic user interfaces, the mouse was propped up on a pedestal as the main input device and the poor lonesome keyboard took second stage. Not necessarily a bad thing…except users have become dependent on their mouse to do EVERYTHING. This is not so good.
With every new crop of students coming into our IT programs, I am always amazed on how much the mouse is used for the simplest tasks. Using the mouse can take 2-4 times longer to do a task that can be done with a couple keystrokes; especially from the point of view of programming. Copying a line of code will usually involve a new student grabbing the mouse, painfully selecting the entire line (if they can do it on the first try), right clicking on the selection and selecting copy from the shortcut menu. To paste, repeat process. One word, painful. Using the home, end, and shift keys along with the old trusty CTRL+C the same task takes about a second.
And it isn’t just about efficiency either. I am a big proponent of students using CTRL+S religiously in order to save their work. Too many times students have worked for two hours without saving…why? Cause it is a pain to mouse up to file/save in the menu or even click the save button in the toolbar if there is one.
So in a nutshell, become a keystroke junkie…learn and use those key combinations…pretend they dispenses candy…whatever it takes! In the end you will be surprised how much quicker you can get stuff done.
Every time I teach CSS to new web development students there is always a lot of confusion as to when you should use a style rule, an id selector, or a style class.
A Style Rule is used when you want all instances of a certain tag to be styled with a group of style properties. For instance, if you know all your paragraphs on the page need to be a certain color and have a bottom margin of 10 pixels you would create a style rule such as:
p {
color:#12324A;
margin-bottom:10px;
}
An Id Selector is used when you want to identify a specific section or tag of your markup for styling (or functionality) purposes. It is usually used on <div> tags, but can go anywhere. The big “gotcha” with Id Selectors is that they can only be used once throughout your entire page! This makes sense since it is an identification – it wouldn’t be doing its job very well if it didn’t actually identify a single tag but severals instead! For instance:
#myId {
color:#12324A;
}
<div id="myId">
This would be coloured by the Id selector style!
</div>
You can not give any other tags an id=”myId” and therefore your nice little #myId collection of style properties will only be able to be used once. Don’t get me wrong, Ids are quite useful, particularly when you start nesting them. But as it stands in our example they seem more like a waste? Well there is another option.
A Style class is much like an Id Selector except it could be applied as many times on as many tags as you would like using the class attribute. For instance:
.myStyleClass {
color:#12324A;
}
<div class="myStyleClass ">
This would be coloured by the Id selector style!
</div>
<div class="myStyleClass ">
And so would this!
</div>
Many years ago I found myself preparing for the interview of a lifetime. The job was a high paying, government sponsored, elite job that any web developer would love to get their hands on…and somehow, despite the recent dot com crash, I was given the opportunity to strut my technological stuff in front of a panel of bigwigs. I prepped and laboured over the interview, coming up with strategies, great demos, possible questions – I was ready for it.
I walked in that room, sat down and began to talk. And talk. And talk. When the time came, the panel started with their questions and I nailed them one after another…until one question in particular got me.
“If there was an upcoming jazz festival…what steps would you take to develop a promotional website?”
Okay, no problem. I talked about brainstorming with the designers, coming up with some clever ideas for navigation, thinking outside the box…and then moving on to prototyping and style documents, then development, then testing, etc. It was then that I noticed my panel all had blank looks on their faces.
A brave panelist spoke up, “You keep saying you would talk to the designer…umm…you realize you would be designing it…”
My heart drops. My smile drops. I couldn’t hide it. The job ad was listed as Web Developer, not graphic designer. Apparently, these people wanted someone who was an expert in ASP.NET, ASP, Javascript, CSS, HTML, Macromedia Flash, and databases on top of being a trained and skilled graphic designer (Photoshop, illustrator, etc)? Bollocks!
There seems to be some massive delusion amongst many companies that people exist out there that can do all these things well…the truth it…ready for this…there aren’t. Unfortunately, there is a cornucopia of people who are brilliant at graphic design and are total crap at programming…the funny thing is, they program anyways. All you have to do is look around the web to see how many incredibly badly written flash applications there are all over the place. Flash has always been a victim of this…graphic designers rationalize: well it is visual design platform and I am a graphic designer so I must be able to excel at Flash. This couldn’t be farther away from the truth.
This is not to patronize graphic designers and what they do. I highly respect those lot of professionals and from my experience the respect goes the other way to us developers as well. But designing and programming is not only two entirely different art forms, but they use different sides of the brain as well! It does go the other way as well…try taking a bunch of developers and ask them to design a website. One word – Scary. To expect great things from someone in both these arenas is not only far fetched – it is almost insulting to both professions.
So all those companies out there who think they can hire someone to do it all…I would suggest acquiring some wiggle room in your budget and be prepared to hire at least two professionals. Just like how firemen don’t fight crime – programmers don’t design.
If you have ever worked with complicated interfaces for flash based games or other applications you know all about how the best designed interface forces the user down the right path. In other words, a developer will need to constantly enable and disable controls (such as buttons, radio buttons, sliders, etc) of the interface in order to ensure the user does not end up doing something they shouldn’t and getting stuck in some sort of functionality purgatory; or worse yet, crash the app.
All object oriented programmers take pride in adding all sorts of cool properties and methods to our custom classes. We love making them as robust and encapsulated as possible. The process is no different when building classes for some of your fancier interface controls to handle the need to enable and disable it. You may add a nice “enabled” property or maybe a setEnabled(value:Boolean) method (for you Java developers) to easily lock a control from use at any time during the application’s runtime. The problem is that when you have several of these controls to enable and disable the task can get overwhelming.
There is an easier way. The displaylist to the rescue!
I adopted this method way back when using Actionscript 2.0 with Flash MX and for some reason am yet to shake the habit…mostly because it is quick and easy. When you have a set of controls on your interface that you need to disable, you could meticulously go through each control and set its enabled property to false (or whatever way you need to do it) and then go through them all again to enable them when the time comes later on. The question is, why not cover them up and block the mouse from detecting them in the first place?
To do this, draw a simple filled square in Flash, convert it to a Movieclip, setup its class name to be EventBlocker and publish your FLA into a SWF or SWC or whatever you are using as your library file. Construct the EventBlocker object in your code (the square), size and position it, make it transparent, and then add to the displaylist (using the trusty addChild) overtop of any controls you want disabled. When the user rolls over or clicks on any of the controls the eventBlocker object will pick up the events and not the controls below…easy disabling of multiple controls with no loops, coplicated data structures, or any other fancy coding required
eventBlocker = new EventBlocker();
// position your eventBlocker overtop of your controls
eventBlocker.x = 0;
eventBlocker.y = 0;
// size it to adequately cover the controls
eventBlocker.width = 310;
eventBlocker.height = 500;
// temporarily set the alpha to 0.2 in order to visually position/size it on your stage
eventBlocker.alpha = 0;
...
// disable all controls
this.addChild(eventBlocker);
