Flash Catalyst Tutorial: Weather Widget, Part 1
I've been playing with Flash Catalyst for a few days now and have a pretty good handle on the basics. I was scrounging around the web trying to find a tutorial or any sample files anyone had done with the MAX release of the software, but have not been able to find one. So, I thought I'd put one together myself and share.
The idea for this sample is to try to emulate and demonstrate the capabilities of Flash Catalyst, Flex Gumbo, and the designer/developer workflow. I hope that I am accurate on my assumptions for the software and it's best practices - given that it has only been in the public eye for a week or so. Please feel free to comment on suggestions and ideas for the tools and techniques. On with the show!
Catalyst Weather Widget
The current .fxp document: weatherWidget.fxp.zip
Our client has asked us to build a weather widget application to have on their travel site. They love the iPhone and would like us to build an application that very closely emulates the functionality and design of the iPhone's built in weather application.
The first step in our process will be to create wireframes of the application. In our wireframe, we will capture all of the major sections of content and their basic placement within the constraints of the application footprint. Our designer opens up Flash Catalyst and begins to block out areas for data and imagery.
All of the sections were placed on the Catalyst canvas using the tools in the toolbar (box, text field, circle). The top section was created first with a text holder for the city, the hi and low for the day, the current temperature and an area for the current weather graphic (snow, rain, sunny, etc). This section was then grouped to make it easier to move around the stage.
Create the dayComponent
Next, the designer created 1 day section by laying down a rectangle for the surrounding box, text holders for the day, the hi and the lo, and a box to serve as a placeholder for the forecasted weather graphic. The day section contents were then converted into a custom component by selecting 'Convert Artwork to Component' > 'Custom/Generic Component' from the heads up display (HUD). Our designer duplicated the new dayComponent 6 times and spaced them evenly down the space to represent each of the days of the following week of forecasts.
Create the cityComponent
After returning to the main stage by clicking on the leftmost link (not sure what this is called exactly, but it's the crumb trail that is displayed immediately below the 'Pages/States' section in the interface), our designer selects all of the contents of the application that have been built so far. This includes the top section (in a group), the seven day components, and the little round button on the lower right. With all the items selected, we again convert into a custom component by selecting 'Convert Artwork to Component' > 'Custom/Generic Component' from the HUD. We now have a cityComponent as a custom component that is made up of a top section and seven embedded dayComponents... looking good!
When we test our application at this point, the wireframe has the correct positioning for it's components but not much else. Because the dayComponents are all the same, and Catalyst doesn't support and UI based logic statements, it's time to put our code hats on!
Handoff to Flex Gumbo #1
Our first step of our developer is to import the Flash Catalyst .fxp file. When we do, we're presented with a Flex Package Explorer that looks something like this:
Editing the dayComponent.mxml
Our first task is to add some mechanism to dynamically name the component text areas within our application. We'll do this in Flex using databinding and with some custom parameters. At the top of the dayComponent file, we'll add some <Script> tags and define 3 variables for the textfields in our component - day, hi and lo. Then, we go to each <TextGraphic> tag and find the 'text' attribute. This defines the text to be displayed in our component. We use the binding symbol of curly braces '{ }' and place the names of our variables on the appropriate TextGraphic tag.
Editing the cityComponent.mxml
Next, we open our cityComponent.mxml document and add the code required for this to be dynamic. We add another Script section to the top of our document, this time including the city, dayHi, dayLo, and currentTemp as variables to display in the top section of the interface. Down on line 37, we replace our text parameters with our curly brace friend and the appropriate variable name. You'll notice that our developer wanted to keep the 'H:' and 'L:' as prefixes to the hi and lo information in the design. The way that is done is with string concatenation which is indicated here by this code:
text="{'H: '+dayHi}"
Basically, that states - take the letters 'H', ':', and a space and then add to that string, the value of dayHi.. easy peasy!
Now then. Since we've already edited our dayComponent.mxml to include a new variable called day (check out the screen shot from above) we can add values for those names in our cityComponent file! The next blocked out section in the diagram shows the dayComponent placed on the stage and at the end of each line a 'day' variable is being defined. One of the cool things about using Flex Builder is the fact that because we've defined this variable in our dayComponent 'class', Flex Builder code hints this new variable for us to fill out... less typing = happy carpal tunnel ;)
Editing the weatherWidget.mxml
Last part of our first handoff is for our developer to open the weatherWidget.mxml document and define the variables that he has created. We define the city, currentTemp, dayHi and dayLo on our cityComponent tag.
OK. We've had our designer create a basic wireframed application - blocking out areas of content and imagery. When our designer runs the application out of Flash Catalyst, the blocked out areas are correct, but all the names of the days are the same and information is 'hard coded' into the text fields. Our developer picks up the .fxp file from our designer and he adds a few simple lines of binded variables and scripting code. When our application is run now, the names of the days are 'dynamically' placed and the application has the basic structure we'll need for further steps.
If you open the weatherWidget.fxp document in Flash Catalyst, you'll notice a strange looking thing - What is up with those long curly braced names?
Remember, our developer replaced the names of our 'hard-coded' values with binding variables. If you dig into the components in Flash Catalyst, you'll see that the text name in the HUD's are now the binding names from Flex Gumbo with the curly braces... aha! So don't change them, or our developer friend will have to change them back again. Actually, when the developer re-imports the .fxp after we do some more designing, he'll have the option to write over changes or not, so I guess that last statement is up to your normal workflow process you have at your gig.
The current .fxp document: weatherWidget.fxp.zip
Stay tuned for Part 2!
No comments:
Post a Comment