Passing data back and forth to a View in a Mobile AIR application

On a recent AIR for Android app I was working on, I had the need to send data back from the current view to the my controller.  The app was really simple, but the ability to send back the data to my data controller changed it from a 4 hour app to an entire day project.  It turns out, when you design your app around the ViewNavigatorApplication or the TabbedViewNavigatorApplication, they make it really hard to get a reference to the instantiated View created by the navigator.push() function.  In fact, since the navigator.activeView casts everything as a View (and it does it on the next frame, so you can’t get that reference anyway), rather than your custom class, you can’t call any methods in that class, nor can you attach any custom events.

This makes it very difficult if you want your controller (or in my case, the main application) to push or pull any data to the View after it has been created.  I didn’t want to re-create the functionality of the ViewNavigatorApplication by hand — they did lots of really nice stuff in there, but the inflexibility seemed kind of odd.

Anyway, I remembered that you could bubble events from the view and have the main application be the event listener to catch it.  While it does have the added advantage of not directly creating a reference to the View (preventing it from being garbage collected), it feels really dirty in my mind.  I guess I’ll get over it.

Injecting data to the View from the controller is a bit more trickey.  What I ended up doing was creating a new class that extends EventDispatcher, and adding getters and setters that dispatch their own events.  I would then package that custom class in the data property and send it along in the push function.  I can then have that View listen to events off that class, as the class dispatches them with every change.  Again, this won’t cause any references to the View (which is what the SDK was trying to avoid), but I can still get my data there.

Connecting your Flex application to BlazeDS or LiveCycle DS

If you have ever attended one of my presentations on BlazeDS, LiveCycle DS, or Flex/ColdFusion, you have heard me talk about how bad the data-connectivity wizards are in ALL of the IDEs available for the Flex SDK.  Even the new Flash Builder 4.5 dosen’t address the white-hot mess they call the data connectivity wizards that they started including in 4.0 (Side note:  I love most of the features in Flash Builder — I use it every day, but some of the wizards they included to make life easier really don’t).

Even including the services-config.xml document as a configuration option in your application will often lead you to troubles in the long-run.  This is included for you when you tell Flash Builder that you want to use ColdFusion or Java as your server model.  When you do this, the compiler inspects your services-config.xml configuration document on your server, and builds a table of the channels (endpoints) and destinations that are configured on the server.  You can then call the destination by name in theortags and not have to worry about how your client actually connects back to the server…

… untill you need to move your application…

… or you need connect your AIR application to your server…

… or you have a mobile or television application that needs resources on your server…

… or your server’s configuration changes.

Destination properties available at runtime

In my last blog post I mentioned that there were various properties available when you create your own BlazeDS / LiveCycle DS destination at runtime.  The properties available to you are based on which type of adapter you are using.

Each set of properties is baked into a ConfigMap instance that you pass to the initialize() method of the adapter.  In my research, I’ve found that there are some adapters that fire up ok without any properties defined (these tend to be the open-source ones), and some which cause all sorts of issues unless you have certain magical properties defined (these tend to be the closed-source ones).

In addition to the regular properties, there are also “ServerSettings” and “NetworkProperties”, which are not covered here.  By not setting those properties, your destination will assume the defaults.

So, what are the available properties that you can set?  Below is a list of the service/adapter/properties:

• remoting-service    (used for Flash Remoting, Remote Object connections, and “AMF” connections)
• ColdFusionAdapter “cf-object”   (used to connect AMF messages to CFCs)
• access  (as ConfigMap)
• use-mappings    (true/false) ***
• method-access-level   (“public”/”remote”) ***
• property-case  (as ConfigMap)
• force-cfc-lowercase   (true/false)
• force-query-lowercase  (true/false)
• use-accessors (true/false)
• use-structs (true/false)
• Java Adapter “java-object”   (used to connect AMF messages to Java classes)
• include-methods (if defined, this is the list of methods that are allowed to be called)
• exclude-methods (a list of methods that are blocked from being called. do not use with include-methods)
• method
• name
• messaging-service   (used for realtime messaging applications)
• cfgateway  (used to have ColdFusion mediate messages on the destination)
• gatewayid  (the dot-location to the cfc that will handle the message) ***
• gatewayhost  (used to define which host is hosting the cfcs, if it is not localhost — for example if your BlazeDS server is different from your CF server)
• allowedIPs (which servers are allowed send data onto the destination back to the clients)
• remote-username  (bakes in this username into all the packets sent to CF)
• remote-password  (bakes in this password into all the packets sent to CF)
• actionscript
• (there are no properties for ActionScript.  Send in an empty ConfigMap)
• jms
• jms (as ConfigMap)
• destination-type
• message-type
• connection-factory
• destination-jndi-name
• delivery-mode
• message-priority
• preserve-jms-headers
• acknowledge-mode
• max-producers

There are also services for proxying and data-management, however I’ve never used them (well, I have used data-management a lot, but since the licensing changes to LCDS, it’s pretty much dead to me).  I don’t know much about the jms adapter, so I can’t really say what all the properties mean, but I do know they are there. 

I have marked some properties with a ***.  If you see that, you need to include it, or you will get varied results in creating the destination at runtime (most likely, it will fail the first time you send data to it, rather when you create it).

Creating runtime remoting destinations in BlazeDS and LiveCycle Data Services

Ok, lets dive right into a really geeky topic… destinations in BlazeDS and LiveCycle Data Services.

For one of my customers, I was given the requirement to create a runtime destination in BlazeDS.  BlazeDS, along with its bigger brother LiveCycle allow you to create destinations in one of two ways — via the configuration XML files (services-config.xml, and related files), or via Java calls.  I won’t talk about the XML file method because it is extremely well documented.  However, the biggest disadvantage of the XML file method of creating destinations is that you usually have to reload or reboot your server in order for the changes to take affect. 

Runtime Destinations are not permanent — they do not persist during restarts.  They are also not magically added to the XML documents either.  Their creation is also often blocked on shared hosting servers as well.  But besides that, they act and smell just like ones created by the XML documents.  Why would you want to use them?   There are quite a few reasons for wanting them — for example to help secure your server by only exposing your destinations on demand, or by providing private destinations to clients so there is no way that data can be shared (in that case you COULD use subtopics, but that is controlled by the client).  In my case I was asked to provide a solution where the client would not have to change any configuration files when they installed our application.  We were using ColdFusion 9 as our back-end server, but these techniques work for Java based solutions too (you would just have to change the Syntax a bit).

I’ll start off by saying that the documentation is extremely poor (I wish Adobe would make this stuff clearer one day!), but with the help of two people, Sven Ramuschkat and Marko Simic, I was able to get to the point where reading the source code made sense.

The first step in creating the dynamic destination was getting the instance of the Message Broker.  The Message Broker in BlazeDS/LCDS is the guy who does all the work for remoting, messaging, data services and proxying.  You can access it in ColdFusion with the following commands

this.blazeDSClass = createObject("java", "flex.messaging.MessageBroker");
this.blazeDS = this.blazeDSClass.getMessageBroker(javacast("null", ""));

As a teacher

I, in general have been very quiet in the technical front as of late.  This last fall one of my very good friends and mentors Ron Choura passed away suddenly.  After loosing another close mentor of mine this just the year before it hit me really hard.  Both Ron and Dr. Muth were instrumental in my schooling and career advancement. 

With Ron Choura’s passing, his upcoming class was missing an instructor.  I was asked to fill in for the class that was set to start a few weeks later; I couldn’t think of a better tribute than to teach the class that I enjoyed most during my time at MSU.  My manager at my day job helped with the class as well.  The class was titled “Advanced Network Design” and had a focus on how the telecommunications world works from the phone jack of your house to the jack of the other person you called.  It also had a project where the students were to write an extensive RFP (Request for Proposal) for a telecommunications based company. 

The class itself went off without a hitch.  It made me realize how much work running a class like that really is.  Despite knowing the material cold (heck! it’s stuff I do during my day job), it still required about 12 – 14 hours of prep time for every week’s class.  Between prepping for the power-point, grading, setting up the next assignment and setting up the next exam (we had exams each week), it took a lot more man-power than I had ever expected out of a 4 hour class. 

I’ve been out of school for nearly 7 years at this point, so interacting with the students was very interesting.  When I found out I was going to be teaching the class, I immediately dove in and did the research as to what tools they would want to use to communicate, how to best reach out to them, etc.  I had a chance to reach out to my favorite EduTech professional Leigh who also gave me some useful pointers. 

 Some of the things that as a telecommunications professional I “knew” but my students made very apparent :

• Not a single one of them had a land-line telephone at home.  Many of their parents didn’t have one at home either.
• Only two of the students were on Twitter.  Most of them saw Twitter as what the older generation and celebrities used.
• They all, at one time had MySpace accounts.  None of them have logged in to the service in ages.
• Facebook is their primary communications method — but only to their friends. 
• To many of them, the phone company IS their wireless provider. 
• They see getting most of their telecommunications services (data/video) in the future either via wireless or fiber. 
• They are not excited by offerings from their telecommunications providers — AT&T / Comcast / etc.  They feel there is always more marketing behind their offerings than substance.

All in all, the class was a lot of fun, and it gave me insight into how I can best offer MSU Telecom’s own services to the current generation of college students.

So, now all that is out-of-the-way — it’s time to return to my tech and telecom blogging 🙂