Enterprise Rich Internet Applications and Mobile Technology
Enterprise Rich Internet Applications and Mobile Technology
Author: Fabio Trentini, BTC Business Technology Consulting, July 2011
Preliminary Information
Delivering business data to end users on time and up to date, as we all know, belongs to the pre-requisite of every business. Facilities allowing external agents, employees and customers to directly retrieve, update and enter business relevant information from mobile devices belongs today to every modern and innovative organization.
The App Store is of course one of the first though as soon as we refer to mobile applications. Besides revolutionary and exclusive ideas that will make us all rich and famous by developing "the App" that everyone worldwide will buy and install on his/her mobile device, there are also other alternatives such as implementing tailored and dedicated applications supporting specific corporate business needs in order to optimize the usage of own internal resources and services.
In other words, a mobile application does not necessarily have to target a worldwide user segment but is also an option for specific in house business solutions and may be used within a company or in a B2B approach. The IOS developper Enterprise program of Apple is an example for such "proprietary" in House app that may be distributed to employees and members of a given organization.
From the strict technical point of view, the implementation workflow for mobile applications allowing to integrate available backend business service components has been greatly simplified with the appearance of new modern development environment.
In this paper I will discuss the latest mobile facilities included in the Adobe Flashbuilder (commercial release of June 2011) and compare it, at least from a personal experience and point of view, with a native development approach using the Apple XCode environment and Objective C for IOS devices (i.e. for Iphone, Ipod Touch and the Ipad). Both approaches (Xcode and Flashbuilder) provide their advantages and according to the specific requirements and the available IT resources, the decision of which way to go may not be as obvious as it may seem at first glance.
The reason to select Flashbuider for this paper is therefore not aiming to necessarily present it as the absolute way to follow. The latest development environment provided by Adobe is however an excellent example on how existing skills and resources originally involved in the implementation process of powerful Rich Applications for the WEB (or Desktop Applications using Adobe AIR) , can now be used to write/generate native applications for mobile devices (i.e. targeting for example the Ipad without flash and as native IOS application) and at the same time using the available knowhow and programming environment.
This may make a difference for requirement analysis, resource planning and project design workflows . If some months ago, a mobile module for a given project had to be considered with additional costs in term of available IT resources and/or missing mobile implementation language knowhow (such as objective C for example) , the same requirements could be taken over today with the available IT staff on place since the mobile part of a project could be solved as a development task equivalent to the remaining desktop or intranet visual components implementation.
In other words, a company having in house FlashBuilder knowhow , thus taking advantage of the power of this environment in the Rich internal Application area for intranet and WEB based applications, can now in addition also approach functionalities that would target mobile IOS, Android or Blackberry devices since these would implicitly belong to the implementation options that could be taken over by the same team, and using the same implementation language.
Consider the following example used here to illustrate this aspect. The following component is a very simple Flashbuilder "widget" (the relevant code will be shortly discussed later on and, as we will see, it's going to be very compact and straight forward for either the WEB and the mobile versions).
Consider now the very simple requirement of bringing the chart component on an Ipad/Iphone. Going one year back, this would have been feasible by either re-implement the same logic using Objective C (and XCode) or create an equivalent functionality using HTML 5 or whatever Javascript library providing similar visual and chart components.
We can now (commercial sinceJune 2011) in Flashbuilder directly generate an IOS application by selecting the desired target mobile platform as reported in the following screenshot (taken from Project settings - Flashbuilder ver 4.5.1 for mobile Projects).
$
This short video shows the results and how Flasbuilder charts runs on Ipad and Android mobile devices.
From a whole project lifecycle perspective, and even if, as we will see, the deployment process in case of Flashbuilder is, to date at least, slower and to some extents may seem less effective than XCode, there are also more than one reason to still consider the Adobe solution.
I personally work with both Xcode and Flasbuilder platforms and I sure would like to see the advantages of both environments in one product (Flashbuilder for the ease of use, portability across multiple mobile platform, visual component models and embedded service integration components combined with the XCode/Objective C full Ipad/Iphone framework availability and direct development workflow).
Mobile applications, as we know, require data and data has to be stored and maintained in the corporate business server landscape. The corporate data need to be maintained and kept up to date using desktop and intranet based client applications. Mobile applications up front always need therefore also a backend infrastructure and user interfaces. Flashbuilder can therefore cover both aspects in one shot by offering a very powerful, easy and effective mean to integrate, render and manipulate remote service components using a variety of standard J2EE compliant protocols.
If new to Flashbuilder you may want at this point have first a look at these examples on the official Adobe site and select in particular the "introduction to flex" show cases since this gives an excellent overview on what this technology may bring to your organization and see who is using it.
Note on terminology : We refer, according to the context, to Flex or Flashbuilder . For readers not (yet) familiar with these technologies and development environment of Adobe, we actually talk about the same Product. Adobe changed the name from Flex to Flashbuilder since Version 4 i.e. "Flex" is actually now called "Flashbuilder". In other words Flex=Flashbuilder.
The Adobe Flex/Flashbuilder way towards IOS native Applications
At least from what we can read and recall from various discussion sites on the internet, in particular when Apple brought the first Ipad on the market, quite a number of Flashbuider adopters, including myself, have been kind of disappointed to realize that the flash player would probably never be part of the Iphone/Ipad architecture.
Remember?
- will they enable it in the future ?
- When ?
- How ?
- Why Not ?
- Why should they?
- Does that make sense ?
- What will be the strategy of Adobe ?
- etc....
It is here not the aim to start again an endless (and, let's admit it, to some extent useless) discussion about the reasons (whether these were strategic or technical) why the flash player has not been considered on the Iphone and Ipad platform, but rather stick to the facts and reality. The player is not available today on these devices and probably will never become part of IOS in the future as well.
The only reasonable way to write applications for the Ipad and Iphone was therefore, at least as far as I was concerned , to recall the old C/C++ skills, left aside for a while, and simply learn XCode and Objective C.
From the backend point of view, understand here the access of remote corporate services, there are with Objective C actually no restrictions since all the most used standard protocols are supported and the efforts are therefore focusing on the client navigation and rendering part of the story. Even AMF based services, originally written for Flex/Flashbuilder applications, can actually be directly used, as is, from a native Objective C Ipad/Iphone Application (this through freely available AMF library for Objective C). In other words, the server side of a project, and the way used to bring data to the Ipad/Iphone client, is in practice not really affected by the fact the we would use Objective C or another technology.
in the meantime, the strategy of Adobe focused during the last months on a cross compilation approach allowing to bypass the technical requirement for the flash player to be available on a target device and at the same time focusing on a more generic approach where not only IOS but also other mobile devices would be supported in one shot.
Cross code generation aspects
The cross generation approach as such is not new and exists since a couple of years already. Readers familiar with such kind of solutions know that a "generic" code generation process is also bound with some compromises. From an overall project perspective however, and in particular for business specific requirements, those "limitations" are not necessarily a killing factor.
If we develop a game or an app targeting a very large user segment worldwide we certainly have more strict user interface requirements as opposed to information that we may want to bring to our end users within a corporate business. This does not mean that the quality of the information or application will be bad in the corporate example of course , but the expectations may be tailored to a specific business need and compromises are in general in this cases easier to achieve since the target user segment will be smaller.
A salesman or an employee working outside the headquarter may need for example to access customer information or sales, prospects figures on a mobile device. We can of course build an openGL 3D interface for that (in which case a native XCode implementation may be more appropriate), but probably a list and a chart similar to the one reported above may already fit the requirements.
My dentist notifies me with a simple SMS one day before I must go for a consultation. I do not need, to be honest, a 3D openGL diagram for this purpose.
A short comparison between the development workflow using Flashbuilder (for IOS) and XCode (objective C)
In a very simplified way, the development workflow for IOS (to date, July 2011) for Xcode and Flashbuilder is shortly compared in the following diagram.
Note: I describe here the deployment process allowing to install the code on a physical target IOS device. It has to be noticed that both development environments provide a device simulator facility allowing developers to debug and test their applications first on their desktops without the need to deploy on the physical target device. Notice also that XCode runs exclusively on MAC operating systems. Flashbuilder on the other hand is available on different platforms such as Windows and MAC. Please refer to the respective vendors (Apple and/or Adobe) for a more precise and detailed information.
As we can see in the diagram, the IOS implementation process under Flashbuilder requires 3 steps.
Note: Under Xcode 4, there is also a possibility to open the Xcode Organizer, select the target device, and simply drag/drop the compiled cross generated version of the application (i.e. the .app File) to the device. This basically simplify the task of going through iTunes to run the application on the physical device. To my knowledge, this feature is however only for developers using a Mac and Xcode.
The application is implemented using standard MXML and/or Actionscript.
Step 1:
In order to move the application on a physical device, the resulting compiled (flash) code need to be first cross generated and compiled (point 1 in the diagram) using the Adobe AIR packager for IOS. This step may take some minutes to complete.
Step 2
The resulting packaged file (App in the diagram) is a native Iphone/Ipad compliant application that will have to be first manually transferred (via drag & drop) to Itunes (step 2 in the diagram).
Step3
Once available in Itunes, the Application will have to be (again manually) synchronized on the target Ipad/Iphone device (Step 3 in the diagram).
As opposed to the Flashbuilder deployment process, an application written with Xcode (Objective C) will be compiled and directly deployed on the target device (this single step, unless your are developing an extreme large and complex application, arises within seconds) and without any intermediate steps (i.e. the itunes step is for example not required under XCode)
Another aspects and difference is that the resulting App can also be directly debugged using the XCode debugger where brake points, variable contents and console log messages are directly available within the Xcode debt console while the application is running on the device
In this respect, the development workflow in Flashbuilder cannot, to date at least, compete with XCode. There are however reasons to still consider Flashbuilder, since the implementation and deployment process is actually only a part of a project lifecycle.
When I discuss the subject with developers (objective C and/or Flashbuilder), I usually ear the following comments:
The pure Objective C developer usually argues with:
- Performance . The deployment process using Flashbuilder is definitively more time intensive than the XCode equivalent. Considering the typical and well known "Hello World" application for example, it takes few seconds from Xcode to get the App up and running (on the physical device) and roughly a minute (each time going through a manual synchronization process via Itunes) when we use Flashbuilder.
- Debugging. We can directly debug via XCode an Application that is directly running on the Ipad or Iphone. The same task is in Flashbuilder possible but cumbersome.
- Runtime performance. Native applications run drastically faster if written in Objective C. List scrolling is for example a major item of discussions. I personally miss the smooth scrolling performance of native Objective C implementations (and I am not talking about the simple employee list but rather lists including for example, besides text, on the fly charts as part of each individual list item)
- Framework-Api's and native resources access. As Xcode-developer, we can use basically any API available on the Ipad/Iphone as opposed to the Adobe approach where we need to wait until the access of a given resource is included in Flashbuilder.
- Vendor dependency. If a given feature is not available via the packager, or if a bug is discovered, Flashbuilder developers will have to wait for an upgrade or bug fixing release (or ultimately forget about a new feature, if this will not be considered by Adobe).
- Available IT-Resources. A Corporate having available Flashbuilder development skills may reuse quite a number of existing resources in terms of people and business components . In addition, and please do not misunderstand my comment here, even if I like Objective C, a lot, the learning curve and ease of implementation for Client based application is easier and much more compact using Flashbuilder than XCode.
- Portability. Even if it takes minutes to get a running Ipad application on the physical device, the same application may also run, out of the Box, on an Android tablet or Blackberry device (refer here to this video demonstration for example) whereas the objective C developers may still need (probably more than a minute) to rewrite the same code for Android or a Blackberry.
- Device Interoperation. As this is demonstrated in the video mentioned above, we can consider the implementation of applications that would interoperate on different physical devices. Assume for example a corporate requirement having both Android tablets and Ipads to be part of the target devices, Flashbuilder would allow in this case to design and implement the project once by covering, in one shot, and by the same implementation team, both platforms.
- WEB integration and reusability aspects. Even if writing a mobile application, from the strict user interface interaction perspective, is fundamentally different than implementing the same functionality for a Desktop or a Flashbuilder Rich WEB based application, there is a very high degree of code reusability. Some specific visual components that we may run on an intranet infrastructure can be directly used, as is, within an Ipad/Iphone application. Wehave never experienced an objective C native module running directly on a Web browser so far.
There are certainly other arguments in favor or against the one or the other approach.
First of all, and probably this is the most important consideration, we need to take some distance from the "who is the best" aspects trying to identify and prove which development platform is the absolute market leader but rather evaluate on a case by case situation what we actually are targeting in order to support the business requirements. Among others we may want to consider:
- Skills. Doe we have native (Objective C) skills in House or are we ready to train our staff accordingly ?
- Target Users: Are users mainly using Ipad and Iphone or do we need to consider other hardware devices ?
- Specific functionality. Do we really need to use specific device facilities that would not be available in Flashbuider ?
- Reusability. Do we plan to reuse existing client components ? Are we developing a project where we will not only implement target mobile devices but also intranet/internet based functionalities ?
- Can we still cope with performance restrictions ?.It is not necessarily obvious that a "less smooth scrolling list" would be a killing argument to discard Flashbuilder if the App is still providing data within an acceptable response time range, and, more important, if the relevant business information is brought to the user in an acceptable way in terms of content and time to market.
The overall scope of a project is therefore the main element of decision (as usual).
Complexity aspects.
After the well known "hurray effect" when the first Flex/Flashbuilder hello world application appears on your Ipad or Iphone, consider a more careful evaluation period to identify the logic and components that you are going to use on one side, and the navigation (user interaction) on the other side.
As we all know, mobile application runs with different user interaction mechanism if compared to Desktop or web based solutions. In this respect, you probably will have to identify first what may be reused (in terms of individual components) and also review and re-design the navigation and user interface before you start deploying your corporate Flex based accounting system on the ipad.
Service integration example and target audience
In order to get a closer look on how we can integrate services in Flashbuilder and also use these for WEB based and Mobile applications, I will describe in the following part of the document a simple implementation case study where we are going to show how to create and integrate a simple remote Java service using AMF as transport protocol. In a separate document, I will describe more in details the same approach using a SOA based service and JMS Messaging for Mobile applications). The overall principle remains however the same.The target audience here include also readers not necessarily familiar with Flashbuilder.
Although the following part of the explanation will be supported with implementation samples, this document is mainly targeting readers that are not focusing only on pure programming aspects but are interested in having a practical introduction and a first overview on how Applications written with Flashbuilder can be integrated within an existing corporate information system (in particular used for visualization purposes).
For this reason, and for the sake of explanations, the code examples will be kept as simple as possible in order to be understood, as far as the overall approach is concerned, also by readers not necessarily involved in programming activities.(I apologize with Flex/Flashbuilder evangelists, this paper is not meant to actually show you something new in this respect).
Last but not least. I will not re-write another set of tutorials on the subjects since there is quite a number of excellent material on both Flashbuilder and XCode/Objective C on the internet (available in particular on each respective vendor site).
I will not cover for example installation or configuration procedures for the various frameworks and development environment (i.e. for Flashbuilder, Eclipse or XCode) but simply refer to where you can find the required information.
Unless explicitly indicated in the explanations that will follow, the sample code can be used for both Mobile and non Mobile Flashbuilder client implementations.
A simple BlazeDS/Spring service for Flashbuilder
Note: I assume here that you have set up BlaseDS within a J2EE Application server. For space reasons, and since this would bring us out of scope, I omitted all the related BlazeDS/Spring configuration and installation details. You may find however quite a number of excellent documentation on the internet . You may for example refer to this tutorial to get additional information on the subject and get started with a sample running configuration.
Our business case data will be based on Customer information (instead of a classical "Employees" case study) that we will define using a standard java class (called Customer.java):
package ch.btconsulting.flex.spring.tutorial;
import java.io.Serializable;
public class Customer implements Serializable {
String id;
String name;
String country;
long totalInvoiced;
public Customer(String id, String name, String country, long totalInvoiced) {
super();
this.id = id;
this.name = name;
this.country = country;
this.totalInvoiced = totalInvoiced;
}
public Customer(){
}
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getCountry() {
return country;
}
public void setCountry(String country) {
this.country = country;
}
public long getTotalInvoiced() {
return totalInvoiced;
}
public void setTotalInvoiced(long totalInvoiced) {
this.totalInvoiced = totalInvoiced;
}
}
In order to bring customer data to our Flashbuilder client application, all we need now is to define a service (exposed in the example below with the name "myFirstServiceForFlex") and implement a method (getCusotmerList) that will be directly invoked by the Client.
package ch.btconsulting.flex.spring.tutorial;
import java.util.ArrayList;
import java.util.List;
import org.springframework.flex.remoting.RemotingDestination;
import org.springframework.flex.remoting.RemotingInclude;
import org.springframework.stereotype.Service;
@Service ("myFirstServiceForFlex")
@RemotingDestination(channels={"my-amf","my-secure-amf"})
public class CustomersService {
@RemotingInclude
public List getCustomersList(){
List returnValues=new ArrayList();
// extract here the customers from the database and put the data in returnValues
returnValues.add(new Customer("0001","ACME corp","Switzerland",12000));
returnValues.add(new Customer("0002","ACYOU ltd","Switzerland",10000));
returnValues.add(new Customer("0003","ACME & Co","USA",40000));
returnValues.add(new Customer("0004","TestCorp","Germany",20000));
returnValues.add(new Customer("0005","LosCompaners ltd","Spain",25000));
return returnValues;
}
}
As you may have noticed, I simplified here the data access part by using hardcoded information in order to fill the return List with Customer sample information.
That's basically all we need as far as our server (and java part) is concerned and we can now fully focus to the client side of the story.
Simple Flashbuilder WEB client implementation
Without getting in too much details, readers not yet familiar with this technology should retain that client applications in Flashbuilder are usually written using a mix of MXML (a "short-cut" declarative language) and Actionscript (a powerful object oriented language - close to Java as far as the syntax is concerned). MXML declarations and Actionscript are usually mixed within the same source code as reported in the example here below.
The following code would run on any WEB browser where the Flash-Player is available (again, I recall here that this will not be required in the mobile version of the example).
In order to use the above Java service on a Client and render on the Browser a simple list of customers (ID + customer Name in the example) we can use the following code:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
width="100%" height="100%" minWidth="955" minHeight="600"
creationComplete="initCreationComplete();">
<s:layout>
<s:VerticalLayout paddingBottom="20" paddingLeft="20" paddingRight="20" paddingTop="20"/>
</s:layout>
<fx:Declarations>
<s:RemoteObject id="BTCSPRINGSERVICES"
endpoint="http://localhost:8080/BTCSpringServerTest/messagebroker/amf"
destination="myFirstServiceForFlex">
<s:method name="getCustomersList" result="resultFinListHandler(event)" />
</s:RemoteObject>
</fx:Declarations>
<fx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import mx.rpc.events.ResultEvent;
[Bindable]
var resultServiceData:ArrayCollection=new ArrayCollection;
public function initCreationComplete():void{
BTCSPRINGSERVICES.getCustomersList();
}
private function resultFinListHandler(event:ResultEvent):void
{
resultServiceData = event.result as ArrayCollection;
}
public function myLabelFunc(item:Object):String {
return item.id +" "+ item.name;
}
]]>
</fx:Script>
<s:List id="myList" width="443" dataProvider="{resultServiceData}" labelFunction="myLabelFunc">
</s:List>
</s:Application>
The only code required in order to access the remote service is therefore the following :
<s:RemoteObject id="BTCSPRINGSERVICES"
endpoint="http://localhost:8080/BTCSpringServerTest/messagebroker/amf"
destination="myFirstServiceForFlex">
<s:method name="getCustomersList" result="resultFinListHandler(event)" />
</s:RemoteObject>
Where endpoint contains the url allowing to reach the BlaseDS message dispatcher on the server.
You may also notice, if new to Flashbuilder, that I could directly reference in the code the remote java field names and this without any additional variable declaration (item.id and item.name in the example) since the marshalling/unmarshaling process (and data mapping) are transparently solved by the framework. This facilities are independent from the nature of the underlying service protocol (RemoteObject) used. XML data for example can also be directly manipulated via dot notation.
Assuming for example that the remote service was accessing a SOA compliant Web Service, we could basically replace (or add if we would need to access both kind of services) a declaration similar to this one :
<mx:WebService id="webService"
wsdl="http://localhost:8080/WS/CustomerWebService?WSDL">
<mx:operation name="getCustomersList"
resultFormat="object"
result="resultFinListHandler(event)"
/>
</mx:WebService>
In this case, we could simply invoke
and directly get in the list the data coming from the SOA based WebService (reachable at the url specified in the wsdl variable).webService.getCustomersList
The remaining part of the implementation (assuming of course that the web service would deliver a list of Customers with an id and a name would remain exactly the same.
Note to Flasbuilder evangelist: This is quite trivial and natural for a Flashbuilder developer, but believe that this implicit data mapping and service integration is not necessarily available out of the box, and with the same degree of simplicity, on other programming environments :-)
If new to Flashbuilder, retain therefore the following :
- The code inside the Script declaration block (CDATA) is actually Actionscript. Actionscript is used to extend/complete client implementation logic and in our case in order to cope with the results delivered by the RemoteObject service call (via resultFinListHandler), in order to immediately call the remote service as soon as the application is loaded on a web Browser (initCreationComplete()) and in order to format the List content (myLabelFunc).
- Besides Methods, we can use the Script blocks to define local variables. (such as the resultServiceData in the example
- ArrayCollection are actually similar to the Java equivalent in terms of functionalities
- Data mapping and marshalling/unmarshalling are implicitly and transparently solved within the framework allowing for example to basically achieve a one to one mapping with remote Java (or PHP) objects.
The above example is implemented using a very simple and rudimentary form of a List .Thsi was of course not necessarily the best looking option (a standard Datagrid for example would have been more appropriate). In order to keep the examples as simple and as short as possible, I omitted to use itemRenderers.
On the other hand, in order to use a Datagrid instead of a list, the code would have been very similar and actually easy to change. More precisely, we would simply need to replace (or add if we need both):
<s:List id="myList" width="443" dataProvider="{resultServiceData}" labelFunction="myLabelFunc">
</s:List>
with :
<s:DataGrid id="myDg" width="443" dataProvider="{resultServiceData}" >
</s:DataGrid>
and the resulting difference is shown in the following image:
Here again, Flashbuilder newcomers may notice that the Datagrid, as a default, would reflect the remote Java customer data structure without the need for specific additional mappings. (and if we would need to format, manipulate or add visual effects we could of also use quite a number of additional build in or customizable facility to render the data - not covered however in this document)
Using a data driven event approach
As we now know, we can easily use standard enterprise protocols in order to retrieve and integrate corporate information within Flashbuilder Clients.
Another interesting and powerful facility that I will shortly cover in this paragraph is related to the "binding mechanism" used for the data propagation among visual components as reported in the following diagram:
Bindable variables (like we declared the resultServiceData variable in our previous example) are used to collect the result delivered by a given service call (or local processing of information) and are allocated to one or more visual components (like our List, Datagrid) as dataprovider.
The propagation and visual component notification upon state changes arising in a bindable variable to all visual components where the variable is declared as a dataprovider arise immediately and transparently for the developper.
Example :
<s:DataGrid id="myDg" width="443" dataProvider="{resultServiceData}" >
</s:DataGrid>
Any change arising in the resultServiceData ArrayCollection will be immediately reflected in the rendering process of the Datagrid. In this respect, the developper does not need to care or cope about refreshing or updating the visual components as such, but simply ensure that the relevant data is stored in the ArrayCollection.
By calling for example the Service XYZ in the diagram at regular interval (concretely: a simple call of the BTCPRINGSERVICE.getCustomerList() method using a timer based component) the results would be a visual refreshing of list, datagrid , charts or whatever other visual component bound to resultServiceData)
I am not covering in this article the Messaging facilities available in Flashbuilder Clients (i.e. Message Producers and Consumers that can be bound to remote JMS services). It may be however interesting to be aware that these facilities are also available and allow to apply push technologies where client visual component may be notified and directly refreshed by events arising on a remote server messaging based service.
Adding a chart component
Before getting to the final mobile implementation, we cover in this paragraph aspects related to how to add an additional flashbuilder visual component to our client application. As mentioned above, and since a chart component is a standard visual component, the task, besides the specific declarations allowing to specify what we would like to see on the chart, consist in defining which dataprovider to use. Nobody will be surprised to ear that we are going to share the bindable variable called resultServiceData
And here is the additional code required:
...
<s:SkinnableContainer width="688">
<s:layout>
<s:VerticalLayout/>
</s:layout>
<mx:ColumnChart id="myChart" dataProvider="{resultServiceData}" showDataTips="true" width="100%">
<mx:horizontalAxis>
<mx:CategoryAxis
dataProvider="{resultServiceData}"
categoryField="name"
/>
</mx:horizontalAxis>
<mx:series>
<mx:ColumnSeries
xField="name"
yField="totalInvoiced"
displayName="totalInvoiced"
/>
</mx:series>
</mx:ColumnChart>
<mx:Legend dataProvider="{myChart}"/>
</s:SkinnableContainer>
...
You may also notice that besides the dataprovider declaration the additional parameters (i.e. the Xfield, YField to be considered for the Chart) are directly referenced with the remote java filed names and via dot notation.
And here is the screenshot result on a browser:
Nothing new or spectacular actually. Retain however that the chart component is a also a visual component and therefore fully interactive for the user (see also a similar running example at the beginning of this paper). In the example, the bar charts may also react to user events (user tap on an ipad or iphone) and drive additional logic or navigation.
Let's get Mobile !
Now that we have invested time in order to get the WEB component up and running on our Browser, our boss would like to see list and chart on is brand new Ipad. And this may make the difference in terms of overall projects requirements. We all agree that re-writing the same functionality with Objective C would probably take some time starting with looking for an IT-Resource familiar with XCode and Objective C (you may still try to call me if you wish).
We may argue about the look and feel, about missing native facilities or whatever advantage provided by an XCode implementation but in our specific case, we actually need now roughly 5 minutes to get the mobile version of this example, make our boss happy, and, not to be underestimated, our backoffice staff also can use the same component via browser on the intranet or on the internet,
The Ipad/Iphone version of this example is therefore basically (almost) one "click" away now.
We need to create a new Mobile Flashbuilder project and within this project create a dedicated view.
By cut & paste we can now reuse the code written so far and the resulting view implementation is the following:
><?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:s="library://ns.adobe.com/flex/spark"
creationComplete="view1_creationCompleteHandler(event)" title="BTC SAmple Ipad Flashbuilder Charts Demo">
<s:layout>
<s:VerticalLayout/>
</s:layout>
<fx:Declarations>
<s:RemoteObject id="BTCSPRINGSERVICES"
endpoint="http://localhost:8080/BTCSpringServerTest/messagebroker/amf"
destination="myFirstServiceForFlex">
<s:method name="getCustomersList" result="resultFinListHandler(event)" />
</s:RemoteObject>
</fx:Declarations>
<fx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import mx.events.FlexEvent;
import mx.rpc.events.ResultEvent;
[Bindable]
var resultServiceData:ArrayCollection=new ArrayCollection;
public function initCreationComplete():void{
BTCSPRINGSERVICES.getCustomersList();
}
private function resultFinListHandler(event:ResultEvent):void
{
resultServiceData = event.result as ArrayCollection;
}
public function myLabelFunc(item:Object):String {
return item.id +" "+ item.name;
}
protected function view1_creationCompleteHandler(event:FlexEvent):void
{
initCreationComplete();
}
]]>
</fx:Script>
<s:SkinnableContainer width="100%" height="20%">
<s:List id="myList" width="80%" height="100%" chromeColor="#651A1A" color="#BB9191"
contentBackgroundColor="#400909" dataProvider="{resultServiceData}"
labelFunction="myLabelFunc">
</s:List>
</s:SkinnableContainer>
<s:SkinnableContainer width="100%" height="80%">
<s:layout>
<s:VerticalLayout/>
</s:layout>
<mx:ColumnChart id="myChart" width="100%" height="60%" dataProvider="{resultServiceData}"
showDataTips="true">
<mx:horizontalAxis>
<mx:CategoryAxis
dataProvider="{resultServiceData}"
categoryField="name"
/>
</mx:horizontalAxis>
<mx:series>
<mx:ColumnSeries
xField="name"
yField="totalInvoiced"
displayName="totalInvoiced"
/>
</mx:series>
</mx:ColumnChart>
<mx:Legend dataProvider="{myChart}"/>
</s:SkinnableContainer>
</s:View
Not that different than the WEB version right ? (I admit however at this point that the look and feel would require additional work but still, we got chart and data on a mobile device now).
I applied only minor resizing and color changes to the code but relevant for us is the fact that service call, list and chart remains the same.
In a productive mobile application, it is clear that there would be much more efforts required in terms of user interface, look and feel and navigation. On the other hand, we need to get our boss satisfied and, if we are lucky, he may very well cope, and maybe probably primarily interested with the fact that he would be in a position to access his corporate data anytime and anywhere.
The aim of this paper was, and I hope I could at least achieve part of the expectations, to show, and make aware, the an approach such as the one currently followed by Adobe is in any case promising not all for the mobile area, but also and in particular for the overall project development lifecycle.
In a second article currently under preparation, I will demonstrate the access of our remote service using XCode and "Objective C" and by describing this time functionalities that are not yet available in the Adobe Flashbuilder environment.
Thank you for your attention and please feel free to contact me for any comments, suggestions, projects offer or feedback.
Fabio Trentini, BTC Business Technology Consulting, Dübendorf July 2011