다음을 통해 공유

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:

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

Comments

  • Anonymous
    April 01, 2011
    Is there a NuGet package for this? :)

  • Anonymous
    April 01, 2011
    There needs to be!  I'll try to get to that shortly.

  • Anonymous
    April 01, 2011
    This is great. I was just thinking of asking when it was going to be put up on Codeplex earlier this week. Thanks.

  • Anonymous
    April 03, 2011
    This will be a perfect project to get using the Portable Library project... ;)

  • Anonymous
    April 03, 2011
    @Chris - Yes, I'd like to.  In fact I was headed in that direction when I split out the main AgFx assembly from the Controls assembly.  Unfortunately, there's one thing AgFx uses that isn't currently in the portable subset, which is IsolatedStorage.  DataManager is architected with a pluggable storage provider so it's certainly doable to separate it out, but it would require code on the consuming side (e.g. in the app) and another assembly to hook the two up.  It's extra steps that the vast, vast majority of apps don't need.  So, right now it's an aspirational goal. :)