Awkward Coder

If you've been developing Windows Phone 7 apps you'll be aware of the '90 MB' memory limit guideline detailed in the application certification requirements , if not it says: 5.2.5 Memory Consumption An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory. You can use the DeviceExtendedProperties class to query the amount of memory that is available on the device and modify the application behavior at runtime to take advantage of additional memory. For more information, see the DeviceExtendedProperties class in MSDN . I've heard of apps exceeding this limit and still being approved for the app store, but that is not the point of this post , the point is as a developer working on a device you should have a cursory knowledge of the size of your data. The reason is simple because when you exceed the 90 Mb limit (and in all probability you will) you'll be able to identify where your memory problems are quicker an

Continuing with the introduction of WP7Contrib concepts, patterns & services from my previous post I thought I would explain why we have chosen to implement our own ObservableCollection. As with the desktop version of Silverlight the idea of a 'blocking call' on the UI thread is discouraged, to point where if you do block the UI thread on a WP7 device your application could be automatically torn down - bad user experience. So to get round the issue the Silverlight framework makes use of the standard .Net 'async pattern' - IAsyncResult interface. Examples of this are the HttpWebRequest class and it's counterpart HttpWebResponse , they allow you to execute web requests without blocking the UI thread. The problem with the ObservableCollection<T> supplied by the framework is it's not thread safe for any methods. For example, when you have a control bound to the collection and it's enumerating over the collection and another thread modifies the coll

To start my WP7Contrib blogging contribution I thought I started with something small, easy and relatively quick to explain. If you're familiar with the platform you can get the current network type using the API - NetworkInterface.NetworkInterfaceType . This is a simple synchronous call which returns what MSDN describes as 'the type of the network servicing Internet requests. This is a prime example of a 'pull model' to obtain data. We've turned this model on its head, and produced a 'push model' using the MS Reactive Extensions for .Net . What we did was use an observable sequence which returns values at a specified frequency using the interval method. this.networkObserver = Observable.Interval(TimeSpan.FromMilliseconds(frequency)) .Select(DetermineCurrentStatus) .Subscribe(this.statusSubject); So for every interval we execute the Select and the returned value from DetermineCurrentStatus is pushed to the statusSubject. This is a behavior subj

Just wanted to announce the go live of WP7Contrib - a community effort based around the MS Window Phone 7 Platform. Rich Griffin and I have spent the last couple of months bring together code snippets and patterns into a cohensive contribution library, we're currently developing an app using the framework and will be giving more details and examples over the next couple of weeks.