I have blogged about the new data-centric features in Flash Builder 4 here and here. One question people often ask me is: “Can I use this feature if I use a Framework (Cairngorm, Mate, Parsley, Spring ActionScript, Swiz, etc)?”

The answer is yes: The classes generated by Flash Builder (Value Objects and Service Stubs) are standard building blocks that are part of most RIA design patterns, regardless of whether or not you use a framework.

The way you leverage these classes in your application may differ slightly depending on the framework you are using. For example, each framework may have a different approach to configure service endpoints or to instantiate generated service stubs.

To demonstrate this, I built a version of my “Contacts” application (also known as InSync) using the Flash Builder 4 data-centric features and the Parsley Framework.

Configuring Service Endpoints

By default, an application built using a BlazeDS or LCDS project determines its service endpoints using a combination of assumptions made at runtime and hardcoded references baked into the swf at compile time. Read my Externalizing Service Configuration blog post for more information on this topic. The bottom line is that this default behavior is insufficient for any application other than a simple demo: you want endpoints to be fully configurable so that you can move services around without having to recompile your application.

Using Parsley, I inject the service endpoint configuration (in the form of a ChannelSet) in the generated service stubs as follows:

public class ContactService extends _Super_ContactService
{
	[Inject]
	override public function set channelSet(cs:ChannelSet):void
	{
		super.channelSet = cs;
	}
}

Note that I added this code in ContactService.as and not _Super_ContactService.as. Contrary to _Super_ContactService.as, ContactService.as will never be regenerated and is therefore the right place to add your custom code.

The injected ChannelSet is defined in my own channels-config.xml configuration file as follows:

<object type="mx.messaging.ChannelSet">
 	<property name="channels">
    		<array>
		    	<object type="mx.messaging.channels.AMFChannel">
		        	<property name="uri" value="http://localhost:8400/testdrive/messagebroker/amf"/>
		        </object>
	        </array>
	</property>
</object>

Note: Unlike the BlazeDS/LCDS services-config.xml file, channels-config.xml is read at runtime.

Because the ChannelSet is configured in an xml file, you can easily change the channel’s endpoint URI without recompiling the application. You could also add failoverURIs to this channel, or add completely new fall back channels to the ChannelSet.

Instantiating Service Stubs

As we already alluded to, Parsley is a dependency injection framework: Instead of letting a component instantiate its dependencies, those dependencies are injected in the component at runtime. For example, in ContactForm, instead of instantiating a ContactService as follows:

<services:ContactService/>

… I simply defined a contactService reference variable that I annotated with [Inject] to let Parsley inject a ContactService instance a runtime.

[Inject]
public var contactService:ContactService

The instance of ContactService that Parsley injects is defined in Config.mxml and has itself been injected with a ChannelSet. Object configuration in Parsley is very flexible. In this application I combine the xml and mxml configuration options. I use the xml configuration option for the things I don’t want to hardcode in my application, and the mxml configuration for traditional object instantiation and configuration.

Note: Parsley doesn’t force you to use any specific design pattern. For simplicity in this sample application, I inject a service directly into the view. You can of course use other patterns (like the Presentation Model) to achieve a greater level of abstraction. The Dependency Injection and Messaging infrastructure of Parsley will make the implementation of these patterns easier.

Installation Instructions

1. Download and install BlazeDS 4
2. Make a copy the blazeds web application in blazeds/tomcat/webapps, and call the new web application contacts
3. Download contacts.zip, and unzip it anywhere on your file system.
4. Overlay contacts/webapps/contacts (from contacts.zip) on top of blazeds/webapps/contacts
5. Start the server
6. Open a Command Window or Shell, navigate to /blazeds/tomcat/bin, and start Tomcat (for instance: catalina run).
7. Open a browser and access http://localhost:8400/contacts/ContactsParsley/ContactsParsley.html.

Note: The web application also include a plain (framework-less) version of the application available at this URL: http://localhost:8400/contacts/Contacts/Contacts.html

Importing the projects in Flash Builder 4

1. In Flash Builder 4, click File > Import > General > Existing Projects into Workspace.
2. Specify contacts/projects as the root directory and click finish.
3. Explore the projects: Contacts is the Flex project for the plain version of the application, ContactsParsley is the version discussed in this article, and java-testdrive is the Java project for the server-side classes.

You can watch it in the player below, however I recommend you click here to watch it in HD (go full screen for a better viewing experience. Also make sure HD is on).

A few things I’m not mentioning in the demo:

• Value objects and service stubs are automatically generated based on the model
• Data persistence occurs through JPA/Hibernate, but you don’t have to know that if you just want it to work
• Code generation of form is template-based (you can modify the existing template or create new ones)

Greg Wilson and Damien Mandrioli are also blogging about the new Tour de Flex real time dashboard today. Greg is the inspiration behind everything “Tour de Flex”, including the idea of the dashboard. He has the story behind the genesis of this project on his blog. Damien (from IBM/ILOG) did a fantastic job at building the client-side of the dashboard using the very cool ILOG Elixir components, and he walks you through the details on his blog.

My contribution to the project is the “real-time messaging” infrastructure. I provide the details below.

First the overall workflow…

The reason we are combining PHP and Java in this workflow is mostly historical. In the initial version of Tour de Flex, there was no Java involved: Greg was persisting loaded samples data (sample id and timestamp) directly from his PHP page. We later added LiveCycle Data Services to the picture to support the data push requirement of the dashboard, and we took the opportunity to move some code (such as the database persistence) from PHP to Java. Note that we are using LCDS for the performance and scalability of its high-end channels, but the application could also be deployed on BlazeDS.

A more straightforward architecture would be for the client to communicate directly with LCDS. For example, the client could invoke a remote object that would directly publish the loaded sample data (sample id and geolocation of the client) to the message destination. Alternatively, the client could use a Producer object to directly publish the message to the destination. Because some logic (such as geolocating the IP address and persisting the data) has to be executed at the server-side before routing the messages to the subscribed clients, you would have to write a custom message adapter if you used this approach.

We will probably streamline the workflow with one of these two approaches in the future, but in the meantime here is the source code for the servlet (logging and non-essential code removed for brevity):

package com.adobe.tdf;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.maxmind.geoip.Location;
import com.maxmind.geoip.LookupService;

import flex.messaging.MessageBroker;
import flex.messaging.messages.AsyncMessage;
import flex.messaging.util.UUIDUtils;

public class TDFServlet extends HttpServlet {

	// Unique clientID for the message service
	private String clientID = UUIDUtils.createUUID();

	// The geocoding service
	protected LookupService lookupService;

	// A DAO to store sample requests in a database
	protected SampleRequestDAO dao = new SampleRequestDAO();

	// The LCDS message broker
	protected MessageBroker messageBroker;

	// The LCDS messaging destination where real time sample requests information is pushed
	protected String destination; 

	public void init() throws ServletException {

		ServletConfig config = getServletConfig();
		destination = config.getInitParameter("messaging.destination.name");
		String path = config.getInitParameter("geocoding.database.path");
		try {
			// Load the geocoding database in init() to make sure we load it only once
			lookupService = new LookupService(path, LookupService.GEOIP_MEMORY_CACHE);
		} catch (IOException e) {
			// We swallow the exception here. If the database is not available, the feed
			// will still work but won't provide the location info.
		}
	}

	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {

		if (messageBroker == null)
		{
			messageBroker = MessageBroker.getMessageBroker(null);
		}

		SampleRequest sampleRequest = new SampleRequest();

		try {
			sampleRequest.setSampleId(Integer.parseInt(request.getParameter("sampleId")));
		} catch (Exception e) {
			String message = "A valid sampleId is required to process this request";
			throw new RuntimeException(message);
		}

		sampleRequest.setTimestamp(new Date());

		String ipAddress = request.getParameter("ipAddress");

		// Geolocate the IP address and add the info to the message
		if (lookupService != null && ipAddress != null)
		{
	                Location location = lookupService.getLocation(ipAddress);
			if (location != null)
			{
				sampleRequest.setLatitude(location.latitude);
				sampleRequest.setLongitude(location.longitude);
				sampleRequest.setCountry(location.countryCode);
				sampleRequest.setCity(location.city);
			}
		}

		try {
			dao.create(sampleRequest, ipAddress);
		} catch (RuntimeException e) {

		}

		String subtopic = request.getParameter("subtopic");
		if (subtopic == null) subtopic = "flex";

		// Publish the message to specified destination and subtopic.
		AsyncMessage msg = new AsyncMessage();
		msg.setDestination(destination);
		msg.setHeader("DSSubtopic", subtopic);
		msg.setClientId(clientID);
		msg.setMessageId(UUIDUtils.createUUID());
		msg.setTimestamp(System.currentTimeMillis());
		msg.setBody(sampleRequest);
		messageBroker.routeMessageToService(msg, null);

		PrintWriter out = response.getWriter();
	        out.println("<html><body>ok</body></html>");

	}

}

The servlet is responsible for three things:

1. Geolocate the IP address of the client requesting the sample. We currently use the MaxMind Geolocation API. The API is straightforward and the results seem pretty accurate.
2. Save the information about the loaded sample in a database. We keep track of historical data to be able to support future data visualization projects.
3. Publish the data about the loaded sample to a message destination. The servlet uses the Message Service Java API to directly push messages to the Flex destination (lines 97 to 104). Note that the same API exists for ColdFusion, so CF developers could use a CF page instead of this servlet to push messages to the client.

Channels

The messaging destination is set up to support different communication channels: RTMP, long polling, and regular polling. The client-side developer can decide which channel to use to communicate with the server. For example, if you wanted to use RTMP as the primary channel, fall back to long polling if the RTMP connection fails, and fall back to regular polling if the long polling connection fails you could set up your client-side ChannelSet as follows:

<mx:ChannelSet id="channelSet">
	<mx:RTMPChannel id="rtmp" url="rtmp://hostname:2037"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amflongpolling"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amfpolling"/>
</mx:ChannelSet>

SpringSource just released the RC1 build for the Spring / BlazeDS integration project. The key new feature in RC1 is the integration of the BlazeDS Message Service.

I updated my Spring BlazeDS Integration Test Drive to showcase the messaging integration.

In addition to Remoting and Security samples, the Test Drive now includes the following Messaging samples:

• Chat: Messaging basics
• Simple Data Push: A simple data push example
• Traderdesktop: A more sophisticated data push example showing how to use subtopics
• JMS Chat: A chat application using a JMS topic and exchanging messages with a Swing-based client
• Collaboration: An example showing how to use messaging to remotely drive another client’s application

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

As always, I’d love to hear your feedback and your ideas to improve this Test Drive.

I will probably have another version next week with a couple of additional samples and more documentation for the Message Service, but I already wanted to make this version available to allow you to experiment RC1 samples.

Christophe

The question often arises after an application stops working when you move it to another server. This is one of the most frequently asked questions related to BlazeDS and LCDS, so I figured I would answer it here. There is nothing really new in this post, but hopefully this will be a good point of reference.

When you create a new BlazeDS or LCDS project in Flex Builder, you are typically told to select J2EE as the “Application Server Type” and then check “use remote object access service”. This adds a compiler argument pointing to the location of your services-config.xml. If you check the Flex Compiler properties of your Flex Builder project, you’ll see something like this:

-services “c:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml”

When you then compile your application, the required values of services-config.xml are baked into the SWF. In other words, services-config.xml is read at compile time and not at runtime as you may have thought intuitively. To abstract things a little bit, you can use tokens such as {server.name}, {server.port}, and {context.root} in services-config.xml. However, {context.root} is still substituted at compile time, while {server.name} and {server.port} are replaced at runtime using the server name and port number of the server the SWF was loaded from (which is why you can’t use these tokens for AIR applications).

Fortunately, the Flex SDK provides an API that allows you to configure your channels at runtime and entirely externalize your services configuration from your code (you definitely don’t want to recompile your application when you move it to another server). At a high level, it works like this:

var channelSet:ChannelSet = new ChannelSet();
var channel:AMFChannel = new AMFChannel("my-amf", "http://localhost:8400/lcds-samples/messagebroker/amf");
channelSet.addChannel(channel);
remoteObject.channelSet = channelSet;

This is still not what we want because the endpoint URL is still hardcoded in the application. At least in this case it’s obvious that it is. So, the last step is to pass that endpoint URL value at runtime. There are a number of ways you can pass values to a SWF at runtime (flashvars, page parameters, etc). The approach I usually use is to read a configuration file using HTTPService at application startup. That configuration file includes (among other things) the information I need to programmatically create my channel set at runtime. Here is a basic implementation:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	applicationComplete="configSrv.send()">

	<mx:Script>
	<![CDATA[

	import mx.controls.Alert;
	import mx.messaging.channels.AMFChannel;
	import mx.messaging.ChannelSet;
	import mx.rpc.events.ResultEvent;

	private var channelSet:ChannelSet;

	private function configResultHandler(event:ResultEvent):void
	{
		var xml:XML = event.result as XML;
		var amfEndpoint:String = "" + xml..channel.(@id=="amf").@endpoint;
		if (amfEndpoint == "")
		{
			Alert.show("amf channel not configured", "Error");
		}
		else
		{
			channelSet = new ChannelSet();
			var channel:AMFChannel = new AMFChannel("my-amf", amfEndpoint);
			channelSet.addChannel(channel);
			ro.channelSet = channelSet;
			ro.getProducts();
		}
	}

	]]>
	</mx:Script>

	<mx:HTTPService id="configSrv" url="config.xml" resultFormat="e4x" result="configResultHandler(event)"/>

	<mx:RemoteObject id="ro" destination="product"/>

	<mx:DataGrid dataProvider="{ro.getProducts.lastResult}" width="100%" height="100%"/>

</mx:Application>

The configuration file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<config>
	<channels>
		<channel id="amf" endpoint="http://localhost:8400/lcds-samples/messagebroker/amf"/>
	</channels>
</config>

NOTE: With that type of runtime configuration in place, you can create plain Flex Builder projects (you can select None as the application server type).

This particular example is not extremely flexible. It assumes I will always work with an AMF channel and therefore the only thing my application needs to know at runtime is the AMF channel endpoint URL. For RemoteObject that’s a fairly safe bet, however for messaging-related classes (Producer and Consumer), you may also want to externalize the type of channel you use (AMF Polling, long polling, streaming, RTMP, etc.). Before you start creating that kind of dynamic configuration system, you may want to take a look at the Flex ActionScript framework that does that very well.

A relative newcomer on the list is Swiz, the work of Chris Scott. I figured I would give it a try, and create a Swiz version of the inSync application that I often use to try out and demonstrate different features and techniques in Flex and Adobe AIR. This is not an endorsement of Swiz over other frameworks. I simply wanted to share the sample application I built as part of my own research as a (neutral like a Swiss) Evangelist.

View the source code.

Application Highlights:

At his core, Swiz is a simple inversion of control framework. Using an IoC framework, the components of your application (for example, Views) don’t instantiate or even look up their dependencies (the objects they work with). The framework injects those dependencies when the components are created (hence the term “Dependency Injection” also used to describe this approach). The result is looser coupling and more reusable components. The components managed by the Swiz IoC framework are called beans.

1. Defining your beans

The beans of the inSync applications are defined in Beans.mxml:

<BeanLoader xmlns="org.swizframework.util.*" xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:controllers="insync.controllers.*">

    <DynamicChannelSet id="myAmfChannel">
		<serverPort>8400</serverPort>
		<contextRoot>/lcds-samples</contextRoot>
    </DynamicChannelSet>

    <mx:RemoteObject id="contactService" destination="contacts" channelSet="{myAmfChannel}"/>

    <controllers:ContactController id="contactController"/>

</BeanLoader>

2. Bootstrapping Swiz

You bootstrap Swiz in the preinitialize event of the application. You can have multiple Beans configuration classes. You pass your configuration classes in an array as an argument of the loadBeans function. In inSync, we have only one configuration class (Beans.mxml).

Swiz.loadBeans( [Beans] );

3. Injecting dependencies

Swiz uses the [Autowire] custom metadata to inject beans into other beans and views.
In inSync, the contactService RemoteObject is injected into ContactController.as as follows:

[Autowire(bean="contactService")]
public var contactService:RemoteObject;

… and contactController is injected in the Views. For example, in ContactForm.mxml:

[Autowire(bean="contactController")]
public var controller:IContactController;

Because we use an interface, the View is not coupled to a specific implementation of the controller. If you don’t like to have a reference to the controller in your view, keep reading…

4. Dynamic Mediators

Swiz is an IoC framework. Beyond that, it doesn’t force you to use any specific design pattern. So, if you don’t like to have a controller in your view, you can, for example, set up the view to dispatch events instead. For example, in the save() function of ContactForm.mxml, you would replace:

controller.save(contact);

with:

Swiz.dispatchEvent(ContactEvent.SAVE, contact);

You could then listen to this event in some “mediator” class using Swiz.addEventListener(ContactEvent.UPDATE, someHandler), but the dynamic mediator feature of Swiz allows you to automate this process. For example, you could annotate the save() function of the ContactController class as follows:

[Mediate(event="ContactEvent.SAVE", properties="contact")]
public function save(contact:Contact):void
{
	executeServiceCall(contactService.save(contact), save_result, null, [contact]);
}

Swiz will automatically set up an event listener, invoke the annotated method when the event is dispatched, and pass the specified event properties (in this case: “contact”) as the function parameters.

5. Prototypes

By default, components defined in your Beans configuration classes are singletons. In other words, the same instance of a Bean gets injected everytime it is autowired. In some situations, you may want to inject a new instance of a Bean everytime it is autowired. For example, if you open multiple instances of the same View, you may decide you need one controller per view. Prototypes allow you to define non-singleton Beans in your Beans configuration class using the following syntax:

More on prototypes here.

<factory:Prototype xmlns:factory="org.swizframework.factory.*"
        id="contactController"
        className="insync.controllers.ContactController"/>

Installation instructions:

1. Install the BlazeDS turnkey server. (To be clear: you don’t have to use BlazeDS to use Swiz… That’s just the sample I wanted to build.)
2. Download insync-swiz.zip, and unzip it on your local file system.
3. Copy insync-swiz/java/classes/insync to blazeds/tomcat/webapps/samples/WEB-INF/classes/insync.
4. Add the following destination to blazeds/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml:

<destination id="contacts">
        <properties>
            <source>insync.dao.ContactDAO</source>
            <scope>application</scope>
        </properties>
</destination>

5. Copy insync-swiz/sampledb/insync to blazeds/sampledb/insync
6. Edit server.properties in blazeds/sampledb, and modify the file as follows to add the insync database to the startup procedure.

   server.database.0=file:flexdemodb/flexdemodb
   server.dbname.0=flexdemodb
   server.database.1=file:insync/insync
   server.dbname.1=insync
   server.port=9002
   server.silent=true
   server.trace=false
   

7. Start the database (startdb.bat or startdb.sh)
8. Start BlazeDS
9. In Flex Builder, create a new Flex project called insync-swiz. You don’t have to select any “Application server type”.
10. Copy the Swiz swc and the flexlib swc (used for the SuperTabNavigator) from insync-swiz/flex/lib to the lib directory of your project
11. Copy the files and folders from insync-swiz/flex/src to the src directory of your project
12. Open Beans.mxml and make sure the serverPort and contextRoot properties in DynamicChannelSet match your server setup.
13. Run the application

Summary

Swiz was easy and enjoyable to work with. It is also non intrusive and definitely introduces some interesting ideas. A few lingering questions I didn’t have time to investigate…

• Swiz relies on introspection (describeType) to find its custom metadata in the objects added to the display list (with the exception of classes in the flash.* and mx.* packages). This has a performance impact. I’m not exactly sure how much of an impact it would have in real life apps yet…
• How well does Swiz work with Modules or Marshall Plan subapplications?

If you are looking for more information, check out the following resources:

• Chris Scott’s presentation at Flex 360
• Getting Started
• Chris Scott’s blog
• Sönke Rohde’s blog

Here are the links:

• Lab instructions PDF (Powering Flex Applications with BlazeDS and Data Services)
• Lab files (including final solutions)

If you didn’t have a chance to attend, you should be able to use this as a BlazeDS/LCDS tutorial as well.

It was great to see all of you at MAX. I hope to see you next year in Los Angeles.

Christophe

Introduction to BlazeDS and LiveCycle Data Services ES
Moscone West 2007
5:00pm to 6:00pm

Testing the hosted version

Disclaimer: I’m currently hosting the application on the server I use to host this blog (basic PHP and Tomcat hosting plan). I don’t know much about the characteristics of my server, but I’m probably sharing it with a few dozens of other domains and the resources allocated to me are obviously limited in that shared environment. This is clearly not the ideal environment to host a potentially large scale real time application and I’m investigating other hosting solutions. In the meantime, if you experience difficulties running the app, you can install it locally using the instructions provided below (in “Local installation instructions”). The hosted version tries to connect using RTMP by default (available only as part of LCDS) and falls back to “long AMF polling” or regular AMF polling if the RTMP connection fails.

1. Access http://coenraets.org/apps/gmaprooms/gmaprooms.html on two different machines or in two browser windows on the same machine.
2. Make sure you logon with two different user names and the same room name.
3. Move the map in one browser and notice that the position of the map is synchronized in the other browser.
4. You can also search an address in one browser and the resulting map position will appear in the two browsers.
5. The zoom level and the map type are also synchronized between users.
6. Click the “Whiteboard” button in one browser, pick a color to draw on the map (upper left corner), and start drawing.

Note: you can right-click the application and select View Source or click here to see the source code of the application.

Local installation instructions:

1. Install BlazeDS. You can download the BlazeDS turnkey server (a version of Tomcat with BlazeDS preinstalled) here.
2. Open {blazeds-install-dir}/tomcat/webapps/samples/WEB-INF/flex/services-config.xml and add an AMF long polling channel defined as follows:

   <channel-definition id="my-longpolling-amf" class="mx.messaging.channels.AMFChannel">
   	<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amflongpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
   	<properties>
   		<polling-enabled>true</polling-enabled>
   		<polling-interval-seconds>5</polling-interval-seconds>
   		<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>
   	</properties>
   </channel-definition>
   

3. Open WEB-INF/messaging-config.xml and add the following destination:

   <destination id="gmaprooms">
   	<properties>
   		<server>
   			<allow-subtopics>true</allow-subtopics>
   			<subtopic-separator>.</subtopic-separator>
   		</server>
   	</properties>
   	<channels>
   		<channel ref="my-longpolling-amf"/>
   		<channel ref="my-polling-amf"/>
   	</channels>
   </destination>
   

4. (Re)start the BlazeDS turnkey server.
5. Download the source code of the Google Maps Application here.
6. Create a Flex Builder project for the Flex application (gmaprooms). Make sure you configure your Flex Builder project to work with BlazeDS. To read instructions on how to set up a Flex Builder project that works with BlazeDS, make sure your BlazeDS turnkey server is started, and click here.
7. Download the Google Maps ActionScript 3 API here, and add the swc file in the libs folder of your project.
8. Get a Google Maps API key and assign it to map.key in the initMap() function in MapArea.mxml.
9. Compile the application.
10. Open the Flex application in two browser windows (to simulate two users in different locations) and test the application as described above (in “Testing the hosted version”).

LCDS 2.6 allows you to build AIR applications with automatic offline data synchronization. This feature leverages the SQLite relational database system embedded in the AIR runtime, but the advantage is that the data synchronization process is entirely automatic: you don’t have to write SQL statements or synchronization logic to keep your local database in sync with your central database.

I have been getting a number of questions related to this feature, so I decided to build a sample application that demonstrates how it works.

In this application the synchronization process is implicit. When you are online, the cache (a SQLite database) is automatically updated along with the server database to make sure the user can go offline with the latest data without explicitly triggering a synchronization process. When you are offline, the changes are saved in the local cache. If the network becomes available while working in the application, the application will detect the network status change and automatically synchronize data (send your offline changes to the server, and get changes made by other users while you were offline).

Installation Instructions

1. If you haven’t already done so, install LCDS 2.6.
2. Unzip insync.zip
3. Copy the content of the sampledb folder in the sampledb folder of your existing LCDS directory
4. Copy the content of the tomcat folder in the tomcat folder of your existing LCDS directory
5. Add the following destination to data-management-config.xml

   <destination id="insync">
       <adapter ref="java-dao" />
       <properties>
           <source>lcds.samples.contact.ContactAssembler</source>
           <scope>application</scope>
           <metadata>
               <identity property="contactId" undefined-value="0"/>
           </metadata>
       </properties>
   </destination>
   

6. Restart the sample database: run sampledb.bat (Windows) or sampledb.sh (Unix) in the sampledb directory
7. Restart your application server

Quick Tour

1. Install and run the AIR application. Notice the green light in the status bar indicating that the application is in online mode.
   Please upgrade your Flash Player This is the content that would be shown if the user does not have Flash Player 9.0.115 or higher installed.

2. Double click a contact to view the contact details.
3. Modify the data in a few fields and click Save. Your server console indicates that the contact has been updated.
4. Click the + button in the application title bar. Enter a first name, last name, etc and click Save. Your server console indicates that the contact has been updated.
5. Shut down the server
6. Notice that the green light turns grey to indicate that the application is now working in offline mode.
7. Repeat steps 2 to 4 above: changes are saved locally. Notice that the offline status (not modified, created, or updated is displayed in the contact form (bottom left corner)
8. Restart the server.
9. The green light appears in that status bar as soon as the server is up and running. Notice that LCDS automatically detects the offline changes and sends them to the server.