anIDEA

How to create a MVC Utility App using Flex and Webservices

PART 3  of 3

This article is Part 3 of the three part ‘How to create a MVC Utility App using Flex and Webservices’ blog post.

In this section, I heavily reference my source code and assume that the reader is following along. You can download the source code here. (Your svn client may ask you to authenticate, if so, use the word “anonymous” for the username and password)

Controllers

The controllers, specifically the AlertSiteData.as controller, are what make the call to the API, gather the data, parse the data through the desired report, and, finally, send it over to the view’s charts.

As you will see in the code, there is a controller for each measurement. (SiteOne, SiteTwo, SiteThree, and SiteFour.as) Again, these files’ names would be better if they were named as the site you are trying to measure, such as Google.as or Yahoo.as, but for the sake of the generic example, I chose to name them with the generic name.

Additionally, as I mentioned before, there are many ways to skin a cat, and, in fact, I could have done away with these four files entirely. However, I chose to include them for better readability and comprehensibility. By using a controller file per measurement I felt it would be extra clear of what I am trying to accomplish. I will explain how you can modify the app to not require these files at the end of this post.

Since I chose to include these files, I will explain what they do. Immediately after that, we’ll jump into the most important file; AlertSiteData.as.

The SiteXXX.as files do two things:

1. They create a new instance of the AlertSiteData data class.
2. Call the GetData function of the AlertSiteData class to start the process of fetching the data and feed it to the report controller, who will in turn feed it to the chart view. This GetData function lives within the controllers’ getReport function, which is called by the DatePicker view.

The GetData function requires five parameters.

1. The Measurement type (This is where the SiteXXX.as files come into play, each of them pass the respective measurement model) Remember, the model has the measurementUrl, measurementName and the other measurement properties explained prior.
2. chartId: This is a unique hard coded number that will be used to create an instance of a chart, using the chartId value as part of the name for that instance.
3. chartTitle: A string that will be displayed when the chart is complete and shown on the screen.
4. startDate: The start date of the date range.
5. endDate: The end date of the date range.

Before we continue, lets go back to the DatePicker view for a second. Remember, in this view the user selects the start and end date and clicks on “Get Report”. If the date range is valid, _FetchReport() is called.

In _FetchReport the getReport for each measurement controller is called. The id, title, start date, and end date are passed in. See the four calls on lines 78-82 of DatePicker.mxml. (Again, the name convention should be improved here to _google, _yahoo, and/or _amazon)

Back to the AlertSiteData class. Since the getReport function creates an instance of the AlertSiteData class, the application will now start to fetch the data from the API and attempt to parse it and pass it to the chart view. Here is how (you can follow along starting a line 38 on AlertSiteData.as):

1. I transfer the measurement, chartId and chartTitle into local variables. (_measurement, _chartId and _chartTitle).
2. I turn the start and end date from DateTime to String. (Needed for the API call)
3. I build the callUrl variable, composed of the measurementUrl (derived from _measurement) and the new string start and end date.
4. I build the request with the callUrl trigger the request (line 62) and set up listeners for success and failure (line 60 and 61).
5. If the call request fails, an alert is shown telling the user what happened. (line 90)
6. If the call is successful, the app moves to the next steps.

• _xmlData variable is populated with the data from the request response. (line 70)
• The FullPageRange controller is called and a new instance is created. (for now this is the only type of report available so it is hardcoded, but it is here that in the future a different type of report would be instantiated depending on user input)
• FullPageRange parses the data and calculates the data specifically to the Full Page Range report. (more detail ahead)
• Once FullPageRange prepares the data the PopulateChartEvent is triggered. The event contains the measurement name, the data necessary for the chart (xml format) and the chartId. Once the event is triggered it is cleaned up by calling removeEvents().
• Remember the, FullPageRangeView, it is listening for the PopulateChartEvent just triggered by AlertSiteData.as. This passes the data for the chart and the view is responsible for displaying the chart graphics. (explained in the views section of this post).

That is it, but wait….you may be wondering what took place in the FullPageRange.as class. Keep in mind this is specific to the desired report and the xml is formatted specifically for Fusion Charts. So here is what the report does; I wanted to measure how many users loaded a certain site (google, yahoo, and/or amazon) within a certain range in seconds. The ranges are the following:

So, perhaps 82 users loaded google.com within 0-3 seconds, while 104 loaded the site in 3-6 seconds. (Unlikely for Google, but just for the example’s sake)

Here is how the FullPageRange.as works:

1. The XML data gathered from the API call gets passed into the getReportData function. (line 24)
2. Then I create a XML type variable called chartXML and populate it with Fusion Chart specific XML. (This is specifically for the Pie3D chart)
3. Then I loop through the data and tally up the number of items that fall within the specified range. (Refer to legend above). I take that value and insert it into the “value” property of the “set” nodes.
4. Lastly, I return the formatted XML data back to the AlertSiteData.as class.

Now we are truly done with our application, but before I finish off the post, I want to revisit the need for the SiteXXX.as files as my controllers. The reason I mentioned that I could have written the application without these files is as follows:

In the DatePicker.mxml view I could have declared _siteOne, _siteTwo, _siteThree, and _siteFour as AlertSiteData types instead of SiteXXX types. (Lines 26-29 in DatePicker.mxml)

I would then have instantiated an instance of AlertSiteData for each of the four variables. (Example _siteOne = new AlertSiteData())

Lastly I could have then called the GetData function on each of the four objects and passed in the corresponding IMeasurement model. (Example: _siteOne.GetData(new MeasurementOne(), chartId, chartTitle, startDate, endDate);).

This would save four files in the project, but as I explained earlier, I thought that having these files helped with understanding and making the program logic a little more clear.

Conclusion

I hope you found this article interesting and learned a thing or two. Please feel free to point out ways to improve it or things I may have missed. Any feedback, good or bad is welcomed.

Follow AgencyNet: @agencynet

Pages: 1 2 3