AS3 library for Google Calendar (as3googlecalendarlib)

I created an AS3 library for Google Calendar API. This library has following features implemented.

1. Authenticating to the Calendar service
2. Retrieving calendar lists
3. Retrieving all calendars
4. Retrieving only calendars that a user owns
5. Managing calendars
6. Creating new calendars
7. Updating existing calendars
8. Deleting calendars
9. Retrieving events for a specified date range
10. Creating single-occurrence events
11. Updating events
12. Deleting events
13. Reminders and Notifications

Please download the library from this URL http://as3googlecalendarlib.googlecode.com

All you have to do is to use the classes in the com.adobe.googlecalendar.services package to use any of the feature mentioned above.

This library still needs to be improved, in terms of adding more features, code cleanup, documentation and implementing any suggestions. I will try to complete this as soon as possible. 🙂

If you are interested in contributing to this library, please let me know. If you want to use this and want to know how to, leave a comment.

I am in process of creating an AIR application using this API, I will be posting soon. 🙂

BlazeDS adapter to invoke multiple classes on a Remoting destination

What is this?

In BlazeDS and LCDS Remoting service, JavaAdapter class allows us to invoke methods on a Java object.  If we want to invoke methods on a Java class, we declare destination for each class we want to be invoked from Flex applications in remoting-config.xml.

I extended the default JavaAdapter and added very very few lines of code so that Flex application can invoke Java classes by specifying the Java class name in the Flex application. Don’t worry, modified adapter allows you to control access to classes using regular expression and other ways.

This will be useful if you have lots of classes, which you want expose as service. Instead of declaring destinations for each class in the remoting-config.xml file, you can use this adapter and expose all required classes by declaring one destination.

What does this adapter let me do?

1.       Specify the name of the Java class in Flex application and invoke methods on that class

2.       You can control access to classes based on regular expression. If you want to allow access to classes in “com.adobe” package only, you can set the source of the destination to “com.adobe.*”.

3.       Declare a default Java class, which will be used if Flex application doesn’t specify the Java class to be used.

4.       From the list of classes allowed in a package, you can exclude few classes

5.       You can specify scope for each class. For example you want instances of 2 classes in the allowed package to be stored in a session or application scope, you can do that.

How to use this adapter?

Adding adapter class to your web application classpath

Download the MultiClassJavaAdapter .java file from this URL http://sujitreddy.g.googlepages.com/MultiClassJavaAdapter.java

Compile it and copy that under WEB-INF/classes folder of your web application in appropriate package structure.

Declaring in remoting-config.xml

The remoting-cong.xml file is explained below. You can download the completed remoting-config.xml file from this URL http://sujitreddy.g.googlepages.com/remoting-config.xml

In the configuration file (remoting-config.xml) file downloaded, you can find we have added our adapter (com.adobe.remoting.adapters.MultiClassJavaAdapter) to the adapters list as shown in the XML snippet below.

<adapters>

<adapter-definition id=”any-java-object” class=”com.adobe.remoting.adapters.MultiClassJavaAdapter”/>

</adapters>

We have destination with id “AnyJavaClass” declared. This destination has its adapter set to the adapter added above using the adapter element.

<destination id=”AnyJavaClass”>

<adapter ref=”any-java-object”/>

</destination>

You can give a regular expression in the configuration file, which will be used to evaluate if a Java class can be invoked by the Flex application on this destination. You will use source property to specify this regular expression as shown below.

You can declare a default Java class, which will be used if the Flex application doesn’t specify the name of the Java class to use. Set the default Java class name using default-source element as shown below.

<destination id=”AnyJavaClass”>

<properties>

<source>com.adobe.*</source>

<default-source>MultiClassAdapterTest</default-source>

</properties>   </destination>

As per declaration above, Flex application can invoke any class under “com/adobe” folder. You might want not want to allow access for few classes in this package. In that case you can declare list of classes you don’t want to exclude as shown below.

<destination id=”AnyJavaClass”>

<properties>

<exclude-classes>

<class name=”com.adobe.ExcludeClass1″/>

<class name=”com.adobe.ExcludeClass2″/>

</exclude-classes>

</properties>    </destination>

By default when there is a request to invoke method on a class, a new instance of that class is created in the request scope. You might want to keep the instances created in application or session scope. Since we are allowing multiple classes to be invoked using single destination, you can declare names of the classes and scope in which you want to store them as shown below.

<destination id=”AnyJavaClass”>

<properties>

<classes-scopes>

<class name=”MultiClassAdapterTest” scope=”session”/>

<class name=”com.adobe.TestClass” scope=”application”/>

</classes-scopes>

</properties>    </destination>

Flex application to test the adapter

Download the MXML file from this URL http://sujitreddy.g.googlepages.com/MultiClassAdapterTesting.mxml

In the file downloaded, you can see that we will use the source property of the RemoteObject class to specify the name of the class to invoke the method on.

That’s it, now you can declare one destination and invoke methods on multiple classes. Still you can control access to classes.

Please feel free to use/edit/delete this class. Any suggestions are most welcome. 🙂

Adobe rocks 🙂

Creating Factory classes in BlazeDS

What is factory mechanism

BlazeDS provides a factory mechanism that lets you plug in your own component creation and maintenance system to BlazeDS so it integrates with systems like EJB and Spring, which store components in their own namespace.

A factory is responsible for creating the instance that should be used for a request to a destination. When a destination gets a request, destination’s adapter will invoke the configured factory for the destination. When the factory is invoked it should return the instance that should be used by the adapter to process the request.

You can see where exactly a factory is used by the Remoting service at this URL https://sujitreddyg.wordpress.com/2009/01/20/how-remoting-service-in-blazeds-works/

Let’s get into details 🙂

Creating a factory

Creating a factory and mapping it to a destination is 3 step process

Create factory class

You just have to create a class which will implement the “flex.messaging.FlexFactory” interface.

Methods to be implemented:

Initialize() – this method will be invoked when the factory class is instantiated. This happens only once.

createFactoryInstance() – this method is invoked for each reference of the factory in a destination. You will get properties declared in the destination as arguments to this method. Every factory class implementing FlexFactory can have a factory instance class extending “flex.messaging.FactoryInstance”. If you have a instance class for your factory create an instance of it and return the same in this method.

Since there is only one instance of the factory class, you can use this factory instance to create instances specific to a destination.

lookUp() – this method is invoked each time there is a request to a destination. If you have a factory instance created and have the lookUp() method overridden in that class, then this will not be invoked. You will receive the instance of the factory instance class returned in the createFactoryInstance() method as argument to this method. You should return the instance of the object that should be used by the adapter.

You can find a sample implementation below.

Create factory instance class

You have to create a class which extends the “flex.messaging.FactoryInstance” class. You should override the constructor. You can override the lookUp() method if you want to do destination based logic in this method. If you don’t override this method, then the lookUp() method in the factory class will be invoked. You should return the instance of the object that should be used by the adapter.

You can find a sample implementation below.

Declaring factory in services-config.xml

To declare a factory class, you should add a tag in the services-config.xml file as shown below. Add the “factories” node under the “service-config” node.

The declaration below is for the sample factory class.

<factories>

<factory id=”MyCustomFactory” class=”com.adobe.factories.MyFactory” />

</factories>

Mapping factory to a destination

In order to set a factory for a destination, you should declare that in the configuration file. In this sample we will change the factory of a Remoting destination. Append the node below in the remoting-config.xml under “service” node.

You can see that we have custom properties in the destination below we will be retrieving those in our factory instance.

<destination id=”CustomFactoryDestination”>

<properties>

<factory>MyCustomFactory</factory>

<source>This is the source</source>

<scope>request</scope>

<mypassedproperty>Sujit Reddy G</mypassedproperty>

</properties>

</destination>

Deploying and testing the factory

Explanation for the samples

We created a factory instance which will get the properties from the configuration file of the destination and then create an instance of “FactoryTesting” class. When we invoke getMe() method on the destination, the method is actually invoked on the instance returned by the factory instance class.

Download the following files

MyFactory.java

MyFactoryInstance.java

FactoryTesting.java

FactoryDestinationTesting.mxml

1.       Copy the .class files of MyFactory.java, MyFactoryInstance.java and FactoryTesting.java files in appropriate folders based on the packages.

2.       Add factory declaration in service-config.xml and declare destination in remoting-config.xml as mentioned above

3.       Create a Flex project pointing to the BlazeDS/LCDS where we have the classes deployed and factory configured.

4.       Use the FactoryDestinationTesting.mxml to invoke and see that the object instance created in the factory instance created is on which the method is invoked.

That’s it 🙂 Adobe rocks 🙂

How Remoting service in BlazeDS works

In this post I tried to explain how Remoting service in BlazeDS works. Obviously I cannot explain each and every line of the code; I tried my best to cover all. I explained how each component of the Remoting service are invoked sequentially to invoke the method on the Java class and return the values.

I took remoting-config.xml file as the starting point to explain how each component is tied.

Recalling how to create Remoting destinations

In order to invoke methods on a Java class, we declare destination for that class in the remoting-config.xml file. From the Flex application we use the RemoteObject and invoke methods on the class by mapping it to the id of the destination declared.

How do they work and who are they?

Remoting Service

<service id=”remoting-service”  class=”flex.messaging.services.RemotingService”>

This will be the root node of the remoting-config.xml. Observe that “class” attribute is set to “flex.messaging.services.RemotingService”. This means the destinations under this “service” node will be handled by the “flex.messaging.services.RemotingService” class.  When a destination gets a request, RemotingService will invoke the appropriate adapter for the destination to get the result.

Adapter

<adapters>

<adapter-definition id=”java-object” class=”flex.messaging.services.remoting.adapters.JavaAdapter” default=”true”/>

</adapters>

This is how we declare adapters for this service. Each destination will have an adapter. You can see that the “default” attribute is set to “true”. This means that if a destination declaration doesn’t specify an adapter, then the default adapter will be used.

In our normal remoting JavaAdapter class is the adapter. JavaAdapter is responsible for invoking method on object and return the result. JavaAdapter also checks if the method invocation is allowed. JavaAdapter will depend on the JavaFactory class to get the object instance on which the method should be invoked.

Factory

<destination id=”my-destination”>

<properties>

<source>flex.samples.EmployeeService </source>

<scope>application</scope>

</properties>

</destination>

This is how we declare a Remoting destination. This destination has its “source” set to “flex.samples.EmployeeService” and “scope” set to “application”.

JavaFactory will use the value of the “source” element to decide which type of object to instantiate and the value of the “scope” element to decide in which scope of the web application the created instance should be stored or look for the instance already created.

JavaFactory is responsible for returning the object instance. In this case JavaFactory is responsible for returning the instance of the “flex.samples.EmployeeService”. If the “scope” is set to application/session then the JavaFactory will check if there is already an instance in the scope and return that. If the object is not available then it is instantiated and stored in appropriate scope.

Wait a second we did not declare a “factory” in the destination. Yes, we did not declare “factory” because JavaFactory is the default factory used by the JavaAdapter.

Complete flow

RemotingService will invoke the JavaAdapter. JavaAdapter will do necessary checks and invoke JavaFactory. JavaFactory will return the instance based on the “source” and “scope” element values. JavaAdapter will now invoke the method on the instance using Java Reflection API and return the result. RemotingService will return the same. MessageBroker will take it from here.

That’s it, each component work so well to allow us to remotely invoke methods on the Java classes.

Flash Ahead – Showcasing future of Flash Platform – Bangalore

Here’s announcing Flash Ahead… The event that will showcase the future of the Flash platform to the Indian audience for the first time.

Date: 17th January, 2009

Venue: Lalit Ashok (erstwhile Grand Ashok), Bangalore

Time: 09:00 to 18:00

At Flash Ahead we are going to announce the selected finalists of riathon’08 and they will battle it out in an on-stage showdown of application, in front of the crowd and judges. Later in the day, the results will be announced and prizes will be distributed. You will also get to see the latest technologies on the Adobe Flash Platform.

Flash Ahead is your opportunity to catch the very first preview in India of latest in the RIA world that was previewed at MAX 2008. Sneak peeks into Gumbo (the next version of Flex), Flash Catalyst (earlier called Thermo), Alchemy (a technology that brings the power of high performance C and C++ libraries to Flash Player), BlazeDS.NET, Flex™ plug-in for Microsoft® Visual Studio®, Actionscript Cloud Services and much more. For more information see this page – http://adoberiathon.wordpress.com/2009/01/12/flash-ahead

There are limited seats available, so please confirm at the earliest. If you are interested in attending, RSVP at – http://endtoend.in/apps/forms/adobe/flash/adobe.htm