Flash Catalyst Tutorial: Weather Widget, Part 4

Latest files:
www.erikloehfelm.com/catalyst_tutorial/weatherWidget_4.fxp.zip

In Part 4 of our Adobe Flash Catalyst Tutorial, we'll add some data to the project so that our application can represent a real data set. We wont actually be connecting to an data service for the weather, but you can see how the data would be structured to do so.

We'll be focusing on two things in Gumbo: creating a 'model' for our data, applying and binding the information in our model to our interface elements.

We're using a very loose implementation of a design pattern in our example application called the "model, view, controller" pattern or simply MVC. You may have heard of this in regards to RIA (Rich Internet Application) development before. What this means in simple terms is that we will be separating our code into sections that represent the model (data), view (interface stuff) and controller (event handlers, functions, logic, etc). By breaking the code up into these groups and having the groups or 'packages' organized, we will be creating a structure that allows us to easily edit elements without disturbing or breaking pieces that work - ie. changing interface elements without affecting the functions behind them.

Here are the steps I've taken to get to the latest version of the project.

In Adobe Flex 'Gumbo':

• Import the .fxp project
• Go to File > New > ActionScript Class
  
  
  
  Uploaded with plasq's Skitch!


• fill in the appropriate information into the form

You should now have a new class document named 'WeatherDataModel'. We'll be creating a singleton - a class that has one and only one instance - for this class. We do this so that we have one point of contact for our data in the application.


The function 'getInstance()' allows us to access this class from anywhere in our application by stating:

WeatherDataModel.getInstance();

Nice! Next we'll add an actual data set to use. We'll define an XML document as our data source, but you could easily adjust this to any data type you'd like.


Now we have a data model with actual data in it. Lets move on to binding this data to our view. Open the cityComponent.mxml file. We are going to add some code to the Script tag:


Notice how simple it is to reference the model now! We bind the model's data to our visual elements toward the bottom of the page. Move down the file until you see the code for the TextGraphics in the 'current' Group. We'll adjust the parameters to the following:


When we use the curly braces in a parameter like this:

text="{ model.cityData.city[model.currentCity].name }"

we are binding the information to this view. If the information changes, the view updates. In this case, we defined 'model' as our WeatherDataModel. model.cityData points to the XML that we've defined in the model and then we traverse the XML tree to get the value we'd like to display.

Now we need to display the day and the hi and low for each day in our list below the current weather. Move down a few rows in the cityComponent.mxml document to the list of 7 component:dayComponent nodes. These represent the 7 day forecast list. We'll adjust that code to the following:


We've just bound each of the dayComponents to the same data model! If you save all your files and test the application, you should now see something like this:

Uploaded with plasq's Skitch!

Our application now has 'real' data bound to the interface elements. Stay tuned for more Adobe Flex Catalyst and Flex Gumbo goodness!

CSS Body Typography Samples

I just stumbled upon a nice example of some body copy styles applied in CSS:

http://jontangerine.com/silo/typography/p/

It's interesting to see the subtle changes in readability that leading and alignment can make to a block of text. Makes me think back to my days in editorial design and how things seemed to be simpler back then :)

This was a bit of new information to me:

p + p {
text-indent: 1em;
}

The use of the 'p + p' to define a style. I hadn't used that before but will now that I know it's usage and availability! Check out the drop cap example at the bottom... sweet! Too bad that IE doesn't support it very well. What a surprise.

Flash Catalyst Tutorial: Weather Widget, Part 3

Download the file for this part here:
weatherWidget_3.fxp
weather1.ai
Previous tutorial posts:
Part 2
Part 1

Skinning

In this part of our project, I will begin to skin the widget with a graphical treatment similar to the Apple iPhone application. We'll be designing our skin in Adobe Illustrator due to the supported round trip features in the beta release. Normally, I would design these type of skins in Fireworks - I'm more familiar with the drawing and creation tools in Fireworks.

In Illustrator

1. create a new document in Illustrator


2. draw a black background box on the stage 250px wide x 400px tall to match the size of our widget


3. draw a rounded rectangle that is slightly smaller than the background box with a dark blue color and a heavy light colored border


4. name this layer with an appropriate name - blueBack


5. copy blueBack layer and paste. change the color to a grey color for the background and for the lighter rule. this background will be for the 'back' of our widget


6. name this layer - greyBack


7. create 7 rectangles 230px wide x 30px tall for the background color of each of the days in the list


8. alternate the color of the seven rectangles to represent an alternating list of items


9. name these rectangles row1-row7


10. create a small white circle in the lower right corner of the interface for the 'flip button'


11. place the text 'i' on the white circle to represent 'info'


12. group the white circle and the 'i' and call the group infoButton


13. save your work

Uploaded with plasq's Skitch!

Rather than starting from scratch with an import of our Illustrator document, we'll be copying and pasting our design elements into our current work in the Catalyst document.

In Illustrator

1. select the blueBack and row1-row7 layers


2. copy these layers


3. switch to Flash Catalyst

In Flash Catalyst

1. click on the direct select tool - the white arrow


2. double click on the cityComponent to edit it in place - you should see the grey chevrons around the component and see the crumb trail in the upper left and see cityComponent as the right most item


3. paste the copied Illustrator items in the cityComponent


4. to make the items easy to move, group them and name the group graphics


5. move the graphics layer to the bottom of the list in the component's layers


6. adjust the position to your liking

Uploaded with plasq's Skitch!

At this point, you should see the background image in place with the day components laying in place over the rectangles for the alternating days. You might need to adjust the position of those layers to space them evenly. You can do that either in Illustrator or in Catalyst. Next we'll define our info button graphics.

In Flash Catalyst

1. select the direct select tool - white arrow


2. double click on the round button in the lower right of the interface


3. in the HUD click on the 'edit button appearance' 'up' button. this will open up the four states for the button component and list the button in the crumb trail


4. briefly switch to Illustrator and copy the infoButton graphics group


5. switch back to Catalyst and paste the graphics into the 'up' state for the button


6. paste the graphics in each of the button states or select the small colored box in the layers palette for each of the states to copy them over


7. change the colors of the background layers for each of the states by selecting the state and selecting the background layer. change it's color with the HUD

Uploaded with plasq's Skitch!

To make the rounded rectangle background stand out a bit more, we'll add a black background to the component in both states. You can either draw this layer and put it to the lowest layer in Catalyst, or draw it in Illustrator and copy and paste it like the steps above.

For the second state - chooseCity - we'll want to have a background with a rounded rectangle that has a bit of a different color to it to make the transition from the front to the back more dynamic. We created a greyBack layer in Illustrator so copy and paste that layer to the back of the choose city state. It should be placed to the bottom of the cityListGroup in Layer 1 in the layers palette.

If you test the application you'll see the blue background in place with the button graphics. Click on the button to see the transition we've previously built with the 'backside' color applied.

Flash Catalyst Tutorial: Weather Widget, Part 2

Download the current .fxp file here: weatherWidget_2.fxp

To view part 1 of this tutorial, click here.

Designing the Second State

In this part of our project, the designer is planning on adding some more elements to our wireframe to begin to flesh out the experience design (XD) of the application. In the iPhone and Dashboard versions of the weather widget, the 'back side' of the application has a function to choose which cities you'd like to track the weather for. Our designer decides to begin with this part of the app.

In Flash Catalyst, our designer opens up the .fxp file and creates a new blank state by clicking on the 'New Blank Slate' button in the Pages/States panel. Interface elements are placed in the new state and a state title of 'chooseCity' is given to this second state. In the chooseCity state the user is presented with a list of current cities that are being tracked in a scrolling list. Each item in this list has the name of the city and a button to remove the city from the list. There is also a button to add a new city at the top of the interface as well as a button to go back to the previous view. All of the UI elements are placed on the stage. 

Uploaded with plasq's Skitch!

Next, our designer realizes that the scrolling list will have more than one city listed for a typical user. Since the items in the list will be similar, he decides to make this a Custom Component... good call! We create the custom component in the same way we created the dayComponent in the first part - select all the items for the component (remove button, city title, surrounding box) and click on the 'Convert Artwork to Component > Custom/Generic Component' in the heads up display (HUD).

Now that our second state wireframe is complete, we'll build the transition from one state to the next. For those of you that attended MAX in San Francisco and were lucky enough to get into the hands-on lab with Catalyst, you'll recognize the transition we're going to build. It is a rotational transition that makes the application flip over like a card to show the 'back side' of the app. This is the same transition that Apple uses on the iPhone and in Dashboard.

Begin by having the Timeline panel viewable - double clicking on the tab works if it's collapsed. Because we had Auto Effects for New Transitions checked by default in Flash Catalyst (it's in the Timelines menu) you should see some standard fade transitions between the 2 states. All the way to the left in the Timeline panel you will see 2 State Transitions - View City > Choose City and Choose City > View City. These represent the names of the 2 view states we've defined so far. We added 2 actions to each state transition - Rotate 3D - by clicking on the row for the item to be transitions (city and cityListGroup) and then clicking on the 'Add Action > Rotate 3D' button. We then selected each Rotate transition and changed the values to the ones in the diagrams below in the HUD. For the second state transition (the one that goes back to the viewCity state) we just reversed the order of the transitions.

Uploaded with plasq's Skitch!

Uploaded with plasq's Skitch!

To trigger the interactivity for the transitions, our designer selects the round button in the first state, and adds a transition to second state interaction. On the second state, the back button is selected and an interaction is set to go back to the first state. If you run the application, you will see a transition like the one below. (click image to play movie)

Handoff to the Developer

The designer is satisfied with the transitions and basic wireframe positioning of elements and saves his .fxp and hands off to the developer again. Our developer realizes that some changes have been made to our project with a warning presented to him in Gumbo on import of our updated .fxp file. He accepts the changes as none are critical to the functionality already built.

The first thing our developer does is to rename the newCustomComponent that our designer created in Catalyst - I'm hoping that Catalyst will allow you to declare class names in the future so as not to require that as part of the workflow - so that our naming conventions are consistent with one another.

Uploaded with plasq's Skitch!

After digging into the created code a bit, our developer realizes that the button component that our designer created to transition from state 1 to state 2 is just 'floating' in state 1 and not part of a group or custom component. He thinks that might not be the best way to have this button represented and decides to place it into the group on state 1. The problem is, when doing this, it becomes difficult to access the state transition that occurs 1 level up in the display list chain. There is no event that would allow us to track this user interaction so a custom event class is created: FlipEvent.

Uploaded with plasq's Skitch!

Our developer opens the cityComponent class and adds a few lines of code to include the new custom FlipEvent we've created. He ties that to the button - hmm, gotta' rename that button ;) - which triggers a function to dispatch our new event.

Uploaded with plasq's Skitch!

Because our cityComponent is now set up to dispatch our 'flip' event, we can listen for that event in our application! In the weatherWidget_2 file, we add some code to listen for the event to be triggered. Rather than setting up a function to be called to switch the states of the app, we're using a shorthand for that by using the {} with our expression embedded in it to switch the currentState property.

Uploaded with plasq's Skitch!

When we test our application now, we have the same effect as displayed in Catalyst, but we are now using a custom event to trigger our transition.

Part 3 - Let's get some skin on this sucker!

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.

Uploaded with plasq's Skitch!

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.

Uploaded with plasq's Skitch!

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 ;)

Uploaded with plasq's Skitch!

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.

Uploaded with plasq's Skitch!

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?

Uploaded with plasq's Skitch!

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!

Tour de Flex: Great AIR App for Flex Developers

One nice utility application that was released at the MAX conference this year was the Tour de Flex AIR application. It's a great utility for referencing Flex and AIR objects and API's. You can download it by clicking on the badge below: