anIDEA

How to create a MVC Utility App using Flex and Webservices

PART 2 of 3

This article is Part 2 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)

Views

The “views” for this project are somewhat self-explanatory. There are not many screens the users will see/use during the use of the application, here is how I broke them down:

1. PublicReportViewer.mxml – This is the entry point of the application and it acts as a shell for the date picker view and the reports view. The date picker view is placed at the top immediately followed by the reports view, which is invisible until the user clicks to generate the report.
2. DatePicker.mxml – The date picker view is where the bulk of the user interaction takes place. This view has two purposes. The first is to allow the user to pick a desired date range and the second is to allow the user to get the report by clicking on “Get Report”. A couple of things happen in this view:
   • The dates a prefilled with a 2-day date range based on the system’s current date.
   • New instances of the measurement controller classes are created. In this case there are four measurements I want to query. (More on these controllers a little later in the post)
   • Date validation. When the user clicks on “Get Report” the _ValidateDate() function gets called and the date is validated against a valid date and valid date range. If the date is valid the _FetchReport() function is called and the application moves on to fetch the data. If it is not valid, an alert is shown telling the user to check the date range.
   • Each of the four measurements’ getReport functions are called. The id, title, start date, and end date are passed in as parameters. (more on the getReport function in a bit)
   • Lastly, the reportView (which is the app’s report view instance) gets all its children removed, to make sure no other view is already in the report view. (i.e., a previous report)
3. Reports.mxml – This is basically a placeholder view, which will later be populated with the report view to display the final charts. Upon instantiation, the _app.reportView gets populated with the Reports.mxml view so it can later be referenced by _app.reportView across the entire application. This will be explained in further detail when we explain the Main.as model.
4. Chart.mxml – For this view, I knew the application needed to output charts. I researched chart software and decided on Fusion Charts (www.fusioncharts.com). Although written in ActionScript 2, the package provides a great deal of flexible features. In this view, I merely instantiated an instance of Fusion Charts’ “Pie3D” and attached a legend. Though it is beyond the scope of this post, I recommend exploring Fusion Charts and its functionality further. I spent quite a bit of time reading and learning about it and found the software package very useful. The chart.mxml view allows me to set up one chart view and replicate it as many times as necessary in the desired report.
5. FullPageRangeView.mxml – This view was created for the “Full Page Range Report”. In the future I would create a view per type of report. This one just happens to be the Full Page Range Report view because this particular report outputs the Full Page loading times segmented into ranges. (0-3 seconds, 3-6, and so on)A few things happen on this view. (I would also like to note that this is probably a part were I could enhance my code as you will see a lot of hard coded layout values. Not the best practice, but it will suffice for this exercise.)I also use a packaged loader created by J. Hawkes (download here). He created a spinning loader for flash/flex. I decided to use his component to display until the data was loaded and then show the replace the loader with the finished chart.
   
   This is what is going on in this view:
   • Because the program is reporting on four different measurements we are going to output four charts onto the screen, two across the top and two across the bottom. You can see the loaders being placed on the screen on lines 34-49 of chart.mxml, they will later be replaced by the completed charts.
   • I also have an event listener that is triggered by each measurement controller that tells the application when the data is finished loading and parsed through, so that the chart can be displayed. Once this event is triggered, the populateChart function is called.
   • In the populateChart function chart views are created and populated with the data gathered from the API call. It is then programmatically placed on the screen. (More on the PopulateChartEvent and API call ahead)
   • Once all four charts are loaded, I remove the event listener and I enable the “Get Report” button again so that the user can re-run the report if they choose to.

In a nutshell, that takes care of my views for the application. One thing to note is that as of right now there is only one type of report available to the user, however, in the future more views can be added to the “reports” folder. A drop down menu in the date picker view would allow the user to generate the different reports.

Models

As many of you already know, models are used to hold data and provide a structure to an object. In my case the application will consist of the Main (Main.as) and the four measurements (Measurement.as) models.

Main.as

I used this model as my main application model to store a couple of things:

• Instance of the application as “app”.
• The alertsite API url, “alertSiteApiUrl “. (In this case I wrote a proxy in .net so that the proxy authenticates against the actual Alertsite API and then provides the data to the application. This took care of Flex needing to authenticate against the Alertsite API. It is also why the Alertsite API url is located at tools.agencynet.com)
• Finally, I create two properties within Main: reportView and getButton. ReportView stores the holder that will display the final report and getButton stores the instance of the “Get Report” button so I can disable and enable it from anywhere within the app.

Measurement.as and IMeasurement.as

I am using Measurement.as as the class that holds the data that is fetched from the API call. Each measurement call will populate the same properties, which you will see specified in Measurment.as.

• dataItems (getter and setter): This function stores the data from the API call in XML format in a private variable called _dataItems.
• numberOfItems: This returns how many items are in _dataItems (number of elements)

Additionally, each measurement the application is trying to query has its own class that extends the main class, “Measurement.as”. You will find these classes labeled, “MeasurementXX.as” in the “measurements” folder under models. These classes all contain a few other properties and functions that are relevant to each measurement.

• measurementUrl: This function returns the measurement url which is composed of the application’s alertSiteApiUrl (explained earlier) and the hardcoded unique string of the measurement. (This string is what Alertsite uses to identify one measurement from the other).
• measurementName: This function returns the hardcoded measurement name so a human or programmer can easily identify it later. You will see the value hardcoded in the MEASUREMENT_NAME constant on line 13 of the MeasurementXX.as files.

Since I wanted to add new measurements in the future, I wanted to make sure that the same functions were present on all future measurements. To enforce this, I created an interface called IMeasurment.as, which is implemented by the MeasurementXX.as files. This interface simply tells the system that MeasurementXX.as files will always need to be written with the functions explained above.

I would also like to note that I used the names MeasurmentXX.as files just for the sake of this example. A better name for these files is actually the name of the actual measurement or site you are trying to measure. For example: Google.as, Yahoo.as, or Amazon.as. Because they are all found in the “measurement” folder, it is clear that they are measurement model classes.

Now the fun stuff: what makes the application turn. See page 3 for more!

Follow AgencyNet: @agencynet

Pages: 1 2 3