With Silverlight 5 you have the posibilty to define Custome Markup Extensions. For example you can define a new extension MethodInvoke which calls the named method in your datacontext in this way. Not longer event triggers or something else necessary.
more information about Silverlight 5 Beta features: Here
Here is a nice solution for debugging Windows Phone 7 device network traffic with Fiddler. I tested this also using Intel My WiFi Technology instead of Connectify.
http://dotnetbyexample.blogspot.com/2011/05/debugging-windows-phone-7-device.html
Microsoft has now released the third update of the Windows Azure Toolkit for Windows Phone in less than two months – shows that they are hard working on good Windows Azure support for Windows Phone.
One of the new features is the support for Windows Azure Access Control Services.
More details here: Update to Windows Azure Toolkit for Windows Phone 7 « Michael S. Collier's Blog
With the new version Silverlight 5 (beta available) the sandbox of an Silverlight app will be nearly destroyed. If you run your Silverlight application in elevated trust mode as out-of-browser application you can access now to the whole local file system and using P/Invoke to call a Win32-Api function. This will give us as developers a total new scope for Silverlight applications. We can now concept Silverlight applications that have native access to local resources like scanners, 3rd party applications and the whole file system – I love this, because the necessity of using WPF nearly disappears.
Pete Brown give us a flavour of new Silverlight applications that uses several operating windows:
Silverlight 5: Working with Operating System Windows - Pete Brown's 10rem.net
The Mango update for Windows Phone 7 was announced at the Mix11 for end of 2011. But the capabilities of Mango are coming a little bit earlier to developers next month with the new Windows Phone tools.
Jese Liberty has now published a few code samples and decriptions for a few key features that will come with Mango.
In an older blog post I have mentioned that Windows Phone uses some magic caching mechanism if you call a web service with the same Uri. Because I have the problem now again with a REST-service in my new demo app, I will explain a possible workaround for this caching behaviour a little more in detail.
For example the call of the RESTfull service TopList
http://localhost:57988/BornToMoveService.svc/TopList
will not invoked by your Windows Phone 7 client if you call this service a second time. The Windows Phone OS caches the service calls and will give you back the same results as after your first call. For example the event wc.DownloadStringCompleted of the WebClient class the same results as after your first call.
If you now will have the idea to destroy your instance of your WebRequest or WebClient class to force a non-caching behaviour – dont’t waste your time. The caching behaviour is still there.
The only way to get rid of this caching behaviour is to add a unique sign at your Uri. In this sample I use a Guid and put it after the normal REST-Url.
public void LoadData()
{
ReadJsonDataAsync<TopListEntry>(BaseUrl + "TopList", list => this.TopList = list);
}
private static void ReadJsonDataAsync<T>(string url, Action<ObservableCollection<T>> resultAction)
{
var wc = new WebClient();
wc.DownloadStringCompleted += (s, e) => OnReadJsonDataCompleted(e.Result, resultAction);
wc.DownloadStringAsync(new Uri(url+ "?id="+ Guid.NewGuid().ToString()));
}