Give us a call 203-379-0773

Calendar Styling - 5/28/2010 - Episode 63 - Flextras Friday Lunch

In this session, I show some code behind a custom dayRenderer for Flextras Flex Calendar. We chat about The Flextras AutoCompleteComobBox, ASDocs, and Elips Studo.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

Why won't my ASdocs Copy?

This post comes from the monthly Flextras newsletter. While we were finishing up the Flextras Calendar, we wrote over 27 pages of ASDocs. I was presented with an interesting issue with ASDocs.

What are ASDocs?

ASDocs, if you're unaware, are special blocks of code you write in your Flex files that can be run through a command line utility to generate an API Reference. The API References you use for the Flex Framework are generated by the ASDocs tool, for example.

ASdocs look like this one, from the changeMonth method of the Flextras Calendar:

/**
* A method to change the month based on the specified increment.
* You can use a negative value to go back in time or a positive value
* to go forward.
* Only has an effect if in the MONTH_VIEW state.
*
* @param value The increment value used to change the month; the
* default is 1.
*
* @see #MONTH_VIEW
*/

The ASDoc are placed before elements in your files, such as properties or method and when you run the ASDoc tool it picks up the text and adds it to the generated ASDocs files.

In the ASDocs segment above you see two ASDoc tags, @param and @see. These tags give special instructions to ASDocs. The @see tags add links to other elements of the API, other classes, or even URL links. The @param tag defines the parameter to a method, and they are given a special place in the ASDoc output.

The @copy tag?

Our Calendar supports most elements of the List class API and the DateChooser API. The Calendar extends ListBase, so most of the properties are inherited. The DateChooser properties, such as firstDayOfWeek, monthNames, or dayNames are implemented as if they were brand new.

We thought instead of writing new documentation for these properties, we could use another ASDoc tag--@copy--to just copy the documentation from the DateChooser class into the Calendar class. The code looked like this:

/**
* @copy mx.controls.DateChooser#firstDayOfWeek
*/

This seemed logical to us, but for some reason the ASdocs wouldn't copy; and the documentation in our generated file was blank for those copied properties. What was the problem?

It turns out that the DateChooser is never used anywhere in our Calendar. As such, the Flex Compiler will automatically optimize the class right out of the SWC file. This is good because it keeps file size low and you do not have to distribute unnecessary classes. Unfortunately, it seems to the ASDoc appears to use the same approach. DateChooser wasn't in the API, so therefore the ASDoc utility couldn't find the DateChooser code in order to copy the appropriate ASDocs from one place to another.

The Solution Part 1!

One solution, and I hated doing this, was to create a dummy variable of the DateChooser type:

private var temp : DateChooser;

Then all was well and the properties would get documented as expected. I don't like this because it artificially inflates the size of the SWC. Thankfully there is a better solution.

The Solution Part 2!

The ASDoc command line tool supports many of the same command line arguments that the Flex compiler supports. We can use the include-libraries argument and point it at the framework SWC. This will make all classes in the framework available to the ASDoc compiler whether or not they are used.

For practical purposes, you want limit your use of this argument when creating swfs for wide release. But, none of that matters when generating ASDocs.

Conclusion!

Did I mention that the Flextras Calendar is out? It supports Flex 3 and Flex 4 and you can download a free developer edition to test it out.

Calendar Release - 5/7/2010 - Episode 61 - Flextras Friday Lunch

In this session, I demonstrate the final Flextras Calendar for the first time.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

  • Watch Original Recording
  • Calendar API Explorer
  • Subscribe

    Contact

Flextras Friday Lunch - Episode 50 - 2/19/2010 - Flex Calendar Component Architecture

In this episode I talk about how the architecture of our Calendar Component for Flex. After 9 months in development, the release is finally coming closer. For some reason I introduce the date as November instead of February; sorry about that.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

How do you tell if a component is in a transition?

I'm working on Fleshing out the Flextras CalendarDisplay component. I think I'm finally happy with our approach to implementing a day view. One of the things we want to support is the ability to transition between a month view, a week view, and a day view.

Transitioning from a day display to a month display was working fine. Transitioning from the month to the day was not. After stepping through the code I discovered that the updateDisplayList() method would resize the day before the effect ran, thus negating the effect.

I needed a way to figure out if a transition was playing and tell the component not to run the updateDisplayList() method.

I've seen some situations where you set a Boolean value "transitionRunning" to true before running the play method, then set it back to false in a listener to the effectEnd method.

But, that wouldn't work in this situation. If the transition is a transition between two states, then all the code for starting / stopping the effects is locked up in private methods of UIComponent.

I ended up writing this method to loop over the transitions array and figure out if one of the effects was playing.

protected function isTransitionPlaying():Boolean{
if(this.transitions){
for each(var transition : Transition in this.transitions){
if(transition.effect.isPlaying){
return true;
}
}
}
return false;
}

My intuition tells me there should be an easier way, but I'm not sure what that is.

Update:

A friend on twitter recommended I take a look at the activeEffects property. The function would be modified like this:

protected function isTransitionPlaying():Boolean{
if(this.activeEffects.length >
0){
return true;
}
return false;
}

Unfortunately, that didn't work. Even though a transition was running, it was not on the activeEffects array. I'm unsure why.

Understanding the Flex Component LifeCycle Methods

Lately we''ve been getting a lot of questions about the proper way to use the methods in the Flex 3 Component LifeCycle. I wrote about this in the December Flextras newsletter and thought I'd turn it into a post here too.

The Flex Component Lifecycle is a set of methods and events that Flex uses to setup, size, and position the components that make up your Flex Application. There four lifecycle methods that you'll use when creating Flex Components: createChildren(), commitProperties(), measure(), and updateDisplayList(). I'll discuss each one individually.

createChildren()

The createChildren() method is aptly named. It is intended to create the children of the component. This is run as part of the initial component setup and is never run again. In our Calendar component's MonthDisplay class we use createChildren() to create the day name headers to display the day of the week and the month header which displays forward / next buttons, the month name and the year.

commitProperties()

I consider the commitProperties() method is a wild card method. You'll use commitProperties() to coordinate component changes all at once. However, the exact use of this is a bit of a gray area. It depends what properties have changed and how they affect the component.

In many of the custom components I've built I find that I'm using commitProperties() as an alternative for createChildren(). In our Calendar component, I use it to create the month's days from a dayRenderer. This can't be done in createChildren() because we may not know the displayedMonth or displayedYear yet, and therefore can't determine the number of days in the week.

measure()

The measure() method will determine the ideal size of this component. Its' purpose is the most concretely defined of all the component lifecycle methods. This will set the measuredWidth, measuredHeight, measuredMinWidth, and measuredMinHeight properties on your component. A component is always sized by its' parent; but if these properties are suggestions to that parent.

How you calculate the meauredWidth and measuredHeight is open to interpretation and depends on your component. In most cases, you'll examine each of the component's children and keeping some type of running tally. For our Calendar component's 'month display, we set measuredWidth to the width of the longest week. MeasuredHeight is calculated using sum of the heights of the largest day in each week. The calculations take into account localization features, such as the first day of week.

I've experienced a few gotchas with the measure() method. First, if you specify an explicit height and width, the measure method will not be run. This is done for performance reasons. If you already know the height and width, why does the parent need suggestions from the child? It doesn't!

Second, the documentation states that measuredMinWidth and measuredMinHeight are optional, but I have found this not to be the case. If these values are not set I've experienced situations where the width or height ended up being set to NaN, which interferes with sizing calculations up the component chain.

updateDisplayList()

The updateDisplayList() method is intended for changing the visual pieces of the component. It is great for setting the height and width of your children and positioning those children with the x and y coordinates. In the Calendar's MonthDisplay this will size and position all the days. Even though the measure() method assumes that individual days can contain have different height or widths, updateDisplayList() forces all days to the same size. You may also use updateDisplayList for changing styles.

Final Words

So, in summary:

  • createChildre(): Creates the component's children
  • commitProperties(): Coordinates property changes
  • measure(): Determines the ideal size of a component's children
  • updateDisplayList(): Positions and sizes the children

Most of the work I do when building components for Flextras relates to use of one of these component lifecycle methods. The Flex 4 framework does bring quite a few changes along with a new component architecture. Perhaps I'll write about that another time.

Flextras Friday Lunch - Episode 35 - 10/09/2009 - Adobe Max 2009 Review

In this episode, I discuss my experiences at the Aodbe Max conference and muse over a few of the announcements. I also field questions on get set methods, the Flextras Calendar Preview Release, and Adobe Support problems.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

Flextras Friday Lunch - Episode 34 - 10/02/2009 - CalendarDisplay Preview Release

In this episode, I demonstrate the preview release of our CalendarDisplay component. The conversation covers ways to protect your content in an AIR application.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

Flextras Friday Lunch - Episode 31 - 09/11/2009 - CalendarDisplay Component Prerelease 2

In this episode, I demonstrate the second prerelease of the Flextras CalendarDisplay component.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

Flextras Friday Lunch - Episode 26 - 07/31/2009 - CalendarDisplay Demo

This is episode twenty-six of the Flextras Friday Lunch podcast, originally from July 31st, 2009. In this episode, I demonstrate the Flextras CalendarDisplay for the first time.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact