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.

ESRI Holistic Lab: Flex API Day 3

I got around to asking about two things I would really like to have in the Flex API on day three: Will there be a way to change the version I am seeing, and will there be a way to change the data frame that I am viewing? The answer here was pretty much what you would expect. If the REST API will support it then the Flex API will be able to do it, which means that it isn’t currently available. That means this will still be one area where the ArcServer WebADF will outshine Flex. There are of course ways to get around this. You can create a Map Service for each version you wish to see although that will potentially cause problems with far too many Map Services. As far as data frames go, the same applies, simply create separate map services for each data frame.

Built In Tasks

Having gotten the QueryTask to work on day two I decided to take a gander at the other built in tasks on my last day in the labs. The other two currently available are the Locate and Find tasks. They work similarly to the QueryTask, using the built-in support of the REST API to do their work. Neither of these tasks is currently bug free however so I was unable to satisfactorily test them.

Debugging

This leads me to the next thing I would like to go over, debugging your flex code. Here, especially when using native REST API calls, you can take serious advantage of the Services Explorer. This is typically located at http://serverName/ArcGIS/rest/services and from here you can view any of the MapServices setup for that server. You can also see what capabilities exist both for the service and each individual layer and even test them. The explorer also has links directly to the REST API documentation which can be invaluable.

The other priceless tool for debugging is an extension to Firefox called Firebug. Firebug allows you to see requests being made over your browser. You can then see the request, header, parameters, and the response. By right clicking on a request you can copy it and then paste it into your browser’s address bar and see the result in your browser. I was able to figure out several issues I had with the QueryTask by doing this and then manipulating the variables directly within my request. I wouldn’t recommend working with the Flex API without using Firebug or something similar.

Building an Extensible Framework

The original Flex API from ArcWebServices was built on a variation of OSGi www.osgi.org/ which is a dynamic module system originally created for Java. Using such a framework allows for seamless adding and removing of modules from an application without having to take it down. You can simply drop a new module into your framework on a server while the application is running and it will be discovered and its functionality made available.

Eclipse (the base application for Flex Builder) is built on top of the OSGi Spec. The basic idea is that each module you create must implement the IBundle and IBundleActivator interface. When a new module is discovered your application then casts it to an IBundleActivator, passing it a context (IBundleContext) and retrieves all of the services (IService) from the module. Now any other part of the application can find and use the services provided by this new module. There are several freely available OSGi frameworks. Knoplerfish ( http://www.knopflerfish.org/ ) and Felix ( http://felix.apache.org/ ) are two fairly uncomplicated and well known ones.

Transmitting Data

We also spent some time on the different ways to transmit data using Flex. There are three basic ways beyond Web Services which are available: Remote Objects, messaging, and data services. Adobe provides a free Blaze DS service which allows you to do the first two. If you want to do the third though, you’ll need to shell out $25,000 for the privilege. Each of these transmission types buy you something. Using remote objects allows you to transmit actual objects as binary over the wire, speeding things up considerably over the use of web services. Messaging allows clients to subscribe to a destination point on a server and then receive any messages that come from there. Data Services allows for things like ‘active rows’ where you are given and can manipulate a row from a database table that will automatically manipulate the row on the server and let other users of that row that it has changed. There are a lot of powerful uses I can think of for this last method which is probably why it is so expensive.

ESRI Holistic Lab: Flex API Day 2

Day two for me consisted mainly of trying to get an extent QueryTask to work in order to do feature selections. I had already created a map service on my machine which exposed a set of utility data. My first task was to create a graphic to allow users to click and drag to create an extent for their selection. This was somewhat less straight forward than in the old ArcWebServices version of the Flex API as there is currently no easy way to draw an interactive extent on the map with no mouse handler interface and toolkits not yet implemented. One of the Flex API team members gave me a sample which got me jumpstarted however. In the end it was a case of simply hooking the mouse down, mouse move, and mouse up events. The tricky part was getting the extent rectangle to draw the way I wanted. I never really got it to look the way I wanted, but I did get it to work. The really nice thing about this is that using the new REST api available in 9.3 you can query on a layer with no custom web services. The query capability of the REST api is nicely wrapped up within the QueryTask object. I’ll not go into too many details about it because I don’t want to push the NDA I had to sign too far but the Task interface is going to make a lot of people happy, not to mention making their jobs easier when creating flex applications.

We also sat together as a group for a couple of hours in the morning and afternoon and talked about basic Flex programming dos and don’ts. Many of the following ideas come from the Cairngorm flex framework http://labs.adobe.com/wiki/index.php/Cairngorm

Code-behind

We started out by going over the basic GUI coding paradigm of code-behind and how it works in the Flex world. The best way to do this is to create your own Actionscript class, MyApp for instance, which has Application as a super class. You then create your base application mxml and have it subclass your MyApp Actionscript class. At this point you can put all of the code you need to run your application within its own actionscript class and keep it completely separated from the mxml gui tags. In order to access your gui items from your MyApp class you must declare a public variable within your class with the same name and type as the items within the mxml. So if you have a in mxml then you would need a public myLabel:Label declared within your MyApp to be able to access it.

The names that you give your objects now become very important because you will be coding the logic in a separate file from where the GUI is created. If you name your objects and event handlers poorly you will have trouble keeping up with what functions and items do what. Therefore it is good to not only give your objects meaningful names but to also follow a standard when naming your event handlers. Using the convention of objected_eventNameHandler() is the standard way of naming your event handlers and does a good job of concisely informing you on what it is (an event handler), what type of event it handles and for what object it does the handling.

Making use of Singletons

Cairngorm recommends creating a bindable singleton class which holds on to all of your application level information and allows any class to manipulate that class level data and always be sure that it is the correct version of the data. Making the class bindable also allows other classes to bind to these application level variables and be automatically updated when those values change. The Flex API team called this class the Model. We used a singleton class in our original Network Express prototype which definitely made life much easier but the one we were shown had a couple of advantages over the one we used previously. Chief among these was the ability to make sure that only one instance of the Model is ever created, and the ability to be certain there is only ever one instance of any given application level object.

The Flex Object Lifecycle

All objects which are created in the Flex world go through the same cycle when they are created. There are several events and functions which fire off that can be overloaded to allow you as the programmer to perform specific functions even before the CreationComplete event has fired.

·

• New (Label) – the first step is the object instantiation is started.
• PreInitialize – an event dispatched before any actual initialization takes place.
• Setter – calls all Set functions
• Initialize – another event dispatched to alert of actual initialization
• CommitProperty – a function. Overriding this function will allow you to make changes to the object atomically, preventing flashes and other artifacts from occurring as properties are set.
• CreateChildren – function which starts the Lifecycle on all children objects. This is another function which can be overridden.
• Measure – Sets all of the width, height, etc.
• UpdateDisplayList – function that adds the new object to the display list atomically.
• CreationComplete – the final event which signals that the object is complete. This is called only once.

Simply knowing about this lifecycle opens a lot of possibilities, especially with the functions which can be overridden.

Tips:

1. Make sure to listen to the Load event on map objects as the CreationComplete event will fire well before any layers have actually been loaded. Trying to manipulate the map before the Load event will only cause you heartache, and errors. Each individual map layer will also fire a Load event.

2. Always call super on all overloaded functions. Failing to do so will keep the normal behavior from occurring.

For more information on the Flex lifecycle check out this document: http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000492.html

Events

Let’s say you have an application with a VBox that contains a button. The display tree would look like: Application --> VBox --> Button. If you were too hook into the click event on this button then I’m sure you can guess that your function will be informed when the button is clicked. What you might not know however is that Every item in the display list starting at the top will receive a click event as well. This means that if you were to hook the click event on the VBox or the Application you would catch an event each time the button was clicked as well. So how does your function know if the event it catches was meant for it? The event object has target and currentTarget properties. The target property contains the id of the actual target of the event and the currentTarget property contains the id of the item in the display list currently receiving the event.

Events also have a phase. There are two event phases: capture and bubble. The capture phase occurs as the event is making its way down the display list looking for the target. If you need to cancel an event for some reason you would want to handle it during the capture phase. The bubble phase occurs on the way back up to the top of the display list. When a handler is added it will fire by default on the bubble phase. There is also a bubbles property on an event which is set to true by default.

Delegates and Unit Testing

During the afternoon of day 2 we sat down together and did a quick example application using Delegates which we then performed unit testing upon. Delegates take the idea of code-behind a step further. Once you have your mxml application and the code for it separated, you then perform all of the actual logic of your program via Commands. These commands are called by events in your code-behind which then in turn call their own Delegate classes which perform all of the actual work. The Commands are then in charge of making changes to application level data within your Model. Delegate classes are completely independent of the rest of your program, not caring how they are used as long as they receive their input in the correct form. The Delegates for your application can even be removed to separate swc libraries without causing any issues. This allows teams to break up tasks fairly easily and logically. One person can be in charge of creating the GUI for the application, another in charge of the code-behind application and commands, and yet another person or group can be in charge of creating the Delegates to actually perform the logic of the application.

Unit testing can be performed on Delegate classes very easily because they have well defined inputs and outputs. As long as a Delegate receives input in the correct format it doesn’t matter where it comes from. The unit testing framework we used was Flex Unit http://code.google.com/p/as3flexunitlib/ which is a free download and a very slick addition to your Flex environment which I highly recommend and plan to use myself.

Tips:

When your mxml application is compiled by the flex compiler it goes through several steps. First it is parsed into MXMLC and then it is translated into an actual actionscript (as3) file before being compiled into a swf. Now I know what you’re thinking, wouldn’t it be nice to see how flex natively converts all of those mxml tags into neat concise code? Well it turns out that you can. There is a compiler setting which allows you to tell the compiler to leave all of those as3 files behind instead of deleting them once it is finished, allowing you to learn all types of tips and tricks by seeing how the compiler creates all of that code.

Holistic Lab: Flex API Day 1

Error Handling

This is obviously the first beta, and a closed beta at that, of the new Flex API so you expect a few rough edges. One of those is error handling. There are a few places where I would expect no error to be thrown but they are anyway, if a layer’s url property is set to an empty string then the next pan/zoom will throw an error, and a few places where you would like an error to be thrown to let you know something is wrong and it isn’t. The main place I can think of is when a tiling service fails you have no way of knowing this which caused some of the people here issues. I have no doubt these will be fixed going forward.

Authentication

There is no support currently for secured services. If you want to use one you must first add it to an mxd and then expose it as an unsecured map service in Arc Server. I did this with an IMS weather service and it worked just fine. This is something that will be added but hasn’t crept to the top of the development team’s list yet.

Slow/Dead Services

There are issues with services which are either slow to respond or have died. When a zoom occurs and a service doesn’t respond correctly the area on the screen which is coming from that service will behave weirdly, growing or shrinking out of proportion with the rest of the map. This caused a small set of data in Montgomery to eventually cover the entire South East US for me when I tested it by stopping the map service completely. In the case of extremely slow services this will eventually correct itself but it may take several minutes. This is something the team was working on fixing as the day progressed and may even now be dealt with.

Layering Services

Layering multiple services is now much smoother than it was with the old api. When you drop services on top of one another they now automatically leave the area not covered by their features transparent. This means that if I put a map service with gas mains on top of a service showing street data I can automatically see all of the data. This is a nice improvement from the past when you had to set transparency colors etc. to get this effect.

No More IMouseHandler!!

The IMouseHandler interface is gone with the wind. This made me sad mainly because we have created a number of mouse handlers to do various tasks for us. After talking it over with the development team however it seems there will be a new paradigm called Toolkits which will allow the same type of behavior along with (hopefully) even more flexibility...no pun intended.

TOC Control

One of the first tests I did was to recreate the table of contents control I had made with the old api. This is now much more straight forward. LayerInfo objects now come along with your layer when it is received from the rest api. This means you can immediately cycle through all of the layers, drop them in a VBox as checkboxes, and correctly check/uncheck them based upon the default visibility property. I was very pleased with the TOC control in both performance and ease of coding. The only issue that I saw was when switching the URL of my background layer there would be a flicker as the background turned momentarily white. I didn’t even notice it at first but when the Product Lead was watching me show the TOC control he commented on it. I’m not sure if this will get fixed to not redraw the background layer until the new source comes through but that would be a nice little adjustment.

Tips:

Use when debugging. Lots of useful information comes through here which can help you solve your issues.

Whenever you change the underlying map document for a map service be ready to also clear the REST cache. You can find the REST manager by going to http://servername/ArcGIS/rest/admin where the only option is currently to clear the cache or setup a schedule for it to be cleared. If you don’t do this and the api has already been used to get information on that map service then you will get some strange inconsistencies.