A Flex / Flash guy learning more about Java

A Flex / Flash guy learning more about Java

Understanding more about Java is great. A good amount of knowledge can be shared between Flex/ActionScript 3.0 and Java. I’ve worked with Java in the past, compiled some applications, read the tutorials and some books, helped build a Java based LMS and also worked with Adobe on writing a simple Java socket server, but I wanted more of a thorough understanding of the language. The University of California at San Diego offers a great series of programming and software development courses. These classes are really affordable so I decided to take a Java II course. It’s been seven weeks and so far the experience has been awesome. The end goal is to become more familiar with the core Java language. My hope is that this will enable me to have greater confidence when working on Flex and BlazeDS projects. (A really cool stack I’ve been playing with recently is Flex/Cairngorm, the new Spring/BlazeDS integration and Hibernate/MySQL. Eventually I want to get this running on Glassfish. Something else I’ve been looking into.)

Some items we’ve covered in the Java class so far are: SDK installation and command line compilation, data types, control flow, variables/operators, numbers, arrays, objects and classes, static classes and methods, method overloading, object construction, constructor overloading, OOP basics, packages, commenting, generating JavaDoc, inheritance, abstract classes, polymorphism, sub/superclasses, reflection, inner classes, graphics programming, event handling, Swing and Collections including Maps, Lists, Sets and the Comparator interface. We’re compiling all of our homework using the command line. It’s pretty cool. The class also demands a pretty rigorous reading schedule. The three-pronged-learning-approach is working well for me: lectures, reading, coding (homework and labs.) The ins and outs of the language are really sinking in.

A few immediate benefits to learning more about Java are: Flex and BlazeDS / LCDS integration, strengthen fundamental OOP understanding and comprehension and also gain knowledge of OOP concepts not available in Flex/AS3. Learning Java also provides the opportunity to get exposure to Swing (Flex’s distant relative). Also, since the Flex compiler and other aspects of the Flex SDK are written in Java this opens up the door to greater understanding of the Flex SDK and even bug contributions. Java makes extensive use of design patterns and there is a plethora of existing Java code to look at, use and learn from. (Cairngorm was born from J2EE design patterns.)

There are several differences that I noticed in Java. Some items available in Java and not in AS3: static classes, abstract classes, private constructors, constructor overloading, method overloading and Collections. Working with Arrays is a LOT different, working with numbers is different, working with Strings is different and String comparison is different. There are no Hashmaps and no hashcodes in ActionScript. No equals() method. Another difference is that you have to implement your own design patterns more often in Java. Not a bad thing, and good to know how to do, but Flex takes care of a lot of things behind the scenes: events, data binding etc. I noticed that when coding Java the developer is expected to implement interfaces more often than in Flex/AS3. This is pretty cool; it involves more work but provides more power.

It’s been a cool experience and I wanted to share some of these thoughts and observations. I think more developers come into the Flex world from Java vs. the other way around. For some reason Java sort of reminds me of AS2… I may try to post some Java source code soon if time permits…

Original post http://seantheflexguy.com/blog/2009/02/20/a-flex-flash-guy-learning-more-about-java/

Merapi is the bridge between Web and Desktop software

Merapi is the bridge between Web and Desktop software  Merapi, a project run by the team at Roundarch Labs, has been a long time in the making, but on July 14th, 2008 the initial Merapi Alpha release candidate was distributed to the Merapi Alpha community of users. On Wednesday, May 20th, Merapi is officially Open Source! After almost a year of  heavy development, we have finally released Merapi's Java-to-AIR bridge framework as Open Source, and are hosting the project on Google Code. Merapi is a technology that can be used as a messaging bridge between applications that run in the Adobe Flash player or Adobe AIR and applications written in Java. This is really exciting to the Java, Adobe Flex and Adobe AIR development communities and everyone on the Merapi team is excited as can be to start working with this larger community group to uncover bugs, add features and shape the concept of Merapi into the backbone of killer applications across the globe. Since the initial release, the community has provided a lot of feedback to the Merapi team, and the industry has started to take notice of what we are doing, and what Merapi can be used for. While we are working hard to improve the core functionality and developer experience when using Merapi, members of the Merapi project team are constantly out an about at conferences, user groups, talking to developers,  analysts and members of the "Web" media about what we are doing and about how Merapi can be used to create fundamental changes in the way we design and develop software applications. For more information about Merapi, how you can use it, how it is being used, and what it means for the future of Web and Desktop software development, we suggest you check out the information posted on this Web site, by searching Google,  reading through the Merapi Project forums, or by checking out some of the Merapi project member's own personal Web sites: Adam Flater (founder, architect) - adamflater.net, Dave Meeker (chief project instigator) - whatanexperience.org, orthese other blogs/postings. To learn more about Roundarch, check out our old (and soon to be re-launched) Web site - roundarch.com. We will soon be re-designing this Web site, and encourage you to still sign up and create an account. Doing so will allow us to provide you with updates on Merapi and other next-generation technologies developed/supported by Roundarch Labs. Tosign up as a member of the Merapi Project Web site. Once we receive your request, we will approve your account and you will get an automated email with your account credentials and other information. To get involved with the Merapi Project, click this link.

How to Get Merapi Code

So, you've read all about it and want to jump in and become part of the future of the Web, huh?

We have spent the last year working on Merapi, talking to users, developers, software companies and others in the community to get feedback on how Merapi should work, how it might be used and what people really want out of a next-generation technology such as this. With the generous support of Roundarch, Merapi has made it out of the private alpha stage and we've released Merapi as Open Source.

To help simplify things, we have decided to host the Merapi source code, examples and message boards on the Google Code Web site. You can access the project files, etc. at the following URLS:

http://merapi.googlecode.com/
http://merapi-examples.googlecode.com/
http://groups.google.com/group/merapi-project

We will be updating the Merapi Project Web site (this Web site) in the coming weeks, and encourage you to still sign up for an account so that we can notify you of updates to the project and keep you up to date on the latest news related to Merapi, RIA development and the future of Web & Desktop integration.

Don't be shy. We'd love to have you participate.

Once we receive your submission, we will review it and approve your account.

Join the Merapi Community

Why Merapi was Created

Merapi was created to extend the capabilities of applications built on the Adobe AIR™ platform.

Adobe AIR™ has been recognized a revolutionary step forward in "next generation" software design and development.

With AIR's launch, the massive community of Flash, Flex and AJAX Web developers were provided the ability to build desktop applications using the tools and technologies with which they are already familiar. Using the Adobe AIR™ API, their "Web" applications can become integrated with the user's desktop operating system.

AIR is a framework that does most of the hard work for you. It enables applications to run locally, connect to Internet services, store data locally, and access information stored on the usre's file system. It's great, and the team that founded the Merapi project are huge proponents of the Adobe AIR™ platform, as well as Flash, Flex and other Adobe technologies.

We are passionate software designers and developers, with a primary goal of pushing the possibilities of user experiences.

In order to provide the best user experiences, we often find ourselves in a postion to try and push the limits on available technologies. When coming up with ideas about cool applications that could be build on the Adobe AIR™ platform, some of the most innovative concepts for "Rich, Connected" desktop applications were even outside the capabilities that AIR™ was able to provide.

One of the biggest benefits of Rich applications developed using Adobe technologies is the ability to provide killer user interfaces and what we consider to be "next generation" user experiences. Professionally, most of the members of the Merapi Project team do this every day for clients.

While AIR™ is a huge jump by itself, we found ourselves asking:

• Could we connect an AIR™ application to a wii remote?
• Could we use AIR™ to talk to a phone plugged in via USB?
• What if we wanted to do TWAIN Capturing of Video or Images from a camera or scanner?
• Could we control robots with an AIR™ application?
• What about sending MIDI signals to instruments over a network using an AIR™ application?
• Could I build a social-networking AIR™ application that controlled hardware devices?

Adobe AIR™ doesn't allow for these things natively. We realize that Adobe might do this in the future, and make Merapi obsolete. While it would represent an end to the value our open source project, it would be for the best! It would mean that we could build bigger, badder, and bolder desktop applications using Flex, Flex Data Services, LiveCycle, and other Adobe products... and we'd be able to do so without having to "build the bridge" to the OS, which is what we've done with Merapi.

Building a Bridge between Adobe AIR and Java (OS)

Merapi is a Java™ application, intended to run on a user's (client) computer. Merapi connects other Java™ applications on the user's computer to Adobe AIR™ applications that the user has installed.

It isn't magic. You have to develop your Adobe AIR™ application in a way that allows it to connect to Merapi. Merapi acts as a "middle man", passing objects between your AIR™ application and your Java™ application.

Using Merapi, Adobe AIR™ applications can "talk" to other software that the user has installed on their computer. In addition, Merapi allows AIR™ applications to serve as a user interface to just about anything that a Java™ application can do on a user's computer.

How Merapi Works

Merapi is a framework that bridges an AIR application with a Java application, both running on the desktop. This communication is accomplished through a class that exists in Java and ActionScript called merapi.Bridge.

The simplest way to interact from AIR to Java is by sending and receiving messages though the bridge.

Sending a message from ActionScript:

var message : Message = new Message();

message.data = "Hello from Merapi Flex.";

message.type = "Reply";

Bridge.instance.sendMessage( message );

Sending a message from Java:

Bridge bridge = Bridge.getInstance();

Message message = new Message();

message.setData("Hello from Merapi Java.");

bridge.sendMessage(message);

Receiving a message in Flex:

id="bridge" result="handleResult(event)" />

private function handleResult( event : ResultEvent ) : void

{

var message : IMessage = event.result as IMessage;

Receiving a message in Java:

Bridge.getInstance().registerMessageHandler("Reply", messageHandlerInstance );

public void handleMessage( IMessage message )

{

System.out.println( message.getData() );

}

More advanced features are available in the framework for creating proxy objects in ActionScript or Java that automatically cause a mirrored instantiations and invocations on the corresponding side of the bridge. This functionality is essentially an abstraction of the basic messaging framework described above.

Merapi Videos As we get more videos posted, we will be sure to add them to this page. Hello World! Hello Merapi!!!! Check out Adam Flater's "Hello World" example using Adobe Flex, Java and Merapi Merapi and Physics - This is cool! Prior to talking about Merapi at WebManiacs, Adam Flater put this tiny AIR application together. This application, designed to run on the Mac, uses a Java program to read the data that is being reported by the Mac's accellerometer. Java passes this value to the AIR application and...... Well, just watch the video. Cool? YES Indeed! Merapi meets Robot! With the help of our pal Jordan Snyder, Merapi is seen here enabling an AIR application to control a Lego Mindstorm Robot. This is done using the lego Mindstorm API, Java and Bluetooth. More of this to come!

 

Remote Object Service in Flex

» Der Remote Object Service in Flex

Was unterscheidet den Remote Object Service vom HTTPService oder dem WebService?

Wie auch der HTTPService und der WebService greift der Remote Object Service über das HTTP Protokoll auf die Ressourcen des Servers zu. Im Gegensatz zu den erst genannten Services benutzt der RemoteObject Service aber nicht das auf Text basierende XML Format für den Informationsaustausch, sondern das proprietäre AMF (Action Message Format). Dieses codiert die auszutauschenden Informationen binär, die gesendete Nachricht wird dadurch wesentlich kleiner und kann schneller übertragen werden.
Java Entwickler mag diese Technik an die RMI API erinnern und der Vergleich ist durchaus angebracht. RMI nutzt jedoch statt des HTTP Protokolls (Port 80) ein eigenes Übertragungsprotokoll, scheitert damit an den meisten Firewalls und macht deshalb nur in firmeninternen (oder anderen geschlossenen) Umgebungen Sinn. Im Gegensatz dazu kann der Remote Object Service ohne Einschränkungen auch im Internet verwendet werden.

Das POJO auf dem Tomcat

Um den Remote Object Service zu verwenden, muss zunächst ein Service Objekt in Java implementiert werden, welches die auf dem Client benötigten Methoden zur Verfügung stellt. Die Methoden, die der Client später verwenden soll, müssen als public deklariert werden. Die Klasse muss sich zudem im CLASSPATH des Flex Data Service befinden und einen leeren Konstruktor haben. Eine simple Testanwendung könnte wie folgt aussehen:

 Die Service Klasse auf dem Tomcat
      
         public class RemoteObjectService {
      
              public RemoteObjectService() {}
           
              public String sayHello() {
                  return "Hallo Flexwelt";
              }
         }
         

Bekanntmachen der Klasse

Damit der Flex Data Service die erzeugte Klasse als RemoteObject erkennt, muss diese in der remote-config.xml bekannt gemacht werden. Die remote-config.xml befindet sich, genau wie die proxy-config.xml, im Verzeichnis WEB-INF/flex unterhalb des Context-Root.
Für die erzeugte Service Klasse wird eine neue Destination angelegt. Diese bekommt eine eindeutige Id, die später in der Flex Anwendung zur Referenzierung des entfernten Objektes gebraucht wird. Zusätzlich wird der vollständige Klassenname und der Scope deklariert.

 Auszug aus der remote-config.xml        

         
              
                  org.fleksray.samples.RemoteObjectService
                  application
              
          
          

Scoping

Die drei Möglichkeiten um einen Scope zu definieren sind application, session und request. Diese Varianten den Scope zu definieren sind Java Entwicklern hinreichend bekannt, deshalb hier nur eine kurze Erklärung.
Wird für das RemoteObject der Scope application definiert, wird für jede Serverinstanz nur eine einzige Klasse instantiiert. Alle Anwender der Applikation greifen also auf das gleiche Objekt zu. Im session Scope wird für jeden User ein eigenes Objekt angelegt. Dieser Scope wird deshalb in der Regel für Session Tracking, das Speichern von Warenkörben und Ähnlichem verwendet. Im request Scope wird für jeden HTTP Request ein neues Objekt erzeugt. Dieser Scope erhöht die Rechenlast des Servers empfindlich und sollte nur, wenn unbedingt notwendig angewendet werden.

21. Oktober 2007

» Aufruf entfernter Methoden

Verarbeiten der Daten auf dem Client mit Hilfe der Binding Expressions

Um die vom RemoteObject bereitgestellten Daten zu verarbeiten, stehen dem Entwickler zwei Möglichkeiten zur Verfügung: Binding Expressions und in ActionScript geschriebene Event Handler. Erstere Methode ist einfacher und weniger verbose. Werden dagegen eigene Event Handler benutzt stehen mehr Möglichkeiten zur Verfügung, die Daten zu verarbeiten.
Mit Hilfe der Binding Expression ist das entgegennehmen der Daten recht einfach.

 Auszug aus der MXML Datei die das RemoteObject verwendet
 
               
                
               
               
         

Verwenden der Event Handler

Das RemoteObject löst bei erfolgreicher Datenübertragung ein ResultEvent aus. Lief etwas schief wird ein FaultEvent getriggert. Innerhalb der Event Handler können die Ergebnisse des entfernten Methodenaufrufes vielfältiger gehandhabt werden, als mit den Binding Expressions.

 Die MXML Datei verwendet nun Event Handler
       
     
      
          
               handleResult(ev:ResultEvent):void {
                       _message = ev.result.toString();
                   }

                   private function handleFault(ev:FaultEvent):void {
                       _message = "das ging daneben: "
                       + ev.fault.faultCode + " :: "
                       + ev.fault.faultDetail + " :: "
                       + ev.fault.faultString;
                   }
               ]]>
           

           result="handleResult(event)"
               fault="handleFault(event)"/>
            
           
           
       
        

Ein FaultEvent kann leicht ausgelöst werden, indem im click Handler des Buttons auf eine nicht existierende Methode des RemoteObject zugegriffen wird ( click="{myRemoteObject.sayGoodBye()}")

Result Handler Dispatching im RemoteObject

Wie geht man nun mit Service Objekten um, die dem Client eine ganze Reihe von Methoden zur Verfügung stellen. Im RemoteObject wird im oben gezeigten Beispiel nur einen Result Handler defininiert, der für genau eine Methode zuständig ist..
Ein erster, einfacher Ansatz wäre, im Result Handler eine switch-case Anweisung zu schreiben, die anhand des übergebenen Events die aufzurufende Methode erkennt.
Flex bietet eine elegantere Lösung. Innerhalb des RemoteObject können den Service Methoden jeweils unterschiedliche Result Handler zugeordnet werden.

 Dispatching der Events an unterschiedliche Handler
    
     
      
              
                  handleHelloResult(ev:ResultEvent):void {
                          _message = ev.result.toString();
                      }

                      private function handleDataResult(ev:ResultEvent):void {
                          _data = ev.result as ArrayCollection;
                      }

                      private function handleFault(ev:FaultEvent):void {
                          _message = "das ging daneben: "
                          + ev.fault.faultCode + " :: "
                          + ev.fault.faultDetail + " :: "
                          + ev.fault.faultString;
                      }
              ]]>
          

          
              name="sayHello" result="handleHelloResult(event)" />
              name="getTestData" result="handleDataResult(event)" />
          


          
          click="{myRemoteObject.sayHello()}"/>

          

          
          click="{myRemoteObject.getTestData()}"/>

     

Im gezeigtem Beispiel wird für jede Methode des Service Objektes ein eigener Result Handler deklariert, der Fault Handler wird von allen Methoden gemeinsam benutzt. Es ist auch möglich, jeder Methode einen eigenen Fault Handler zuzuweisen.

31. September 2007

» Übergabe von Argumenten

In den meisten Fällen wird von einer Applikation mehr verlangt, als nur einfache Methoden aufzurufen. In der realen Welt müssen Eingaben des Benutzers an den Server weitergeleitet werden und zu einer entsprechenden Response umgesetzt werden. Die Eingaben werden, wie in bei Html auch, oft über Formulare entgegengenommen und dann verarbeitet.
Das RemoteObject muss also auch in der Lage sein, Argumente zu verarbeiten. Im folgendem Beispiel soll das Service Objekt auf dem Server aus zwei übermittelten Strings ein personalisierte Begrüßung bauen.

 Die Java Klasse übernimmt Argumente
     
          public class AnsweringService {
       
              public AnsweringService() {}
           
              public String sayHello(String title, String name) {
                  return "Hallo " + title +" " + name;
              }
          }
          

In der MXML-Datei werden die Argumente innerhalb des <method> Tags deklariert. Hier können statische Werte oder Binding Expressions verwendet werden.
Das Tag erwartet ein Array mit Parametern. Wie diese Parameter benannt werden, ist unwesentlich. Der Konsistenz halber sollten sie aber wie die Argumente der Java Klasse benannt werden. Entscheidend ist die Reihenfolge der Argumente. Das zuerst deklarierte Element wird als erstes Argument an das Objekt auf dem Server übergeben.
Werden Argumente in der beschriebenen Weise übergeben, muss im Click EventHandler die Methode send() an der Remotemethode aufgerufen werden.

 Senden von Argumenten an das Objekt auf dem Tomcat Server
       
   
   
       
              
                  
                      
                          
                          
                             {myName.text}
                          
                     
                 
             

             
         
             
         
             
                 
                     id="title"
                         dataProvider="['Frau','Herr','Mrs.','Mr.']"/>
                 
                 
                     id="myName"/>
                 
            
         
           click="{myAnsweringObject.sayHello.send()}"/>