LiveCycle Data Services – Channels and Endpoints Explained!

As a follow-up to my LCDS Quick Start Guide, I wanted to offer more in-depth information about using channels and endpoints with your LiveCycle Data Services application. What is a channel and what is an endpoint ultimately? A ‘channel’ is the term used for the client-side code to manage the connection, and the ‘endpoint’ is the term used for the server-side code or configuration that manages the connection. So for a Flex client to communicate with LiveCycle Data Services, a channel must be defined for the client side to communicate with the endpoint on the server-side. The data is sent across the channel in a network-specific format to the endpoint. The endpoint code (Java) reads the data that comes across the channel and determines which service to route that data to. In this case, a service is just another set of code that will be used to process the data sent over the channel and refers to either a remoting service, a data management service, messaging service or an HTTP Proxy service.  The channel and endpoint definition are configured and associated in the services-config.xml file via tags, such as the following:

<channel-definition id="samples-amf" type="mx.messaging.channels.AMFChannel">
        <endpoint url="http://servername:8400/myapp/messagebroker/amf" port="8700"
            type="flex.messaging.endpoints.AMFEndpoint"/>
</channel-definition>

where the ‘id’ attribute refers to the client side channel and ‘type’ refers to the client-side code class type. The associated endpoint element is included as a child of the channel definition to show what server-side endpoint should be used when that client-side channel is used. The ‘url’ attribute on the endpoint must be unique across endpoints, and points to either the MessageBrokerServlet or an NIO based server depending on what implementation you are using. The above example shows the use of the MessageBrokerServlet.

Christophe Coenraets presents on LCDS and BlazeDS often, and has great summary information in those presentations regarding channel usage. I took details from his slides and summarized them in the text below because I think it’s very valuable information for people to know.

Simple Polling

• Near real-time
• May use when you only expect to have 100-150 connections max.
  

<channel-definition id="my-amf">
    <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling"/>
    <polling-enabled>true</polling-enabled>
    <polling-interval-millis>8000</polling-interval-millis>
</channel-definition>

Long polling with piggybacking

• Similar to traditional poll, but if no data available, server “parks” poll request until data becomes available or configured server wait interval elapses.
• Client can be configured to issue next poll immediately following a poll response making this channel configuration feel very “real-time”.

Pros

• HTTP request/response pattern over standard ports. No firewall/proxy/network issue.

Cons

• Overhead of a poll roundtrip for every message when many messages are being pushed
• Servlet API uses blocking IO.  You must define an upper bound for the number of long poll requests parked on the server

Example:
<channel-definition id="my-amf">
    <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling“/>
    <polling-enabled>true</polling-enabled>
    <polling-interval-millis>8000</polling-interval-millis>
    <piggybacking-enabled>true</piggybacking-enabled>
    <wait-interval-millis>60000</wait-interval-millis>
    <client-wait-interval-millis>1</client-wait-interval-millis>
    <max-waiting-poll-requests>200</max-waiting-poll-requests>
</channel-definition>

The following illustration is taken from the Adobe LiveCycle Data Services Developer’s Guide and is helpful in showing the difference between for standard polling versus long polling. The description of it, taken from the dev guide is as follows: “In the standard polling scenario, the client constantly polls the server for new messages even when no messages are yet available. In contrast, in the long polling scenario the poll response thread waits for messages to be available and then returns the messages to the client.”

Streaming AMF/HTTP Streaming

• Because HTTP connections are not duplex, this channel sends a request to “open” a HTTP connection between the server and client, over which the server will write an infinite response of pushed messages.
• Uses separate connection from browser’s connection pool for each send it issues to server.
• Each message is pushed as an HTTP response chunk (HTTP 1.1 Transfer-Encoding: chunked).

Pros

• No polling overhead associated with pushing messages to the client.
• Uses standard HTTP ports. No firewall issue and all requests/responses are HTTP so packet inspecting proxies won’t drop the packets.

Cons

• Holding “open” request on the server and writing an infinite response is not “nice” HTTP behavior. HTTP proxies that buffer responses before forwarding them can effectively swallow the stream.  Assign the channel’s ‘connect-timeout-seconds’ property a value of 2 or 3 to detect this and trigger fallback to the next channel in your ChannelSet.
• No support for HTTP 1.0 clients.
• Servlet API uses blocking IO. You must define a upper bound for the number of streaming connections you allow.

Example:
<channel-definition id="my-streaming-amf">
    <endpoint url="http://localhost:8400/messagebroker/streamingamf"/>
</channel-definition>

RTMP

• Single duplex socket connection to the server.
• If direct connect fails, the Player will attempt a CONNECT tunnel through an HTTP proxy if one is defined by the browser.

Pros

• Single, stateful duplex socket that gives clean, immediate notification when a client is closed. The HTTP-based channels/endpoints generally don’t receive notification of a client going away until the HTTP session on the server times out.
• The player internal fallback to HTTP CONNECT trick to traverse an HTTP proxy if one is configured in the browser gives the same pro as above (technique not available from ActionScript or Javascript).

Cons

• Generally uses a non-standard port so it is often blocked by client firewalls.
• Network components that do stateful packet inspection may also drop RTMP packets, killing the connection.

Example:
<channel-definition id="my-rtmp">
    <endpoint url="rtmp://{server.name}:2037"/>
    <properties>
        <idle-timeout-minutes>20</idle-timeout-minutes>
    </properties>
</channel-definition>

NIO Channels

• NIO stands for Java New Input/Output and is basically a Java socket server completely separate from the servlet-based server-side option.
• The same channels as previously described are available through an embedded NIO Server.
• This option offers much better scalability and no configured upper bound on the number of parked poll requests.
• Because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests.
• NIO endpoints use the Java NIO API to service a large number of client connections in a non-blocking, asynchronous fashion using a worker thread pool, therefore the limitation of the servlet option using one thread is removed and a single thread of an NIO server can service multiple I/O’s.

NIO AMF example

<channel-definition id="my-nio-amf">
    <endpoint url="http://{server.name}:2080/nioamf"/>
    <server ref="my-nio-server"/>
    <properties>
        <polling-enabled>false</polling-enabled>
    </properties>
</channel-definition>

NOTE: BlazeDS only supports the following channel types:

• Polling
• Long polling
• Long polling with piggybacking
• HTTP Streaming

Configuring Channels

Channels can be specified on the client-side via the configuration of the -services compiler option in your project setup, or programmed at runtime. If done at runtime, they are coded into the client MXML or ActionScript directly, therefore no –services compiler option is specified on the project. This also means that the specific endpoint URL does not have to be compiled into the client SWF. In this case it is much more flexible in that you could simply create an XML file with your endpoint URLs in it depending on the environment, and connect with an HTTPService in your client to read them in at initialization. More detailed information regarding defining channels can be found here: http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcoverview_4.html

Below are screen shots to show you how to set up your LCDS project with the compiler options etc:

However, as noted in the previous paragraph, you can completely skip all the above project setup and define your channels for runtime use. An example of this is shown below:

<mx:ChannelSet id="channelSet">
    <mx:RTMPChannel id="rtmpChannel" url="rtmp://tourdeflex.adobe.com:2037"/>
</mx:ChannelSet>

You can also code it in ActionScript if desired, such as the following:

var cs = new ChannelSet();
cs.addChannel(new RTMPChannel("my-rtmp", "rtmp://localhost:2035"));
cs.addChannel(new AMFChannel("my-polling-amf","http://servername:8400/app/messagebroker/amfpolling"));

You then use that defined ChannelSet on your DataService object as follows:

<mx:DataService id="ds" destination="product2" channelSet="{channelSet}"/>

This can be done for any of the LiveCycle Data Services objects you are working with, including RemoteObject, Producer/Consumer objects for Messaging etc…

An example of this with remoting is below:

<mx:ChannelSet id="channelSet">
   <mx:AMFChannel id="amfChannel" url="http://tourdeflex.adobe.com:8080/lcds-samples/messagebroker/amf" />
</mx:ChannelSet>
<mx:RemoteObject id="myService" destination="userService" channelSet="{channelSet}" result="onResult(event)" fault="onFault(event)"/>

Many other examples of this can be found in the Flex Data Access section of Tour de Flex.

General Guidelines

So when to use which channel? Below are some general guidelines. For more detailed information, see the LiveCycle Data Services Developer’s Guide:

• Use AMF channels for Remoting
• The order of preference in choosing channels in general, particularly based on latency (other then when using Remoting):
  • RTMP
  • Streaming AMF (1st choice for BlazeDS since RTMP is not supported there)
  • Long Polling
  • Polling

  Important Note: you can code multiple channels at runtime and LCDS will use them in order of declaration. If there is a problem, such as a firewall issue with RTMP, then the next channel in the code will be tried. It is a good practice to add a regular polling channel as the last channel in order since it will always work as a fallback. An example of how this would look in the code is shown below:

      <mx:ChannelSet id="channelSet">
         <!-- RTMP channel -->
         <mx:RTMPChannel id="rtmp" url="rtmp://tourdeflex.adobe.com:2037"/>
         <!-- Long Polling Channel -->
         <mx:AMFChannel url="http://tourdeflex.adobe.com:8080/lcds-samples/messagebroker/amflongpolling"/>
         <!-- Regular polling channel -->
         <mx:AMFChannel url="http://tourdeflex.adobe.com:8080/lcds-samples/messagebroker/amfpolling"/>
     </mx:ChannelSet>

• If you need scalability and are using LCDS (versus BlazeDS), opt for the NIO based channels. Note that in this case though you will not have access to any HttpSession data etc since it is not servlet-based.
• Use AMF channels over HTTP-based channels since the data is passed in binary format versus text/XML and will be much faster.
• Choose Long-polling or streaming over simple polling.
• Damon Cooper has an excellent summary of the various channels with more detail on when to use which here, definitely recommend reading through this post.

And lastly… if you’re like me and really need to understand what is happening under the covers with all of this rather than assuming the magical black box, I recommend reading at least this one page of the Adobe LiveDocs for LCDS. It was eye-opening for me!

LiveCycle Data Services (LCDS) – Quick Start

With the recent work I’ve been doing to add LiveCycle Data Services samples to the Flex Data Access category for Tour de Flex, I felt the need to add some additional helper information to assist people in getting started using it quickly. I’m including some basic information on how to configure the client (using Flex 3) and server side, and provide links to more detailed information as needed. This post is not intended to explain all things Data Services, but I am hoping to provide some overview information for those just beginning to take a look at it, as well as some helpful info and links that might be needed to get on board fast!

So… you want to use Data Services, where do you begin? First I suggest you think about and try to answer the following questions:

• What kind of data access do I need or what does the service need to do?
• What platform/language do I need to use (Java, .NET, Cold Fusion etc)?
• Will there be a database needed, and if so how complex will the table structure be?
• Will there be any other layers involved, such as Hibernate for instance?

LiveCycle Data Services (LCDS) – Feature Overview

First, a quick overview of the different features provided by LCDS…

RPC Services
Making calls to a remote service or operation is super easy using LCDS. There are various ways to achieve this depending on protocol you want to use etc… they include an HTTP call (using the HTTPService class),  a SOAP call (using the WebService class) or using AMF via Remoting (using the RemoteObject class). I strongly encourage using Remoting where possible due to the significant gains in response time. James Ward has a fantastic and powerful example of different response times for different types of invocations here. The best way to use this app is to select the ‘Census – Guide Me’ option from the drop down list and go through each type of call to get the full effect of response times.

Data Management
If you need to persist and manage data between clients, LiveCycleData Service’s Data Management is definitely the way to go. Using the DataService object, you are immediately given amazing power over your data, including CRUD operations (Create, Read, Update, Delete) with conflict management handling options, auto-commit of data, persisting to a local cache when offline (in an AIR app), and so much more. And what’s even better is the little bit of code needed to make all of this happen! It is still totally amazing to me how powerful yet easy it can be compared to anything I’ve done in the past. The Tour de Flex samples for Data Management are the best resource to check out to get started in this area quickly.

Messaging
The most common use of messaging is in a one-to-many relationship, when there is information that should be broadcast real-time to many at once. This is often called publish-subscribe messaging, or topic-based messaging. The topic is the shared item that a ‘producer’ (the one sending the message) and the ‘consumer’ (the one receiving the message) both subscribe to. A general but explanatory example often used for publish-subscribe messaging is that of subscribing to a stock ticker topic that is broadcasting all of the stock prices real-time to its subscribers. Another type of messaging supported by LCDS is point-to-point messaging, which involves a one-to-one relationship. All of this is described in-depth in the LCDS Developer documentation for those looking for more information. Adobe offers the open-source BlazeDS that offers most of the same Messaging features as well. More info on BlazeDS is given later in this post.

What next?

So once you decide what you need to do and which LCDS features you need to use, I recommend going to the Flex Data Access category in Tour de Flex and locating a sample for the specific area of LCDS you’re planning on implementing. If your solution involves  server side code, for instance if you’re doing Remoting or Data Management, the following steps detail what you should do next to configure the server side:

Server-side Configuration Steps
1.    Create your project in your favorite IDE (I use Eclipse) and be sure to include the following libraries (found in the LCDS or BlazeDS install packages):

a.   acrobat-core.jar
b.   acrobat-core-charset.jar
c.   backport-util-concurrent.jar
d.   cfdataservicesadapter.jar – (Cold Fusion only)
e.   cfgatewayadapter.jar (Cold Fusion only)
f.    commons-codec-1.3.jar
g.   commons-httpclient-3.0.1.jar
h.   commons-logging.jar
i.    concurrent.jar
j.    flex-acrobat
k.   flex-messaging-common.jar
l.    flex-messaging-core.jar
m.  flex-messaging-data.jar
n.   flex-messaging-data-req.jar
o.   flex-messaging-opt.jar
p.   flex-messaging-proxy.jar
q.   flex-messaging-remoting.jar

2.    Create a destination in the appropriate XML configuration file (remoting-config.xml, data-management-config.xml etc.)  The next section has more information about configuration files and LCDS.

3.    Point the destination to the appropriate server side ‘assembler’, (if using Data Management) or class you are using to perform the server side RPC operations and set required parameters on that destination.

Note:  An assembler is a general term for the server side code that will be used to process your interactions with your data. There are a few different types of assemblers built into LCES, or you can extend their AbstractAssembler class to create your own custom class. Examples of each are part of the recent additions to Tour de Flex, and more information about the Java classes used can be found here

4.    Copy your compiled class files for your service or assembler into the WEB-INF/classes directory. Ensure any other configuration files needed for things like a Hibernate integration etc are added to their appropriate server location as well. Note: Tour de Flex has more information regarding configuring LCDS with Hibernate.

For a detailed explanation of the server side configuration needed for your web application that uses LCDS, see here.

Client-side Configuration Steps
1.    Create your Flex project. There are actually a couple ways you can go about doing this. The conventional way will include your required libraries in the build path and set up your compiler options as needed (adding the –services option) so you are ready to use the various LCDS components in your application. However, I personally find the non-conventional way along with using runtime configuration of channels easier and feel that I have more control over it that way.

a.    Conventional way: this link sums it up
b.    Non-conventional way: create a basic Flex project (no server specified) and add the necessary SWC’s to the included libraries for the build path (fds.swc, playerfds.swc and the locale folder found in your webapps WEB-INF/flex/libs folder). Note: these SWC’s are also shipped with LCDS

As I said above, using this option requires you to use runtime channel definitions and set them on your LCDS components, but also offers you full control over which channel is used when, and allows you to easily switch where one is pointing (for instance localhost versus another server destination). Also important to note, configuring this way does not require the services configuration to be compiled into your SWF. An example of configuring channels at runtime is shown below, and used in all of the Tour de Flex Data Access samples:

    <mx:ChannelSet id="channelSet">

         <mx:RTMPChannel id="rtmpChannel" url="rtmp://tourdeflex.adobe.com:2037"/>

    </mx:ChannelSet>

        <mx:DataService id="ds" destination="hibernate-contact" autoCommit="false" channelSet="{channelSet}" fault="onFault(event)"/>

Config file C-R-A-Z-Y! Why are there so many configuration files and what are they used for?

When I first started using LCDS, it seemed a little confusing to me that there were so many different XML files for configuring things, I was just accustomed to having to edit one main config file for many of the things I had worked on, so to have to touch all the different ones for the different services seemed a bit overwhelming at first.

Now that I have worked with it for awhile, I realize there really is one main configuration file called services-config.xml, and it just includes the rest of the config files for the specific services (remoting-config.xml, data-management-config.xml, messaging-config.xml etc).  The services-config file defines channels, logging and security settings, and then has the includes for the rest of the configuration files.  You would typically not specify application level destinations here, but would put them in the appropriate *-config.xml file based on the guidelines below:

remoting-config.xml – set up your destinations used for remoting here (ie: RemoteObject from your Flex client)

data-management-config.xml – set up your destinations for Data Management applications here (ie: those referred to from the DataService object in your Flex client).

messaging-config.xml – set up your destinations for messaging applications here (ie: those referred to from  Producer/Consumer objects from your Flex client).

proxy-config.xml – defines Proxy Service destinations for working with web services and HTTP services (REST services).

Channel Confusion! Which, when and why?

Channels are used in LCDS to provide the transport of your data from end to end over a specified protocol (HTTP, AMF, RTMP etc).  They specify an endpoint for your data to be sent to as well as handle how it should get there. Channels are defined in the services-config.xml file, and there are many different types that can be defined for them. It can be very confusing to try to read the documentation given and figure out what you actually need. Damon Cooper has a fantastic and detailed summary of the different channels depending on what you might need located here.

BlazeDS

BlazeDS is the remoting and HTTP-based messaging technology Adobe is contributing to the community under LGPL v3. BlazeDS offers publication of the Action Message Format (AMF3) binary data protocol specification. Certified builds, warranty protection and enterprise support subscriptions are available. A comparison of the features included in LCDS versus BlazeDS can be found here. There’s also a full test drive available in BlazeDS you can use to check out the included features.

References

The LCDS Gurus

Christophe Coenraets – site includes TONS of cool samples using more advanced LCDS features and information. Christophe has a way of explaining the more complex features in a manner that seems much less intimidating and always supplies source code so you can see exactly what he did to make something happen.
Sujit Reddy G - again lots of great info on LCDS, BlazeDS and more, but some particularly helpful info on using Flash Builder 4 with Data Access.
Dr Flex – a very cleverly written site packed with some great and useful information on a variety of topics.
Cornel Creanga -  former J2EE Software Developer turned Adobe Evangelist with a lot of useful information and samples to check out.
Greg Wilson – great blogger and Adobe Evangelist with a bunch of LCDS, LiveCycle and Tour de Flex sample information.
LCDS Livedocs/Developer’s Guide – in-depth information related to Data Services, includes all the details for the subject matter covered in this post.

LiveCycle Data Services – included samples – included in LCDS is a great set of samples that show off the different features. Some of these were already the basis of the samples added recently to Tour de Flex, but it is in you best interest to start by installing LCDS, running the samples locally to see how they work, and then checking out the included source code. For instance, when running locally your path to the LCDS samples webapp might be: http://localhost:8080/lcds-samples/ depending on your configuration. Don’t miss the ‘Take the Test Drive’ option as well… that is actually the best place to start as some of the other samples on the main samples page become a bit more advanced.

Launch an AIR application from within another AIR application

Have you ever needed to launch another AIR application from within an AIR application? I have found myself wondering how this would be done exactly, and noticed that Rich Tretola just did a great blog post this morning on two ways to do it, including source code. He presented the solutions at 360 | Flex recently and was kind enough to share it on his blog. He shows one solution using an undocumented AIR class called ProductManager, and another of how to load from the Browser API air.swf in the event that you are not sure the other AIR app is installed on the user’s machine. Check it out if you find yourself in need of this functionality in the future!

Tour de LiveCycle!

If you haven’t heard the news yet, Tour de LiveCycle was released this week! It is based on the same architecture as used in Tour de Flex and is jam-packed with useful information on how to use this very complex but powerful product from Adobe. LiveCycle ES is near and dear to me as I have worked with it and the wonderful people that continue to develop and support it for many years now.  I was fortunate enough to work with the development team that wrote the original workflow engine that was eventually purchased by Adobe back in 2004, and have seen it evolve so much over the years. I have to say I’m super excited about this application because I feel it was so necessary and will be such a huge help to so many.  I know that many people have no clue what LiveCycle ES is all about, what you would do with it etc, but now is your chance to find out! It is absolutely worth your time to install the AIR app and find out more about it. This app is not only useful for those who are discovering LiveCycle, but will also serve as an awesome reference to those who are using it in their day to day jobs. I highly recommend checking this out, yet another great application from Adobe…

LiveCycle Data Services (LCDS) Goodies added to Tour de Flex!

Recently I’ve been given the opportunity to work on adding LiveCycle Data Services (LCDS) samples to Tour de Flex in an effort to help ‘de-mystify’ it for developers. In my opinion it seems that many find it a bit intimidating, at least anything beyond using HTTPService, WebService or RemoteObject anyway… I think much of this is due to the lack of information on how to use it exactly (other than the super helpful coenraets.org), the confusion about configuration, (since there are so many different XML files involved) and developers not knowing exactly how to set it up with their projects to get started with it quickly and not painfully ! I am a great example of this myself because I remember full-well the experience I had when I needed to use it on my first project and know the frustrations that could have been avoided given the right knowledge!

The overall goal of these samples is to help get developers started with showing off the many different features available in a simplified manner, along with explanatory text, source code (including server side), XML configuration file entries etc. I was involved in numerous discussions regarding these samples and how to best present them with Adobe Evangelists Greg Wilson, Christophe Coenraets and James Ward, and they had some really great ideas that I believe will be a huge benefit to the community of developers of all types. Some samples have already been added thus far (under top-level category Flex Data Access), and notes about them are listed in the QuickStart page that’s shown when you open Tour de Flex initially (on both the AIR and web versions). However, there are more to come, as well as some samples that highlight using Flex and LiveCycle Data Services with a back-end other than Java (PHP, ColdFusion, .NET, Ruby etc). As part of this goal, we’re hoping to solicit samples from other server side software companies showing how to use their APIs, so look for those in the near future. I’m also about to release a sample that shows how to work with Hibernate on the back-end with your Flex client using data services.

In addition to the samples, I’ve also started writing up some summary notes to supplement them and explain some things about LCDS overall. I’m hoping these notes will help people get started quickly since they are coming from a fellow developer’s point of view who’s sorta been there, done that and will hopefully simplify things for people beyond trying to gather it from reading the very large LCDS developer’s guide ! That post will be coming in the next week as well so please check back again soon!

Attest 1.8.5 – Additional Flex 3/AIR mock exams released!

Tonight we released another update to Attest based on some user feedback received from our previous poll. Version 1.8.5 includes the addition of a bunch of questions and exams as requested, and some you may find a bit more challenging. We also covered some additional material with these questions, so people should feel that much more prepared for the exam. It also includes a new randomization feature in the order of the questions that make it harder to memorize a pattern of answers. Dave and I are still hard at work on some other super cool features for version 2.0 (in addition to our regular work!) but knew that people were anxious to get their hands on more test questions, so we delivered Grab the updated version here!

Attest 2.0 (Flex 3/AIR Certification Practice Exams) Feature Poll

Since releasing Attest late March, Dave Flatley from PXL Designs, Inc and I have gotten some awesome feedback from the community including how you’re using it, features to add, change etc. We had some ideas of our own as well and decided it might be a good idea to come to the community and take a vote for the most desired features for Attest 2.0. Below is a poll that we came up with to summarize some major features we’re looking at for the next version of Attest. Take a moment and let us know what you think! A quick summary of the options follows. If you have other ideas not listed that you feel are more important, select Other and leave one of us a comment.

• More Questions! More, tougher questions and exams, all categories – this option is pretty much what it sounds like, MORE, MORE, MORE, questions/answers/feedback. We realize the more questions you get right, the higher your confidence, and the less likely for memorizing the content. We are aware that this is a big one and are already working on more.
• Learning/Practice Mode – un-timed test with answer and resource links with questions – this one has come up a couple of times… this entails adding a whole new section to Attest that allows you to start from scratch study-wise and learn what you need for the exam without ruining your scores on the testing section from having seen the questions during studying.
• Community Area – test yourself against the guru’s, submit your own questions, feedback – this might be the most fun option of them all… it entails another new area in Attest that would include a place for the community to submit questions/answers/feedback for review to be added into Attest. And the other neat thing here is the option to see how your test results stacked up against those of well-known Flex/AIR guru’s .
• Web Version – self-explanatory
• UI enhancements – color changes, progress bar on exams, user interaction changes – ok, so we know Attest isn’t the most beautiful app you’ve ever used, but we do work on this in addition to our day jobs and had an interest in getting something out sooner than later versus spend the additional time on the UI. HOWEVER, that being said, we realize there are some things we could change and enhance, and understand the value of User Experience, so vote for this option if you feel strongly about this!

So please take a second and vote! We value your opinions and appreciate your help in making Attest a success!

The Making of an Eclipse Plug-in – Part 1

I recently had the opportunity to write my first Eclipse plug-in as part of Tour de Flex for Adobe. We had a pretty short deadline for the project and I was a bit hesitant about entering the world of SWT and JFace without previous experience. I did have a good amount of experience coding in Java Swing/AWT previously, but it had been awhile and I had been coding UI’s in Flex/AIR with Java on the server side most recently. Moving back to this “widget-world” was certainly different! I discovered very quickly how spoiled I had been in the Flex/AIR world I ran into a few kinks along the way in my development that I believe could have easily been avoided and saved me oodles of time had I been able to find some quick information on the web. So now that I have been through the painful task of figuring out how to code, build, package and test an Eclipse plug-in, I decided to write a series of posts to explain the steps I took in creating my plug-in as a sort of quick reference and cut to the chase, as I found myself sifting through a lot of information to find the nuggets I needed.

Before I begin, there are two books I found particularly useful in tackling this project. They are:

Eclipse Building Commercial-Quality Plug-ins
The Definitive Guide to SWT and JFace

The View

An Eclipse ‘View’ is basically any of the UI tabs within your Eclipse environment, so for instance your Project Explorer, the Console, or the Problems window, that you can drag around to customize your environment. My Tour de Flex plug-in was all contained within one view, so the main things I needed to figure out were all the events and behaviors around showing, closing and sizing a custom Eclipse View panel. A screenshot of my Tour de Flex plug-in view is shown below.

And by the way, if you don’t know about Tour de Flex or what the plug-in does, I HIGHLY recommend checking it out! Tour de Flex is a great tool for developers, full of code samples that showcase the language and how to use it. The plug-in can run in either FlexBuilder or Eclipse, and allows you to search code samples provided by Tour de Flex. Double-clicking on a search result will open the Tour de Flex AIR app right to that particular code sample where you can then find out more info or copy/paste code right into your IDE. Instructions for downloading the Tour de Flex plug-in and more information about this useful application can be found here.

Coding a Sample View

Fortunately Eclipse makes it pretty easy to get started in building a plug-in via a wizard. Using this wizard ensures the necessary base packages needed for a view are included, and includes some sample code to help get you started. To use this in Eclipse, click File | New | Project, and then find the Plug-in Development folder and select ‘Plug-in Project’ from the drop-down menu.

You will then be prompted with the following screen, where you will enter the project name and location desired and leave the default selections unless you need to change the required Eclipse base version etc and hit ‘Next’.

The next button will take you to the ‘Plug-in Content’ dialog, where you will stick to defaults once again (except name changes as desired), and leave the default boxes checked. From here you will again click the ‘Next’ button.

On the following screen select the ‘Plug-in with a view’ option and go through the resulting panels indicating any names changes you might want for your plug-in, otherwise sticking with defaults. For the viewer type, you have two options which apply to the sample code that is contained within your view. You can choose a Table View or Tree View, and this will depend on your own personal view needs. In my case I used the table view and modified it as needed. Lastly hit ‘Finish’ and you will see a new project created with various files and folders needed for your plug-in. Screen shots of those wizard dialogs are shown below for my sample:

To see what the sample plug-in you just created looks like, or to test any plug-in for that matter, you can right click on the project in the Package Explorer and select the ‘Run as… Eclipse Application’. This will actually open a new running instance of Eclipse with your plug-in activated in that instance. Another way to test/run it is from the ‘Overview’ page of the plug-in that was created, under the ‘Testing’ section, via the option that says ‘Launch an Eclipse Application’. This page is your entry into all of your plug-in settings, and you will see tabs at the bottom that allow you to flip through each page of settings. More about these settings and how to use them will be explained in Part 2 of this series.

So now that we know how to launch an Eclipse application for testing our plug-in, we need to go into that instance to find our new view. Once in the test Eclipse instance, go to the ‘Window’ menu and find the ‘Show View’ option. This will bring up a list of all the view categories, and you should now see your new category in the list, and under it your sample view. Once you find your newly created view, select it and hit the ‘OK’ button.

The new sample view will be opened immediately for you to see with a basic table as shown in the screenshot below.

Congratulations! You have just learned how to create your first basic plug-in! In Part 2 I will take a deeper dive into the files that were generated as a result of the above, discuss some caveats to watch out for during coding, and also take a closer look at the plug-in settings tabs.

My Flex/AIR ACE Certification Experience

A couple of months ago I started considering taking my Flex 3/AIR Certification. I solicited feedback in a previous blog post and got some really great comments regarding the value of getting the certification. I wanted to write up a quick post about the experience myself and my overall feelings on the topic for the many people out there considering it.

I know there are many opinions on taking the test and some believe it is just a matter of purely memorizing the Flex 3/AIR APIs and not testing real programmer knowledge. After taking the test (and passing, woohoo!!) I can say I do not believe this to be the case. While there certainly are questions revolving around API properties, methods etc that could essentially be memorized, there were also some great questions that test your knowledge of object-oriented programming and best practices, and general use of Flex/AIR that would be difficult to answer without prior practical programming experience in my opinion.

As far as making it worthwhile to study and get your certification, I absolutely believe it is worth it! I have worked with Flex and AIR for a couple of years now and still found myself discovering a lot of things I did not know previously in the process of studying. I believe it also has the benefit of adding that extra bit of confidence to know that you are aware of the breadth of possibilities available in the API’s for future projects you may find yourself working on. With all of this, I believe getting certified can only help you be more successful in your future work.

As far as studying for the test, I feel the Attest software is one of the best tools you can use to prepare, which is why I offered to help get the latest version released. It really helps to point out the areas you need to study further, and makes it easy to quickly locate and read that piece of information via the feedback at the end of each mock exam and links to the LiveDocs.  Also, just a tip, the LiveDocs are the most important thing to know/study for this exam, and in-depth. The test is tough and randomly pulls from content throughout those docs, and is changed up for each person so you never know what you’re going to get.  Dave from PXL Designs and I are currently in the process of adding more challenging questions to Attest so it can only help further.

There’s my two cents on the subject. So download Attest, get certified and let me know if you agree!

Tour de Flex – Web Version Released!

Tour de Flex - Web Version

Tour de Flex for the Web was released today! It’s hosted on the Adobe Devnet site where we also now keep the Tour de Flex AIR app download, and looks almost identical to the AIR version, minus the AIR-only samples for obvious reasons.

The web version contains deep linking integrated into it so it’s now very easy to bookmark samples for later reference, or to email a sample to a co-worker etc… This version is also a great option for those who are new to Flex or might want to explore it, but are not ready to download the full AIR application. When they are ready to download it, all they have to do is hit the Install button at the top of the page to get it.

I had some unique challenges in creating the web version, since we use HTML links to supply our content (in the form of SWF or HTML) for all of our tabs within the illustrations and documents, and obviously could not use the handy dandy HTML component as our AIR app used. Christophe Coenraets had been down this path before and suggested using iFrames to hold the content in the tabs, and advised on how he had done something similar, so that is the path we chose. The final result took a little bit of trickery to make the iFrames behave with the resizing of the browser window, popping up and hiding of other windows etc, due to the z-order of the iFrame always taking precedence over the Flex component, but ultimately worked! I plan to write another post about how this was done in case it may help others who need to build something like this in the future… so check back soon!

Also, be sure to check out Greg Wilson’s blog for the rest of the info on the Tour de Flex 1.2 AIR app updates and more!