If your data coming from the backend is always the same structure and all the properties of your value objects are populated, the following gotchas probably won’t apply.  For me, I’m working with some complex objects that can have a lot of data associated with it.  Because of that, the objects returned from the server can have different amounts of data populated.

Let’s say you’re working with Contacts again.  If your contact table had the following fields that matched to basic properties of your value object, you’d be fine.

contactId, firstName, lastName, phone, email, street1, street2, city, state, zip

But what if your object was a little more complex, like this:

contactId:int
firstName:String
lastName:String
phone:String
email:String
address:Address
notes:ArrayCollection of potentially long Strings
purchases:ArrayCollection of Purchase
referrals:ArrayCollection of Contact

Now, the API for the database might need to have more than a simple getContacts call.  Maybe you need a getSimpleContacts that just populates the id, name, and contact info.  This would be useful for getting the list of your contacts to put in a list.  Then when you select a contact, you could make a getFullContact call so that potentially large sets of data don’t have to be sent if they might not be needed.

If this were the case, you’d make the initial getSimpleContacts call to populate your list.  That would sync the objects to your data cache, with null values for the properties that are ArrayCollections.  Then as you select items, those null values would get overwritten with the real data in the cache.  Here’s the updateProperties method in the cache I’ve been using:

private function updateProperties(itemA:Object, itemB:Object):void
{
     for each (var property:Property in info.getProperties())
     {
          if (property.readable && property.writable)
          {
               property.setValue(itemA, property.getValue(itemB));
          }
     }
}

It simply copies the new data from the new object (itemB) to the cached object (itemA).  That seems simple and elegant.

If you have the multiple APIs I talked about earlier, this can pose a problem.  Let’s say you open the application, getSimpleContacts is called to populate the basic list, you select a couple which shows all the contacts information so you use the getFullContact API.  The Contact object comes back with all the fields populated.  You sync the contact object using the cache and all the values are copied over to the cached object.  This is good because now, the object in the cache is fully populated so wherever you use it in your application, you’ve already got all the data.  Maybe in the time since you called getSimpleContacts and getFullContact, the phone number was updated, so that is updated in the cached contact as well.

Now, you go back to your list and to be sure you get any contacts that have been added since you last looked at the list, you make the getSimpleContacts call again.  The contacts come back and you sync each one with the cache so any updates will be reflected in the cached contacts.

Do you see a problem with the updateProperties method in this case?  The simple contact objects will still have all the property definitions, but since the API only returns the basic stuff, the new object will have null values for notes, purchases and referrals.  The updateProperties method will copy those null values over, clearing those populated values you had.

As long as the API will never return null values for properties the API provides, you could add a check to the if statement that only does the copy if the new value is not null:

if (property.readable && property.writable && property.getValue(itemB) != null)
{
     property.setValue(itemA, property.getValue(itemB));
}

If the data your server provides has a dateModified field that gets updated whenever any property of the object changes, you could make a custom cache for that dataType that compares the dateModified values of the old and new data.  If the dateModified is the same, you can skip copying over the basic data, since all APIs retrieve that in our example, and just copy the last three properties that might be null.  You could check for nulls as well to further reduce the work involved.  Skipping all that data copying if you know it wasn’t modified might seem trivial for one object but imagine if you retrieved 1000 contacts and synced them all with the cache.  Skipping the copying for the majority of your data would vastly improve the time it takes to process all those objects.

If you’re working on an enterprise application like I am, you’ll most likely appreciate the performance improvement and the caching mechanism I’ve described.  When you’re working with really big data sets, every little bit of processing time saved on each item can translate to noticeable improvements in the performance of your application.  Mobile applications also benefit from any performance improvement you can give it.

Do you have other ideas on caching or performance improvements when dealing with large amounts of data?  I’d love to hear them in the comments.

Lets say you have an application that tracks contacts.  The Contact object has a number of properties and some of the properties are custom classes themselves, such as an Address class.  Your application displays the contact information for the contact and you bind the address view to properties of the address property, like this:

<s:Label id="street1" text="{contact.address.street1}"/>

At first glance, most people would think this is just fine.  But here’s the scenario where this becomes an issue:

Let’s say the contact application doesn’t cache the contact objects.  Instead, you just overwrite the original data with the updated data.  It’s fast and simple.  There is probably a var called contacts in a model that the rest of your application references to display information about the contacts.

You’re open the application and on startup, it fetches all the contacts.  You select one of the contacts to view all the details.  The label that displays the street binds to the contact you selected and displays the data.  Then your application fetches the contacts from the server again, in case someone else has made changes to the contacts.  This contact (we’ll call him Henry) lived on River Rd. but recently moved to live on Oak St.  While your application was open, someone else updated his address.  Now, when the application on your computer goes out and fetches the contact again, it replaces that object with the new contact object.  It’s the same information but a different object in memory.

Here’s where the problem comes into play.  The Label was bound to the street1 property of the address property of the original contact object.  That object still exists with the original address and street1 values, and the Label is still bound to it.  The new object that has replaced it happens to have the same name and contactId, etc. but ActionScript doesn’t assume anything so the label ends up showing out of date information even though you’ve fetched the updated information.

If the contact object was cached, what would end up happening is that the Label would bind to a property of the contact which was stored in the cache.  When the new object came back from the server, it would be sent to the cache to be syncronized.  The cache would find the contact object with the same contactId and copy values from the new object to the one already in the cache.  Any properties that are not base objects like String, int, etc. would need to be cached and synced as well.  So your Address instance associated with Henry’s Contact instance would be updated in the cache too.  That way, the Contact instance is always the same object in memory and the Address instance used for the address property would always be the same object in memory as well.

This method takes some more time to keep the objects up to date but makes it much simpler when it comes to referencing those objects throughout your application.  The flip side would be to do the basic swap of data, but use events to notify the rest of the application that things have changed and carefully deal with that change appropriately by reassigning references wherever needed.  That way would be much more complex on your part but could potentially be much faster than using the cache.

I was using an ArrayCollection to hold a collection of items. I had a custom sort applied since the items were typed objects that needed to be sorted according to certain, out-of-the-ordinary fields. In the sort method, I was comparing values and returning either -1 or 1.

return itemA > itemB ? -1 : 1;

From the docs for a compareFunction:

The method used to compare items when sorting. If you specify this property, Flex ignores any compareFunction properties that you specify in the ISortField objects that you use in this class.

The compare function must have the following signature:

         function [name](a:Object, b:Object, fields:Array = null):int

This function must return the following value:

• -1, if the Object a should appear before the Object b in the sorted sequence
• 0, if the Object a equals the Object b
• 1, if the Object a should appear after the Object b in the sorted sequence

To return to the internal comparision function, set this value to null.

I decided that instead of returning 0 if they were the same, I would just let it stick it below the item. No big deal.

Later, when checking to see if an item was selected, I used the contains() method to see if an item was in the ArrayCollection. I quickly noticed that it wasn’t finding my item, even when I knew it was in the list.  Stepping through the code, and diving in to the Flex framework classes, I found that the contains() method uses the custom sort compare method to compare the item you’re looking for with the items in the list. It determines it found the item when it gets 0 back from the compare function. Since my custom compare method never returned 0, it never found the item.

Knowing this also helped me optimize the compare method for finding items.  Instead of thinking just in terms of whether one item goes before or after another item (or at the same level), I could also think about the comparisons in terms of checking to see if itemA was itemB.

Here’s the scenario.  I created a custom component that contained a background rectangle for highlighting, a label to display the name of the item, a toggle button for expanding the item and a button for editing the item.  I won’t get into the specifics of what this component is for, but just stick to the high level concept.

[ [expandBtn:ToggleButton] [labelDisplay:Label] [editBtn:Button] ]

The component had a number of states:

[SkinState("up")]
[SkinState("over")]
[SkinState("down")]
[SkinState("upAndSelected")]
[SkinState("overAndSelected")]
[SkinState("downAndSelected")]

This is similar to the ToggleButton component in the SDK but didn’t need the disabled state.  I created mouseEvent handlers to take the rollOver, rollOut, mouseDown, mouseUp and click events so I could handle them appropriately, setting properties for the getCurrentSkinState() method to use and setting invalidateSkinState() after changing the properties.

In the components up state, I wanted just the label to show and then when the user hovers over the component, the expand and edit buttons show.  Using states, this is simple enough to accomplish in the skin for the component:

<s:states>
  <s:State name="up" />
  <s:State name="over" stateGroups="overStates" />
  <s:State name="down" stateGroups="downStates" />
  <s:State name="upAndSelected" stateGroups="selectedStates" />
  <s:State name="overAndSelected" stateGroups="overStates, selectedStates" />
  <s:State name="downAndSelected" stateGroups="downStates, selectedStates" />
</s:states>
...
<s:ToggleButton id="expandBtn" includeIn="overStates" .../>

<s:Label id="labelDisplay" ... />

<s:Button id="editBtn" includeIn="overStates" .../>

The ellipses indicate additional code that is irrelevant.

I added the click handlers for the buttons in the custom component so I could capture the clicks and dispatch my own custom event.

So this starts out looking fine.  The buttons show up when the mouse is hovered.  Great.  I click on the edit button and… nothing.  The click handler is never called.  Do you see why?

Hint: Because events like clicks travel the displayList, the surrounding component will react to the clicks of the buttons inside it too.

Ok, here’s the chain of events:

1. The user presses the mouse button down over the edit button.
2. The edit button gets the mouseDown and enters it’s down state (if it has one).
3. The surrounding component gets the mouseDown and changes it’s skin state to the down state.
4. The edit button is not included in the down state, so it is removed.
5. The user releases the mouse button.
6. The surrounding component gets the mouseUp and returns to the over state.
7. The edit button is included in the over state so it appears again.

Since the edit button wasn’t included in the down state, it never had a chance to react to a click event.  Click events occur when the user presses and releases the mouse button over a component and the edit button was not around for that whole chain of events.

Solution: Add the buttons into the downStates so they exist during the entire click action.  Problem solved.

Check out the AIR team blog to see their post on the subject.

Personally, I got the Motorola Droid for Christmas, and have been loving it.  I’m quite excited to have the opportunity to develop applications for my phone using technologies I already love and know so well.

Background

I had an ArrayCollection of custom classes called Build. Those Build classes each had an ArrayCollection another custom class, Item. Item is simply a class with properties key and value. The collection of Items is called metadata. In the Build, I created a getter to go grab the Item from it’s metadata with the key “STATUS”. This way, I can have the datagrid display the properties of each Build as well as the value associated with the metadata Item that has a key of STATUS. Make sense?

Problem

I’d receive a collection of Build objects back from a web service I was polling routinely. After the first call, I’d compare Build id’s and just update the existing Build with the updated information. The problem was, the DataGrid wasn’t showing the updates to the STATUS even though I could introspect with the debugger and see that it was getting updated.

Solution

I found that when I first created a Build instance, I was creating an ArrayCollection to hold the metadata and assigning listeners to watch for changes. I did that to keep it updated. After assigning the listeners, I would go about creating an ArrayCollection of Items and assigning that ArrayCollection to the metadata property of the Build. Did you catch that? My listeners were now listening to an orphaned ArrayCollection.

Moral

Be careful of when you create your properties and assign your listeners. I hope someone out there will be saved a few hours by this little tidbit.

1. Portability
2. Flexibility
3. Performance
4. Weight

Using these considerations, you’ll be able to develop more professional, usable components. Even if I don’t think I will use my component in another project, I like to use these principles.

Portability

This refers to the components ability to stand on it’s own. As you build it, keep in mind that you want to create a “black-box”. It should have properties and styles that define what data it works with and how it looks, but if it requires other components or data to be present outside of the component, you won’t be able to use it in other projects without those other things. This is bad form. It’s not that hard to keep your components portable, so just provide getters and setters or public vars that can be your interface to the outside world and you’re good to go.

Documentation also improves the portability of your component, although this depends somewhat on the complexity of your component. If it’s really straight forward, then putting the work into lots of asdoc documentation is just going to waste your time. Instead, document the code really well (if you’re distributing it as code) or write a web page describing the basic inputs and outputs of the component.

Flexibility

Flexibility is the ability another developer has to customize your component without digging through your code. If you expose the right properties and styles, another user will be able to easily set those things most often changed. I say “most often” because you don’t want to go overboard with this one. Just because something can be changed, doesn’t mean it needs to have a property exposed to change it.

Performance

This doesn’t take much explanation, but unfortunately, understanding the meaning of good performance doesn’t make everyone understand how to implement it. You have to look for ways to reduce processor cycles where it isn’t necessary. Look for places that the exact same mathmatical calculation is being done over and over. Make the calculation once, store the value and use that instead. If you have an understanding of how computers work, under the hood, this will be much easier for you.

The importance of performance is dependent on how much processing it’s going to be doing. If it processes some data once, then just displays it, then you will be more likely to get away with sloppy performance than if your component is meant to process thousands of bits of data every time the screen refreshes. One way to squeeze extra performance out of your component may be to use the “garbage-in, garbage-out” rule. That means removing some of that error checking code you have sitting around and providing the disclaimer with the component that error checking should be done earlier on.

Sometimes, you can ask yourself “how much processing does this require?” Then ask yourself, “how much processing should this require?”

Weight

The weight of a component refers to the memory footprint it has for every instantiation that exists. Similar to performance, you might need to examine what the most common use of your component will be. If it will be on the stage in one place and fairly static, then the weight won’t be as much of a concern as the case where your component will exist hundreds of times (such as in the case of an item renderer).

Something else to consider when looking to drop the weight is feature bloat. As I mentioned in the flexibility section, you don’t want to go overboard with features. Think about what most people will use your component for. A component that does 5 useful things is better than one that does 400 things that 99% of the users will never use. The component will end up carrying around all that extra baggage whether they get used or not.

When your component is an extension of another class, take the time to find out how base your base class can be. A common mistake is to extend Canvas or some other container to hold something simple. Containers like Canvas and VBox have code to draw scrollbars, layout children in certain ways, and other baggage that may not be needed for your use case. UIComponent is the base class for all Flex components. If you subclass anything else up the inheritance chain, you won’t be able to display it, so if your component is visual, see if you can get away with subclassing UIComponent.

You can get the widget from here: http://www.google.com/talk/service/badge/New

Update: I removed the chat widget after getting quite a few interruptions during my work day. �Word of advice, use with caution.

The thought process went like this: I wanted a search field that when I typed, the datagrid (or whatever the data was displaying in) would filter out the rows that didn’t match the search terms. FilterFunctions do just that, but they don’t work on the DataGrid or List directly, they work on the dataProvider. The dataProvider must implement ICollectionView to have a filterFunction applied to it. You can figure this out by searching for filterFunction and finding that it is defined in ListCollectionView. ListCollectionView defines the function because it’s in ICollectionView, which ListCollectionView implements. I programmed to an interface, not an implementation.

So, I extended the TextInput class and added a public property called dataProviderToFilter:ICollectionView that will take the dataProvider it needs to work on, and another public property called propertiesToSearch:Array that is an Array of Strings identifying the properties of the objects used for each row. It uses a no-arg constructor, which makes it available to use in MXML as well, just like the TextInput.

<theflexguy:SearchInput id="searchTxt" width="100%"
	propertiesToSearch="{['artist','album','description']}"
	dataProviderToFilter="{my8TrackCollection}"/>

Since I will probably use this a number of times, I’ll share it with the world. Once again, it’s not as hard as it seemed, which should be your mantra for Flex development.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

package com.theflexguy.controls
{
	import flash.events.Event;

	import mx.collections.ICollectionView;
	import mx.controls.TextInput;

	public class SearchInput extends TextInput
	{
		// dataProviderToFilter must implement ICollectionView so a
		//  FilterFunction can be applied to it.
		public var dataProviderToFilter:ICollectionView;

		// propertiesToSearch is an Array of property names as Strings
		public var propertiesToSearch:Array;

		private var _searchWords:Array;

		// Splits the search text up using spaces to get the "words",
		//  then sets the filterFunction
		private function searchTxt_changeHandler(event:Event):void
		{
			if (text != "")
			{
				// split up the input into individual "words", made 
				// upperCase so it's case insensitive
				_searchWords = text.toUpperCase().split(" ");

				// check to see if the last item is a 0 length String, this
				// would be the case if the last character typed was a space
				if (_searchWords[_searchWords.length - 1] == "")
				{
					// if it is "", remove it
					_searchWords.pop();
				}
				// set the filterFunction
				dataProviderToFilter.filterFunction = filterForSearch;
			}
			else
			{
				// the user removed the text so remove the filterFunction
				dataProviderToFilter.filterFunction = null;
			}

			// refresh the dataProvider
			dataProviderToFilter.refresh();
		}

		// Uses the searchWords array to search the summary and components
		//  fields of each row for each item in the array.
		private function filterForSearch(item:Object):Boolean
		{
			var match:Boolean = false
			for each(var s:String in _searchWords)
			{
				for each(var p:String in propertiesToSearch)
				{
					// check each property for the word using 
					// toUpperCase so it's case insensitive
					if (item[p].toString().toUpperCase().match(s))
					{
						match = true;
						break;
					}
				}
			}
			return match;
		}

		public function SearchInput()
		{
			super();
			addEventListener(Event.CHANGE, searchTxt_changeHandler);
		}

	}
}