AgFx now on CodePlex
Today, the CodePlex AgFx site went live, with a new updated release.
Quite a few folks are now building Windows Phone 7 apps on AgFx and are having good luck with it.
I’ve written a few more walkthroughs and detail pages on the documentation tab, and the release now includes a help CHM file.
Along with some bug fixes the Release on CodePlex adds:
- The ability to manually push items into the cache with the DataManager.Current.Save method
- Helper classes for handling login and credentials management with AgFx (AgFx.Controls.Phone.Authentication)
- A derived PhoneApplicaitonFrame type (creatively named PhoneApplicationFrameEx) that gives support for
- An app-wide header area for something like a loading progress bar
- A PopupContent property that makes it easy to pop UI over the current page for things like login or “Loading…” UI.
- A CachePolicy of CachePolicy.Forever that keeps things in the cache indefinitely.
There are some additional features in the tree that didn’t make it into the initial release as well:
- The ability for model items to specify their cache duration. Before this had to be statically declared as part of the CachePolicyAttribute. Now an object can override that and provide an exact time for it’s cache to expire. If CachePolicy.AutoRefresh is specified, a reload will happen automatically at that time.
- AgFx knows a lot about what your app is up to, so I added some functionality to keep some statistics around that info. AgFx will build a report on this data for you on-demand, and it gives you a lot of insight into what your apps is up to:
To enable this, I just need to write the following code at startup.
DataManager.ShouldCollectStatistics = true;
And everything happens automatically. I can fetch the data as follows:
StringWriter writer = new StringWriter();
AgFx.DataManager.Current.GetStatisticsReport(writer, false);
writer.Flush();
string output = writer.ToString();
Here is an example of the output for the sample NWS weather application. In this case, I started the app, requested weather for a few different zip codes, closed the app, then did a few more request, some new, some repeated.
As you can see I get a lot of data about my network requests (called “fetch”) below, my deserialization, and how many objects of each type I was managing.
Totals:
Total Instances: 6
Total Requests: 10
Total Fetches: 5
Total Fetch Failures: 0
Total Deserialization Failures: 0
Cache Hit Rate: 0.50
Average Fetch Time: 546.1ms
Maximum Fetch Time: 2780.0ms (Object Type=WeatherForecastVm, ID=98109)
Average Deserialize Time: 19.8ms
Maximum Deserialize Time: 84.0ms (Object Type=WeatherForecastVm, ID=98112)
Average Deserialize Size: 7287.5 bytes
Maximum Deserialize Size: 14437 bytes (Object Type=WeatherForecastVm, ID=98033)
Statistics for NWSWeather.Sample.ViewModels.WeatherForecastVm:
Total Instances: 3
Total Requests: 4
Total Fetches: 3
Total Fetch Failures: 0
Total Deserialization Failures: 0
Cache Hit Rate: 0.33
Average Fetch Time: 997.5ms
Maximum Fetch Time: 2780.0ms (Object Type=WeatherForecastVm, ID=98109)
Average Deserialize Time: 29.7ms
Maximum Deserialize Time: 84.0ms (Object Type=WeatherForecastVm, ID=98112)
Average Deserialize Size: 14351.7 bytes
Maximum Deserialize Size: 14437 bytes (Object Type=WeatherForecastVm, ID=98033)
Statistics for NWSWeather.Sample.ViewModels.ZipCodeVm:
Total Instances: 3
Total Requests: 6
Total Fetches: 2
Total Fetch Failures: 0
Total Deserialization Failures: 0
Cache Hit Rate: 0.67
Average Fetch Time: 94.7ms
Maximum Fetch Time: 195.0ms (Object Type=ZipCodeVm, ID=98109)
Average Deserialize Time: 10.0ms
Maximum Deserialize Time: 29.0ms (Object Type=ZipCodeVm, ID=98112)
Average Deserialize Size: 223.3 bytes
Maximum Deserialize Size: 224 bytes (Object Type=ZipCodeVm, ID=98033)
Notice how much faster the Zip Code service is that the Weather Service! Of course, it’s a lot less data.
Enjoy!