Flex Builder Cryptic error message

From time to time I find some fun errors in Flex Builder 3. Today for instance we were refactoring our framework project and moving some events and interfaces into our common library. All was going well until I renamed a folder (namespace) within Flex Builder to be singular (i.e. renaming dogs to dog).

Once I did this I got an error saying:

Cannot find source for class dogs.blah Location Unknown

My assumption was that this error was caused by the fact that many classes still referenced the dogs.blah class instead of dog.blah which was it's new name. After diligently fixing all of the references and package declarations within the project the error still occurred. Another developer sat with me and neither of us could figure it out, so I did what I always do in these situations, I Google'd it. And lo and behold I found the answer here.

Basically you need to go to the base directory of your project, open the .flexLibProperties file and remove or correct the bad class references.

This file contains an xml list of all classes to include in your project swc/swf file and for some reason doesn't update properly sometimes. I hope someone reads this and it helps them as much as the other post helped me.

Modular Test Driven Development

So as I mentioned before we've decided to use FlexUnit to do test driven development in Flex for our latest project. We also want to do modular development in order to support Bundles as per the OSGi framework which I also mentioned before. In order to make these two things work together easily I wanted to be able to simply drop modules into a 'test runner' flex application and have it run all of the tests embedded within that module. Zach Smith, one of our new developers, whipped up a pretty nice test framework and test runner application which allows us to do just that.

For the test framework he extended the Flex Module class to make a TestModule class. All of the tests within your module are then registered with your TestModule. Below is an example registering a TemperatureConverterTest.

You'll notice the line 'this.testClassArray' which is the inherited property from the TestModule class. After that you drop the swf from your built module into the directory containing the test runner application, edit an xml file to register your module with the test runner, and run the application. The application is the basic FlexUnit built in interface.

I'm really pleased with the way this turned out and it's going to make unit testing fairly easy since we can do it all in one central location, and since it's a Flex application we can leave it on a central server and run it from anywhere within our internal network.

Creating ASDoc for your Flex application

Since we're heading down the path of creating an actual product in Flex here I decided to look into ASDoc. Once I found the location of the asdoc.exe the whole experience was fairly painless. Above each of my classes and functions I've added a comment something like this:

/**
* Starts this class.
* Try to start this class.
*
* @throws MyError upon error of if the class was in an invalid state for this operation.
*/
function start():void

And then from a command prompt I typed:

C:\Program Files\Adobe\Flex Builder 3\sdks\3.0.0\bin>asdoc -doc-sources "C:\MyProject\src" -main-title "My OSGi Framework" -window-title "My Documentation" -output OSGI_ASDoc

after hitting enter I got this status message:

Loading configuration file C:\Program Files\Adobe\Flex Builder 3\sdks\3.0.0\fram
eworks\flex-config.xml

followed by a 'complete' message. The resulting html document looks much as you'd expect a Javadoc to look, with links to each class and package along with your comments. I'd suggest this to anyone trying to keep up with a fairly complex object model, especially if you will be having more than one person working on it.

Flex Holistic Lab Wrapup

This past week in the ESRI Holistic lab was interesting as always. The Flex API is moving along nicely, now containing api toolbar functionalities, like the drawing toolbar, which really makes life easy for those of us doing redlining and more within the api. I already had a firm grasp of the framework’s intended uses and functionality so I ended up pinging the ESRI team most of the week with feature requests and programming framework questions.

The end result of this week’s testing is that I think I’ve managed to decide on a list of api, application, and programming frameworks that we will use in building our new software. For our prototype version of Network Express we used Fluorine, a .NET gateway technology, to handle all of our calls from/to the server and our Flex application. This was a natural choice for us as we’re mainly a .NET shop and it was easy to write all of our server side classes and web services quickly in C# and ASP.

Moving forward however it seems that if we stayed the course with Fluorine we’d be out on a limb all alone. No one on the ESRI Flex API team (I’m just gonna call them EFA team from now on) have even heard of Fluorine and a number of them come from Java teams within ESRI. As a result they tend to gravitate towards Java based technologies for their server side components. Add to this the fact that Adobe (the company that produces the Flex SDK and Flex Builder) has their own server side product, Blaze DS, which is built on top of a Java platform and it appears that peer pressure has forced our hand. The EFA team are comfortable with Blaze and have used it for several projects, and although they didn’t explicitly say “don’t use .NET!” the mere fact that if we had any technical issues we wouldn’t be able to lean on them for support makes it seem like a bad idea.

So I spent the week largely looking at Blaze DS, which works great actually, once you get used to coding all of your server components in Java. Luckily for me I spent a couple of years coding Java in the past and so it wasn’t too much of a stretch to brush up on my syntax enough to get a few things working.

Late one afternoon I was speaking with Ismael Chivite, the lead of the ArGIS Server group and a generally nice guy, about doing server side coding and he mentioned something that gave me an “aha” moment. He told me to be careful when using a server context to create objects because each time the context is used it makes a call back to touch the SOM machine. Whether you know what this means or not doesn’t really matter, the punch line is that I suddenly remembered our prototype doesn’t take any advantage of the distributed processing environment offered by ArcGIS server at all! We knew it would be necessary long term for the actual product to do so in order to provide a stable, scalable product but we had other things to worry about for the prototype so we let it go. At some point in all the worry of learning the new EFA, learning basic Flex best practices, and deciding on server side technologies and overall architectures and frameworks to use the fact that our current server side design was completely un-scalable had slipped my mind. So I added that to my list of to-dos.

Mid-day Thursday afternoon I finally got my Blaze DS setup working and talking back and forth with my Flex application. I found a great example here by a guy who had gone though my same issues, which was awesome. After I was confident with that I went back to the Java class I had written that morning to create a point feature in SDE using a server context, and consequentially a SOC process. Antony, one of the EFA team members found this site for me which really helped me past the last few issues I was having with it. Blaze DS is so fast in transmitting data back and forth from the server and the Flex application that I didn’t even do any debugging in my server side classes, I simply returned any errors they had to my Flex app and debugged through it. The response time was so fast that I had no problem doing it this way and less than an hour after I got Blaze up and running I was creating features in SDE through my Flex application.

Do’s and Don’ts of Server Context programming:

· Don’t simply ‘new’ your variables, you need to use the server context to create them. Otherwise you’ll end up with automation errors. This occurs because the objects need to be created within the context of the SOC process which will be running your code.

· Do release your server context in a ‘finally’ block or otherwise assure that it will always be released, otherwise you’ll end up bogging down your server when errors occur and the process sits around waiting to time out. This caused me several minutes frustration while I was initially debugging my server side code.

· Do follow all standard Arc Objects programming practices when using a server context. If you would start an edit operation in a standard Arc Objects application, start one in your server code.

Application Frameworks

We talked about several frameworks during the week and I took a hard look at three of them: Cairngorm, the M Framework, and Mate (pronounced like latte but with an m). Cairngorm is an application framework developed by the Adobe solutions developers and is designed to help teams create complex and robust applications without stepping on each other’s toes and getting bogged down with interdependencies and repeating code. The M Framework, named after Mansour Raad the lead EFA team guru, is the name Mansour jokingly gave the framework he uses when creating solutions for customers. It is basically a pared down version of Cairngorm in which he has left the parts that are useful to him and removed the parts that don’t actually give him any benefit and simply create extra overhead. In my opinion his framework is great for any small to medium project with a team of 1-3 developers, but I think you would miss some of the things you gain with full blown Cairngorm on larger projects. The last framework I looked at was Mate. It is the current flavor of the month in Flex frameworks and is generating a lot of buzz. I downloaded the framework and looked at some of their examples and I guess I am still reserving judgment although I think I’d have to say it’s not for me. It seems to be a slick, low maintenance framework though. It’s deemed as a framework for people who hate frameworks and I can definitely see that. For me though I just don’t think I’ll ever be working on the type of projects that it’s meant for, and as an Engineer at heart I love frameworks.

OSGi

The OSGi framework is an application framework for large Rich Internet Applications (RIA) which allows you to drop new components into the working directory of an application and have the app find and expose the new functionality immediately. Basically the way this works is that each new set of functionality you create for an application is wrapped up in a Bundle (IBundle). This Bundle can then be discovered by your base application when it is present, and the functionality it contains is exposed as services which are registered so that any other service can gain access to them. This means that if two related Bundles are present they may use one another to enhance their own functionality and if one of them is removed the other will continue to work but the available options may change. This is exactly what we want for Network Express and is also exactly the way our current field application works. You simply develop new functionality, drop it in the bin directory of our app, and boom, you can use that functionality within our existing application just like it was native.

Resolving OSGI and Cairngorm

So great, I have found two frameworks I want to use. Now how in the world am I going to use both of them on one project? Well first off, OSGi is a Java framework. That is, it was developed to work for Java based web applications. This being the case there isn’t really an official version of the framework for Flex. This is a mixed blessing for us. It means that we have to develop the framework on our own, and mesh it with the Flex notion of Modules (Modules are dynamically loadable swf files for Flex applications) and at the same time interweave it with the Cairngorm framework, which is based on Flex, although an official Flex 3 version of it has yet to see the light of day. The fact that Cairngorm is open source may end up being the saving grace for us in this situation but my initial feeling is that we’ll end up using Bundles from OSGI to encapsulate functionality which is built using Cairngorm, with one master Application Bundle that runs all of the rest.

Oh yes, and don’t forget that we will be using Test Driven Development (using FlexUnit) for each individual piece of functionality. I’m sure there are going to be even more intricacies I have yet to even consider, but hey, that’s the price of doing something new and hopefully cool.

Overall I’d say my week of testing was a big success. I managed to get a handle on using Server Contexts, learn and test the new pieces of the EFA, and begin to get a grip on how we’re going to manage to develop this whole mess. I’m sure it’s going to be busy over the next few weeks but I’ll do my best to keep our progress updated here and post any interesting problems/solutions we run into along the way.

Greetings from Redlands

So I'm spending another week in Redlands, CA this week doing more testing of ESRI's new Flex API. I've got a lot of notes and things to go over here that I'll do over the next several days. A lot of what I'm dealing with now is deciding on the overall architecture of the product we plan on building on top of this new API. I'm dealing with application frameworks, server side technology, etc. I'll post about all of the ones I'm considering and what I like/dislike about all of them.