Aurora and Sol 0

Posted October 16, 2006

Those are the names people: mark em down. Flexamp is on its way out :) . I kinda want the player name to be independent of the technology behind it (I am following an industry norm here. There arent and C++MediaPlayers or JavaAmp :P ). While these names may or may not stick, these are the package names of the Flex Project and the J2EE Project on my Eclipse application so they will always be reflected in the source files.
I am fairly far ahead on the clientside implementation of the player but am just about starting the J2EE part. I havent mucked around with J2EE as much although I do come from a Java background as such. Desktop Java has much fewer rules to adehere to. The first step in J2EE is the biggest one and understanding the structure of a J2EE app does take some serious reading.
Of course there is a leap from the book to the server ;) .
So here is the story of day 1 of Sol development.

Step 0 – Choose Eclipse:
I do all my programming on Eclipse and love it. Ever since the ASDT plugin came out, Eclipse has been my standard development environment. Its well integraded with CVS and SVN and allows quick text searches which makes life a lot easier. And developing Flash and Java on the same IDE is veeeery convinient. The web tools project is something I am just getting used to and while I have heard seasoned Java developers complain about certain features, my own experience has been fairly good. So armed with Google, I created the Sol project.

Step 1 – Get your J2EE app container + MySQL database:
My www host runs Tomcat 5.0.27 so thats what I run as well. I also downloaded the appropriate MySQL version

Step-2 – Create the Dynamic Web Application Project:
This is a project template that I think came with the web tools plugin on Eclipse. Once you create a new Dynamic Web Project, Eclipse will create the WEB-INF, META-INF, classes and lib directories as per the J2EE spec(A typical j2ee webapp should look like this) in a folder called WebContent. That folder can go as is as a webapp in a container (although typically you would deploy it as a web archive (war) file).

Step 3 – Include the jstl taglibs in your container:
Since I will be using the Java Standard Taglibs, I downloaded the jars from the Apache site. Include these taglibs in either your application’s lib folder or, preferably, in your container’s common lib directory (TOMCAT_HOME/ROOT/common/lib/) which would make them visible to all the webapps.

Step 4 – Create your basic JSP
Since the goal of this pass is to verify that my installation is correct, I wrote the simplest JSP file. You can download it from here.

Step 5 – Run the JSP from within Eclipse:
Make sure that the Tomcat Engine isnt running and then right click on the project and choose Run As … > Run on the server. Update the files if prompted and point to the installation directory of the Tomcat server when prompted to choose the local server. As the server starts up, the server logs appear in the Console window. Eclipse will then launch the built in browser and point it to the application root. Click on the JSP page and ensure that it works.

Possible issue: I have no idea why this was happening but even though my JAVA_HOME environment variable was pointed correctly to the JDK, Tomcat could still not find the javac tool to compile my JSP. On a thread I found the solution to put the tools.jar into the TOMCAT_HOME/common/lib directory. That worked.

Cheers.

and finally…. 0

Posted October 10, 2006

The try-catch block is possibly one of the least used elements of AS2. Adobe’s page on the try catch block on livedocs is bare bones and pretty much mentions what it does and little else. For the most part, most flash developers are unfamiliar with the concept of error bubbling and you can pretty much get by without it. For example, if you are reading an xml file, and know that it may not exist, you can construct the code like:


var x:XML = new XML();
x.onLoad = function(success:Boolean){
if(success){
// success
}
else{
this.manager.xmlError();
}
}

Here, the manager.xmlError() function deals with the error situation. However in the try catch block way your code would look like:

var x:XML = new XML();
x.onLoad = function(success:Boolean){
if(success){
// success
}
else{
throw new Error("xml load failed")
}
}

By using the throw keyword, you are declaring that that particular class is aware of a failure situation but its upto some other class which is below the class object on the invocation stack to deal with it (Java also has a 'throws' keyword that is used againt the method name to reinforce the fact that the function will throw an error).

So in AS2 land, while errors were 'nice-to-haves', they were by no means mandatory. This situation has since changed in AS3 and flash developers must now be really aware of this programming paradigm. In AS3, the player itself generates errors in certain situations and it is upto your code to deal with these runtime errors.

If try-catch blocks have been the neglected children of AS2, the finally keyword has been the forgotten one. Most of the code that deals with catching errors pretty uses try and catch but hardly ever finally. Code in 'finally' blocks is guaranteed to execute regardless of what happens in the try-catch block. While explaining the concept of finally, one of my collegues asked me the purpose of finally. For example if you have


try{
}
catch(e){

}
finally{
/// statements here
}

how is that different from
try{

}
catch(e){

}
/// statements here


I did not have any immediate answer for that question besides the better-readability of the code. Reading up on the Java implementation and talking to Java developers (most of whom end up not using it too ;) ), brought out the most important aspect of the finally statement. The part that I hadnt realized was that the finally block is executed even if your try block succeeds and does a return.

In the meanwhile make sure you are upto speed on compiler errors, warnings and runtime errors in Flash.

WOOOW 0

Posted October 4, 2006

Hot of the press: Flash player 9 will soon be supporting fullscreen applications. This is freaking awesome !!!!

Check out the news at the Adobe Labs site

[Update]
Oops. I jumped the gun. Fullscreen doesnt allow keyboard access. Its supposed to be for ‘viewing’ things. sigh !