I have been asked by a few people how sites like WP7AppList get their data.  The Windows Phone Marketplace, which you access on your PC via Zune software, uses XML to get data over the wire.  I wanted to share a couple of code snippets which might help an erstwhile data junkie on their way.  This code works.  It may not be the most elegant solution, but it works, and I wanted to share it with others in case they wanted to see how to parse the XML, or how to write LINQ queries against it.

Caveat – this is a geek enthusiast post.  I used Fiddler to figure out how to parse the XML.  This was something I did over Christmas break to give me a project about which I could be excited, and learn some more about parsing XML with LINQ.  I also wanted to do some large database stuff, and this crawler throws off a ton of data.  I did not use an proprietary knowledge about how our backend systems are working.  This is all done against the public XML feeds.

First up, we are going to need to create some data structures to catch all of the inbound data.  You can use anonymous types with LINQ, but I liked having a measure of control, and having the ability to handle null values and potential errors in the feed.

Read the rest of this entry »

There was a story which surfaced yesterday about vulnerabilities exposed in a wide swath of Android apps.  SMobile Systems conducted research in the Android app space and found that some 20% of the apps allow third-party apps to gain access to sensitive or private information.

It would be easy to dismiss this article by pointing out that by simply downloading an app, a customer is making a explicit allowance to an app to access data on the phone.  What I found troubling about the findings wasn’t necessarily the point about access to the data, but rather that, 5% of the apps surveyed could make calls and 2% could send premium SMS messages.  Talk about a surprise cell phone bill.

The key word in the above statements, however, is “could.’”  Yes, customers make the decision to download those apps, but they have no way of knowing with certainty what those apps are doing behind the scenes.  UPDATE: Ben points out below that the customer us warned of all the APIs used, which is true, but they aren’t told *how* they are used.

Further, because of the multi-tasking architecture of Android, the apps have the potential to be doing a bunch of bad things in the background when the phone is not in use.

Google has been quick to point out that the architecture of Android would limit what actual damage one of these apps could do, but that’s really not the point.  What is being lost in this discussion is that there is no curation of the Android marketplace.  For all the grumbling and grousing about the Apple AppStore, their review process would likely catch these abuses.  There is no such level of certification for the Android marketplace.  Customers don’t want to think about needing anti-spyware software for their phone, as the article implies is one solution for Android.

The Windows Phone Marketplace certainly believes in the curation model, and we have placed user security as a top priority.  This is one of the main reasons that we have our app certification process, and why (UDPATE: “at least in version 1”) apps are run in sandboxes, with no access to any data other than its own isolated storage, or the ability to communicate with other apps.  UPDATE: The goal is to ensure that absolute best customer experience when using their phone.

UDPATE 6/25/10

I’m not one who believes in conspiracy theories or anything, but I do find the timing of this announcement from Google that they can remotely wipe apps from phones a bit curious.  I have to go do some digging, but I’d be interested to know if the Android developer agreement has specificity about what would constitute grounds for a remote wipe.