Skip to main content

Posts

Showing posts from March, 2011

Calling 'HtmlPage.Window.Invoke' from a background thread

Received what at the time seemed like a strange exception from a piece of code in a silverlight I was debugging yesterday - ' this operation can only occur on the ui thread. ' What makes this strange was the fact this wasn't attempting to update any UI controls or classes bound to views,  infact this was the complete opposite, this was a method trying to invoke out to javascript from a randomly assigned thread (thread pool). To compound my confusion not only was I seeing this intermittently but the action I was trying to achieve still appeared to completely successfully, writing to an in-memory javascript log! Now the answer is as you probably known, is... Any interaction with the host browser from silverlight has to be done on the UI thread even if you're not updating any UI.

Considerations when building a caching mechanism for WP7Contrib.

For anyone wanting to build a cache for an application, there are several guidelines(may be rules) you want to beware of and more than likely abid by. Firstly, more than likely you are going to have an in-memory representation of the cache as well as a persisted format if the cache is to survive application restarts. Now an in-memory representation is more than likely going to be a hash-table - especially if you want acceptable retrieval time. Now this is where 'GetHashCode' comes into play and the importance of this is explained perfectly by Eric Lippert , Secondly, and this follows on from a statement in Eric's post - 'the integer returned by GetHashCode should never change', if you're using the internal state of a class to calculate the hash code, you can't allow that state to change overtime. So this means you are more than likely going to have create a copy of the instance before using it as a 'key' when adding to the cache, because this wil

WP7Contrib: RESTful communications using HttpWebRequest & Rx extensions

20/03/2011 UPDATE: code samples after changes to WP7Contrib code base. Simply I want to show how we do communication with web services when using WP7Contrib. When using web services from WP7 devices you have several options on how you are going to communicate  with the service. What follows are the steps required to achieve this using the WP7Contrib. We show how to use a third party web service and how this pattern is very advantageous in this scenario. We aren't advocating this is a better approach than using WCF data services (or any of other implementation), we've just been burnt before by WCF and prefer to possibly go through the pain of hand crafting resources (DTOs) than deal with WCF configs and it's short comings in Silverlight. In Silverlight as we all know communication with web services has to be asynchronous, this in it's self is not a problem, but it can make the code ugly at best and difficult to understand. This is where Reactive Extensions  come

WP7Contrib: Why we use SilverlightSerializer instead of DataContractSerializer

Like all applications developed for WP7 devices we (WP7Contrib) want to get the best performance possible from any libraries or patterns we use and this applies to how we serialize and deserialize data inside the WP7Contrib. In several of the libraries which make up the WP7Contrib we require binary serialization support, specifically we use binary serialization for the isolated storage cache provider and the storage service in the services project. Simply after testing we found SilverightSerializer  gave better performance, shown below the results of serializing a collection of 1000 items compared to the  DataContractSerializer . It shows the tick count, the equivalent time in milliseconds and the size of the generated byte array . So you can see the SilverlightSerializer gives better performance from both a time and size perspective. These results were generated using the StopWatch class. The only downside I can see from using the SilverlightSerializer is the support for gener

WP7Contrib: Trickling data to a bound collection

Recently Rich & I've had problems with adding items to list control where the data template is chocked full of XAML goodies - triggers, opacity masks, images, overlay, loads of things I know little about... ;) The culmination of all this UI goodness when used with a bound list control is the blowing of the '90 mb limit' for WP7 devices. As I posted before , we knew the problem wasn't with the data model so we knew it was the data template, now there is plenty of coverage of issues with data templates in Silverlight and this post it not adding to this list, its about a technique to reduce the memory footprint once you've done as much as you can with the data template. So we're developing an app which exhibits high memory usage, now obviously we want to reduce the memory consumption for the app so we trimmed down the data template for the list control, but we're still seeing the 90 mb limit exceeded for relative few items. Our data set could in theory c