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.
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.
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.
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.
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.
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.
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!
