Migrating an application to AIR, and Flex unable to resolve resource bundle

Not sure why but migrating from a web application to AIR I ran into a few issues

Flex AIR unable to resolve resource bundle

To do this, simply right click your project > properties > Flex compiler and add "-source-path ../locale/{locale}" to the Additional compiler arguments text field.  Hat tip.

Specifying startup height and width

Code Snippet

1. <!-- The window's initial width. Optional. -->
2. <!-- <width></width> -->
3. <width>1320</width>
4. <!-- The window's initial height. Optional. -->
5. <height>920</height>

Asset references

Shame on me for not refering to images, fonts, etc with an absolute path (relative to the flex src directory), e.g…

Code Snippet

1. <mx:Image source="@Embed(source='/../assets/some_icon.png')"/>

This also has the happy side effect of making the paths of these assets more sensible than the alternative crazy relative path approach, e.g. the above line replaced a line similar to the following…

Code Snippet

1. <mx:Image
2. source="@Embed(source='../../../../../../../assets/some_icon

ItemEditEnd broken for a dateField column

Here is a test case where the itemEditEnd does not fire even though everything seems to be hooked up.  This caused me some pain, until I took a look at the DataGrid.as source code and stepped through it in the debugger.  Even though rendererIsEditor="true",  in red below you still need to set itemEditor="mx.controls.DateField".   Why I needed this event is another story.   Hope that someone finds this useful.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application layout="horizontal"
    xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Script>
        <![CDATA[
            import mx.events.DataGridEvent;
            import mx.collections.ArrayCollection;
            [Bindable] private var _data:ArrayCollection = new ArrayCollection([{id: "0", name: "zero"}, {id: "1", name: "one"}, {id: "2", name: "two"}, {id: "3", name: "three"}]);

            private function onItemEditEnd(event:DataGridEvent):void {
                trace("onItemEdit");
            }
        ]]>
    </mx:Script>
    <mx:DataGrid alternatingItemColors="[#F7F7F7, #E9E9E9]"
        borderColor="#DFD9D9"
        borderStyle="solid"
        dataProvider="{_data}"
        editable="true"
        height="100%"
        id="dgProducts"
        itemEditEnd="onItemEditEnd(event)"
        sortableColumns="false"
        themeColor="#67B5E6"
        variableRowHeight="true"
        width="100%"
        wordWrap="true">
        <mx:columns>
            <mx:DataGridColumn dataField="name"
                editable="false"
                headerText="Product"
                width="60"/>
            <mx:DataGridColumn dataField="none"
                editable="true"
                headerText="License Key"
                width="60">
            </mx:DataGridColumn>
            <mx:DataGridColumn dataField="license_expiration_date"
                editorDataField="selectedDate"
                headerText="Expiration Date"
                itemRenderer="mx.controls.DateField"
                rendererIsEditor="true"
                width="60">
            </mx:DataGridColumn>
        </mx:columns>
    </mx:DataGrid>
</mx:Application>

Flex gantt chart project plan v.01

Flex gantt based on the sample code from ilog / elixir. The demo had a bunch of pitfalls, which I’ve tried to overcome

1. underling data model (collections) are not XML based. Seems to me that adobe relies on the xml data for alot of their proof of concept.
2. nested set library from pear php to persist the tree in the back end. There was a bit of heavy lifting and I ended up hacking the pear NestedSet.php
3. support for multiple trees (forest) in the nested set
4. ilog has bug in the constraints where the constraints do not refresh
5. highlighting the selected constraint
6. circular reference cycles in the directed graph using the tarjan algorithm from a previous post
7. When a parent constraint changes the move.
8. Database is sync’d for most interactions
9. supports a templatization, where the dates get bumped to the the current date + 7 for each template, so you can ruse a project.

After a bunch of thought early on, I decided to try to map nodes, constraints and resources with associated reservations to rows in the database. My thinking was to build it this way for a few reasons:

1. I didn’t want to have a corrupt xml and then have to go through the pain to of debugging it
2. support for future concurrency. While it’s not in my use case as of now, my thinking was that XML blobs in the database do not lend themselves to collaboration. Of course if I was to go with real time concurrency, I would need to think about a COCOMO option
3. templates and copying
4. I didn’t want to get in the situation where a user made bunch of edits and then app failed, or the persistence failed or the javascript saying “you need to save” because you just navigated away.

The real drawback to going away from xml is that there would be a bunch more heavy lifting to import/export to MS Project Plan

As you can tell, I may have chosen poorly.