Last call for Windows Phone 7 LG App Starter competition
It’s the last day of the LG App Starter Competition (Competition time for Australian Windows Phone 7 Developers). Get your entries in today to be in the running to win an LG Optimus 7 Windows Phone 7 device.
Note: I’m currently travelling so it will be a few days before I’ll be able to announce the winner for this competition.
Windows Phone 7 LG App Starter: Almost Over…
Don’t forget we’re into the final week of the Windows Phone 7 LG App Starter Competition. All submissions need to be in by 6pm this coming Sunday (6pm EST Sunday 27th February). For full competition details see Competition time for Australian Windows Phone 7 Developers
This is your opportunity to win an LG Optimus 7 device!
Also, don’t forget to enter the Windows Phone 7 App Challenge– yes, you can enter both with the same app!
Windows Phone 7: Translator Sample, an example in what not to do!
I’ve posted about this before but now I feel the urge to say it again following the Real Apps, Real Codepost by Mark Hopkins (by the way I actually think this post and the use of samples is fantastic, I just like this example).
If you look at the Translator Starter Kit section there is a link to the Translator Starter Kit topic. Here the guidance suggests that you should get an AppID and add it into your application.
Surely they can’t be serious – DO NOT PUT APPLICATION KEYS INTO THE APPLICATION ITSELF. Application Keys/Ids are a web construct and work well when they’re in a configuration file on a server. If someone gets access to them then you’ve got bigger concerns than whether they’re going to be using your app key for some malicious purpose.
With an app key/id placed within your Windows Phone 7 application it’s about a 2 minute job for anyone with Fiddler and Reflector (after coughing up $35 to Redgate – talk about bad form!!!) to extract your Application key/id.
Unfortunately there is no holy grail for how you should deal with app key/ids. Some solutions rely on them being placed on a server and then retrieved when the application is run; some solutions distribute parts of the app key/id throughout the application, making it hard for someone to extract it. Essentially it comes down to security by obscurity which is not a great position to be in. When will the industry learn that app keys/ids are not the answer.
Windows Phone 7 Navigation Memory Usage Just Got Scary
In my previous post I showed a couple of graphs of memory usage with some basic pages within a Windows Phone 7 application. Now I’ve started adding some content to the pages. First up I’ve added a single button to the second page:
– 2 Pages w Button (iterative): Iterative navigation between the MainPage and the second page every approx 6 seconds.
– 2 Pages w Button (iterative) (GC): Same again but this time GC.Collect is called before retrieving memory usage information
Now this is somewhat scary. Notice that when GC.Collect is called the memory usage is pretty much as you would expect. As you navigate to a page, memory usage goes up; As you go back to the MainPage the memory is reduced; Overall no memory usage increate. Unfortunately this is not the case if you don’t call GC.Collect. It appears that memory usage (both max and current) progressively increases over time. It does kind of hit a ceiling but it’s significantly higher than even the memory usage when the second page is displayed.
This backs up my previous post when I hinted that you may want to selectively call GC.Collect to free up memory.
**Note: I’m not sure what the sudden drop in the current memory usage for when GC.Collect wasn’t being called. This is probably just an anomaly of the way the data is being recorded.
Windows Phone 7 Navigation Memory Usage
Following Brendan’s post regarding memory usage in Windows Phone 7 applications I thought I’d take a look at some very basic scenarios to get a better feel for where memory is consumed.
Let’s start with a simple application, and I mean simple. Start a new project and basically rip out anything that isn’t required so that you end up with a blank page. In my case I even ripped out the splash screen. I’ve got a simple timer that executes every two seconds and reports current and maximum memory usage for the application. Here’s the first chart, followed by an explanation of each series.
– Single page (GC): This is the application with just the empty MainPage.xaml. The GC indicates that GC.Collect is called before querying the memory usage.
– Single Page (1) and (2): This is the application with just the empty MainPage.xaml but without the GC.Collect calls. You can only see two of these series as the others are identical so aren’t visible as they sit behind the other two.
– Two Pages: This is the application with a second (again empty) page added. This page is not navigated to.
– Two Pages (with 1 navigation): This is the application with a second page that is navigated to after approximately 6 seconds.
– Two Pages (with return navigation): This is the application with a second page that is navigated to after approximately 6 seconds and then navigated back to the MainPage at around the 12 second mark.
Whilst moderately interesting, there isn’t much useful information contained here. Let’s move right along to the next set of lines:
– Two Pages (iterative nav): This is the same application this time we’re navigating back and forth between the MainPage and the second page every approximately 6 seconds.
– Two Pages (iterative nav) (GC): Same again, but this time we’re calling GC.Collect before each query of the memory usage (this stops at 200 second mark as I got bored because the line wasn’t going anywhere…)
Ok, so now this is interesting. Remembering that your application has to sit below the 90Mb threshold for Marketplace certification it is apparent that an occasional call to GC.Collect may be in order to free up some resources. This is completely in contrast to the recommendation that you should never call GC.Collect!