Monday, March 17, 2014

Working with ColdFusion Offline AIR Features

I've recently started working on a new application. Based on the requirements, and having the freedom to choose the technologies involved, I decided it would be a good time to revisit the Offline AIR features that were introduced in CF9 (but for which I’m utilizing in CF10).

Although I've never finished an actual application using this feature, I did play around with it quite a bit when it was introduced. I was very impressed with it and always thought it was a bit underrated at the time. Although times have changed, if you’re still a ColdFusion and/or Flex developer (who still does either of those anymore, right?) you may still find this feature set to be pretty slick.

After not having looked at it in a few years, I needed to go through the documentation to refresh myself on how it all works and was, unfortunately, reminded on how poor the documentation was. So I’m posting this as a reminder to myself on how to accomplish a few things.

Issue #1: Specifying target entities when defining client side relationships.

This is absolutely nowhere to be found in the documentation. Even the full application example code doesn't show how this done. The example code assumes that all your entities are in the root of the application (which is never the case), and therefore, show the syntax of specifying a target entity like this:

[OneToMany(targetEntity="Department", mappedBy="department")]
public var depts:ArrayCollection;


If the 'Department' entity was in the root of the application, that'd work perfectly. But since it's probably not, you’d assume you just specify the fully qualified class name with package structure as the value. That’s close, but doesn't quite work. The actual syntax would be something like this:

[OneToMany(targetEntity="com.domain.application.model::Department", mappedBy="department")]
public var depts:ArrayCollection;


Notice the double colons separating the package path and the class name. Again, that syntax is nowhere to be found in the official documentation.

Issue #2: What to specify for the mappedBy attribute in the relationship metadata.

The code example above demonstrates the OneToMany relationship as defined in an Employee entity, between an employee and departments (assuming an Employee can belong to many Departments – which is usually the other way around – and just makes the example even more confusing - but I digress). 

Yet, it never really explains what the value "department" is referring to in the mappedBy attribute. And if you were to try and figure it out by studying the example code, it would only confuse you more because the code is wrong. 

The mappedBy attribute is intended to refer to the property in the targetEntity (Department) that maps the inverse (ManyToOne) side of the relationship. That's my definition… not a definition you'll find anywhere in the documentation. Based on the code above, it would expect a property in the "Department" entity, named "department" which refers to an employee. That's obviously a documentation bug and should probably be written as:

[OneToMany(targetEntity="Department", mappedBy="employee")]
public var depts:ArrayCollection;

More issues to come?

I'm sure I'll run into more documentation issues as I get further in development and will update this post as they occur.

Thursday, September 12, 2013

Problem with Flex modules, custom theme, and global CSS selector

Maybe I've never used all three of these concepts together in the same application before (or maybe I have, but have forgotten about this problem). In any case, I’m posting this to remind myself in case I run into this issue again… or in case I’m just doing something wrong and any of you know what needs to happen.

Modules inherit styles from the main application. If your main application contains a global CSS selector, modules inherit those styles as well. However, if you’re styling your application using a custom theme, and your theme’s CSS file uses a global selector, modules do not inherit the styles in your theme’s global selector (but they still inherit the other styles in your theme’s CSS).

The work-around I’m currently using is moving my global selector of styles from the theme’s CSS file to my main application’s CSS file. Although, that seems to defeat the purpose of making a custom theme.

UPDATE:
I came across a good solution. Simply apply the theme to each of the modules. I don't think it's intentional that you have to do that (or maybe it is, who knows) but it works well. And as long as you're properly optimizing the modules (whether using your IDEs built-in module optimizations or doing it manually with -load-externs config) the theme doesn't appear to add to the module's file size.

Friday, August 16, 2013

Using Inkscape to generate FXG from Illustrator CC

When building Flex applications, I often use Illustrator to prototype and design parts (if not all) of it, and therefore, make use of Illustrator’s FXG export quite a bit. If you’ve upgraded to Illustrator CC, you may have noticed that FXG (both import and export) are no longer available. From what I’ve read, it’s also missing from Flash Professional CC (and I’m assuming Photoshop CC too).
This, obviously, has broken my workflow and has made designing Flex/AIR apps much more difficult for me (something Adobe has a great track record of lately). But rather than going on a rant, I thought I’d investigate some alternatives. The most obvious alternative is to downgrade to Illustrator CS6, but I wanted to see if there were any ways to generate FXG from documents created in Illustrator CC.

When searching the interwebs, a couple users suggested copying the content to Fireworks CS6 and exporting to FXG from Fireworks. I've never been a Fireworks user, and so I did a bit of research on that workflow before attempting the download and install, only to find other reports of Illustrator CC content can no longer be copied to Fireworks. Some people reported that Illustrator CC content can be copied to Photoshop CC, and then copied from Photoshop CC to Fireworks CS6, but that a lot of vector data was lost and converted to bitmap data somewhere in the process. With this information at hand, I decided to not waste my time testing it out for myself. If anyone else has had success with these workflows, please let me know!

I then came upon an open source vector application called Inkscape that has the ability to export to FXG. I’ve heard of this application in the past (I think it may have some popularity in Linux environments) but have never looked at it until now.

As an Illustrator user, when running the program for the first time, I could definitely tell that it would be a downgrade from Illustrator and probably not something I’d want to switch to for my day to day work (reminds me a lot trying to use Gimp as an experience Photoshop user). Nevertheless, I was strictly interested in it’s abilities to export FXG (and open my Illustrator CC files for FXG exportation).

The current stable version of Inkscape, at the time of this writing, is 0.48, and the FXG save option was nowhere to be found. After investigating further, I found the FXG option to be in later development versions, and found it in the bleeding edge version here. The download site is in German, so Google translate might be of some help.

After seeing the AI option available in the open dialog, and the FXG option available in the Save dialog I first tested the ability to open some of my CC created AI files. The first thing I noticed (which was not all that obvious) was that it could only open Postscript-based .ai files. This was easy to accomplish by opening my content in Illustrator and resaving with the “Create PDF Compatible File” option turned on in the save dialog. For simple things, Inkscape opened and exported to FXG flawlessly. In fact, the FXG it generated appeared to be better optimized than what I remember Illustrator CS6 producing. Even better was the fact that it generated FXG without all the namespace junk that Illustrator injected… and required you to remove before using in your Flex application. In other words, I was able to use the Inkscape-generated FXG file, without any modifications, directly in Flex. This, alone, would speed up my workflow even when adding in the extra time it takes to bring my content into Inkscape to be saved as FXG.

I was then curious as to how well it could handle very complex Illustrator files. I decided to do some tests using some Illustrator source files from the Illustrator Showcase in the “how-to” section. The first few files I tried ended up being a bit too complex for Inkscape to handle… either crashing the program when trying to open them, or crashing when trying to save as FXG. I didn’t see this as big issue, for these are much more complex then anything I’d ever put in a Flex skin file.

I then tried out the fourth (much simpler) example. This one was only a 2MB source file compared to the first three that ranged from 19 to 100MB .ai source files, but was still much more complex than any FXG skin I would ever put in a Flex app. That test worked pretty well. The results of the compiled FXG in the Flex app can be seen here. The only noticeable changes I could detect was the vertical gradient being changed to a horizontal gradient, and some of the text at the bottom is garbled. I also had to remove a line of FXG that appeared to fill a rect with a bitmap that was imbedded in the FXG file, and preventing it from compiling.

All in all, I was very satisfied with the results and willing to incorporate Inkscape into my new workflow.

Friday, August 9, 2013

Resolving IntelliJ Resource Bundle Inspection Errors in Flex Projects

Since switching from FlashBuilder to IntelliJ IDEA (which I’m loving so far) I sometimes come across things that need tweaked a bit. One such thing is inspection errors in the SDK source files where resource bundles are used. Inspection errors don’t necessarily mean that the code won’t compile (although many times it does mean that) but that the IDE can’t make sense of it. In the case of resource bundles, IntelliJ looks for them within source directories, even though they don’t need to exist in source directories to be compiled into the application. Because of this, you often get ugly red marks in your editor when viewing SDK source code.

image

The easy way to remove these inspection errors is to add an SDK classpath pointing to the bundles directory in the Project Structure / SDKs window. In my case, I needed to add a classpath to:
D:\Projects\Flex SDKs\4.10 - AIR 3.8\frameworks\projects\frameworks\bundles

image

Tuesday, June 4, 2013

Flex Job Opportunities Available in Denver, CO and Rochester, NY

The company I work for, Paychex, is hiring Flex developers in the Rochester, NY and Denver, CO offices. They’re accepting both fulltime and contract developers. And no, this isn’t one of those – we need Flex devs to help convert our apps to HTML5 – jobs. Paychex is one of the few large business left, that I know of, that are invested in Flex and will continue working with it for at least 2-3 years.

If you’re interested and located in one of those areas (or willing to relocate) send me an email and I can put you in touch with the right people.

Wednesday, May 15, 2013

Flex SkinnableViewStack Component

The SkinnableViewStack is nearly identical to my ViewStack component except that it extends SkinnableContainer, rather than my DeferredContentGroup, to support skins.

My use-case for a skinnable version of the ViewStack is when defining views or components that need to have ViewStack-like functionality, but also include chrome (think of a wizard component). One could simply define a SkinnableComponent with a ViewStack as a skin part, but the component user wouldn’t have access to the ViewStack API outside the SkinnableComponent.

This SkinnableViewStack implementation replaces the Group-based contentGroup skin part with my Spark ViewStack component and then proxies the ViewStack API to the contentGroup.

I’ll post some example uses of this component soon.

Source  code located at: https://www.assembla.com/code/shinynet/subversion/nodes

Friday, May 10, 2013

Flex Spark ViewStack Implementation

Awhile back, I created a GroupStack as a quick and dirty Spark implementation of the ViewStack I needed at the time. I've recently needed a more complete implementation of a Spark ViewStack for a project, particularly with support for deferred content creation and some of the other features left out of the GroupStack.

This version of the ViewStack is very close to a direct port, containing most all of the features and API from the Halo ViewStack. It’s based on Group (more specifically, my DeferredContentGroup which extends Group) due to my desire to substitute the contentGroup skin part (of type Group), found in many skins, with a ViewStack. The three features I did not port over is the support for history management, resizeToContent, and the usage of effect overlays. And, as with the rest of my library, it’s not that well tested, so be sure to let me know if you’re using this and you find some problems.

Source  code located at: https://www.assembla.com/code/shinynet/subversion/nodes