Flex Pasta

2 1/2 years ago I published annotations for BlazeDS that allowed for placing tags on Java getters/setters to determine if a value is serialized to the Flex client.  Soon I will publish a 3 part BlazeDS extension that does the following(with annotations of course).

1. Serialization Profiles with BlazeDS - This was mentioned in a previous post and I will be releasing this soon along with the rest of the annotations code.
2. Mate Code Generator - More details to come, but if you are familiar with the Mate Framework, this code generator will create complete EventMaps/DataManagers/Events from Java services(and it runs for the life of the project).
3. Model Code Generator  - This isn’t the kind where a button is pressed once to create Flex remote object bean classes.  I don’t like code generators that only generate the file initially.  I also don’t like when a code generator creates generated code that then the developer must extend(ex: Customer extends _Customer).  I have created a code generator that does neither but still can be run endless times for the life of the project.  Here is an example output file.  The developer can add any code to the area marked as such in comments.  Every time the generator is run it will clear out the rest of the file and regenerate the properties from the matching Java class.
   /* File Generated by FlexPastaDomainGenerator v. 1.0
   * Only edit the file in the designated area.
   * All other changes will be lost
   */
   package com.company.model
   {[Bindable]
   [RemoteClass(alias=”com.company.model.Address”)]
   public class Address
   {
   public var country:String;
   public var lot:String;
   public var parcel:String;
   public var state:String;
   public var streetName:String;
   public var streetNumber:String;
   public var subdivision:String;
   public var uuid:String;
   public var zipCode:String;

   //**********EDIT AREA**********

   //**********END EDIT**********
   }
   }

Looks for more details in the coming weeks!

Progress Bars via the mx:ProgressBar tag are easy to use in Flex.  Unlike some kind of progress bars that can drive anyone insane….

Flex progress bars are easy to implement and great for usability.  When there is a long database query or chance for network latency, a progress bar is always a good idea to keep the user informed that something is happening.  Those with an artistic ability can create a custom progress image to use on a progress bar, but if not, the built in one is still a viable option.  There are two main types of progress bars included in the Flex SDK.  Ones that use percentages to show completeness and ones that use an indeterminate/unknown to give the user indication of activity.  Both are implemented in the mx:ProgressBar tag/class.

The percentage progress bar is used directly with the mode property, which has three options, event, polled, and manual.  This is used in conjunction with the source property which the progress bar can use to automatically update the progress bar.

Read the rest of this entry…

Up until the other day, when using modal and/or pop up windows in Flex, I have always instantiated them in Actionscript.  Since I use relative layout, I couldn’t really add an mxml component that would be a modal without it being drawn on the screen.  The advantages of declaring a modal in mxml would be:

• Taking advantage of mx:Metadata tags that allow me to invoke methods when events occur without manually adding listeners
• Automatic binding the same way my other components work
• Less code; by declaring the pop up window in mxml, I don’t have to invoke a method that creates an instance of the pop-up

Here is how you can declare a modal/popup window in mxml:

<mx:ArrayCollection id=”modals”>

 <MyPopupWindowComponent id=”modal1″ someBindings=”{bindingAVariable}” anEventThisComponentDispatchesInMetaData=”doSomething(event)”/>

</mx:ArrayCollection>

Now when you want to open the modal, just do PopupManager.addPopup(modal1,true,DisplayObject(Application.application));

This allows you to use the ease and power of bindings/metadata in modal windows.

A while back I did a post on the choppiness of mx:List scrolling and a mx:Repeater work around FTW(For the Win).  Well in Flex 4, the List component will be FTW out of the box!!!  Meaning, smooth scrolling item renderers!!  It looks like the Flex SDK team has spent some time improving the quality, scrolling, and layout of item renderers.  Here side by side are the examples from a Flex 3 List compared to the same code in a Flex 4 List.  Check out the difference!

Flex 3 List with Image Scrolling

Flex 4 List with Image Scrolling

Time travel between Flex, BlazeDS, and Java can be quite complicated to keep the three correctly in sync.  Time travel, aka remote objects that carry date members, can mean different things to each piece of software.  Java is very time zone aware, where as Flex is very time zone unaware.  Since time in Java, BlazeDS, and Flex is defined in milliseconds since 1970, it can mean translation via BlazeDS can result in inconsistencies.  How can this be?

Java

When it comes to time zones and daylight savings time, Java is very smart.   It uses the Olson Database to determine how to translate a time in milliseconds since 1970 into an actual date/time based on the current timezone.  The Olson Database knows when daylight savings time started and ended in each time zone each year.  If you remember, prior to 2007, daylight savings time in the United States started the first weekend in April and ended the last weekend in October.  But, it an effort to be more energy conscious, the government changed it to the second weekend of March through the first weekend in November.  Java knows about daylight savings time and time zones as they existed in the past.  Therefore, milliseconds since 1970 for a date of March 15th, 2006 in Java maybe different than on another platform.

BlazeDS

BlazeDS(and the Flex RPC library) translate time via AMF between Flex and Java.  It knows nothing about time zones or daylight savings time.  When sending a remote object that contains a date, it will be converted to date.getTime() - milliseconds since 1970.  BlazeDS is always translating dates in the present and has no understanding of the client and server’s time awareness.

Flex

Flex only knows about daylight savings time now.  Meaning, Flex will think March 15th, 2006 was during daylight savings time.  But in 2006, daylight savings time didn’t start until April so Java will have a different answer than Flex to milliseconds since 1970?  To be fair, it is not Flex or Flash that aren’t time zone savy.  It is the user’s browser and computer that are ultimately at fault.  The flash player will just pull the information from them.  Imagine if a user enters a date/time today(during daylight savings time).  At some point in the future, the government changes daylight savings time to start tomorrow.  After the change occurs, the date the user entered will be correct in Java(because Java knows of daylight savings time in the past), but will be one hour off when displayed in Flex.

Creating an identical date/time object in both Flex and Java can cause different results for milliseconds since 1970.  Take for example a user entering a birth date on a Flex form as March 15th, 2006 and another user entering a birth date as March 15th, 2009. The following screen shots show a simple Flex app with a date chooser and a label showing the time in milliseconds since 1970.

When the user selects March 15, 2009, the date is correctly translated to Java via BlazeDS as March 15th, 2009.  Notice that Java says EDT(Eastern Daylight Time).

Now look at the same test for March 15, 2006.

Notice for the March 15th, 2006 date translation is incorrect.  The date given to us via BlazeDS will actually be on March 14th at 11pm.  Java correctly identifies the time zone EST(Eastern Standard Time).  Java is correct.  Back in 2006, March 15th was during eastern standard time.  Because this date today is in eastern daylight time, Flex incorrectly reports milliseconds since 1970 to a number off by one hour.

Now the incorrect birth date is put in the database as March 14th!!   Want to run a query to find all people born on March 15th, 2006?  That could be a problem.  There are several ways to solve this problem.  One might be creating a JustADate class that has year, month, day fields on it so BlazeDS will send it without using getTime().  Another option might be sending date only fields as strings to avoid the getTime() translation.  When working with dates in Flex, BlazeDS, and Java, be sure to consider time travel and its inconsistencies!

“Once confined to fantasy and science fiction, time travel is now simply an engineering problem.”   -Michio Kaku