Windows Phone SDK 7.1 - A developer review
Join the DZone community and get the full member experience.Join For Free
There were a bunch of reviews floating around that covered the various new features coming with the Mango. All that is exciting, but there is also the Mango "backyard" - the SDK, that also went through quite a few major changes. Since the initial 7.1 release to the RC build, I tried to spend as much time as possible with new features and accumulated quite a bit of general feedback and opinions on most of them. In this article, I tried to emphasize on the most important (in my opinion) features coming with the new SDK.
Non-push tiles and toast notifications
Metro is awesome. A lot of people like it and I know even more people who prefer Live Tiles to static iPhone/Android icons. Those were accessible to developers from the very beginning as a part of the push notification infrastructure, but using them outside the push mechanism was a bit of a pain, especially since often developers wanted to "bookmark" parts of their own application or show notifications when an Internet connection was not required. There were, of course, workarounds - for example, as a part of the Coding4Fun Tools there was ToastPrompt that would allow the simulation of the toast prompt. It was nice, but it's only drawback is that it won't be activated outside the application.
On the other hand, with the updated 7.1 SDK developers are now able to create their own tiles and trigger almost instant toast notifications. The drawback of the toast, though, is the fact that it will not show while the application is running, and it has to be scheduled through a BackgroundAgent (details here). It's still better than using HTTP push services when there is no need for those.
The tiles are created instantly and without any scheduling needed. The built-in protection mechanism helps avoid the scenario when an application simply fills the home screen with unnecessary content - the app is tombstoned after each tile is added from inside it.
New URI schemas
Great idea but at this point it lacks full integration with the developer platform. It is really easy to access content in the Isolated Storage through isostore://mycontent rather than opening an IsolatedStorageFileStream, but the fact that most of the classes that accept an URI parameter will not work with isostore and appdata is sometimes frustrating.
It's only the beginning, though. There are other interesting URI schemas that can be invoked outside the application and I think the dev platform team is going to slowly integrate those deeper in the SDK. Eventually, it would be great to see the app:// schema available, in order to be able to launch existing installed apps from inside another app. It is already used in the internal parts of the SDK. Of course, this will imply that there will be restrictions (e.g. a user prompt notifying of the application launch). Nonetheless, this would have some potential.
Emulator with accelerometer and location support
Probably one of the features that is enjoyed by hundreds of developers with limited access to a physical device. In NoDo, simulating location and accelerometer data was a daunting task, especially for complex applications that pretty much rely on the accelerometer as the foundation of general user experience (e.g. games where the user controls a ball through a maze). I really like that now there are pre-defined motions that can easily be modified and added. The simplicity and ease-of-use of the accelerometer and location simulators compared to other platforms (e.g. Android and a direct telnet connection to the emulator to set current geo coordinates) puts the Windows Phone emulator a couple of levels above its competitors.
How many times did you want to take a look at what's in your application's Isolated Storage? How many times did you want to easily copy and restore that content? With the 7.1 SDK this is now possible through the Isolated Storage Explorer tool. For beginner developers it might seem a bit complicated, since it solely relies on the command line, but the reality is - there are not that many parameters you have to remember to make it work. The key element with this tool is - you should have the application GUID (declared in WMAppManifest) handy, as it will be used to read the data folder. A must-have for the SDK.
ShareLinkTask and ShareStatusTask
Every Windows Phone user has at least one social account linked to their device (that is, the mandatory Windows Live). Before the 7.1 SDK, if the developer thought about sharing content through a service like Twitter or Facebook, he would have to implement his own service connection layer. This is not a problem for service clients, but if the application only shares content at specific occasions, this was an overkill. I am glad that there is now the possibility to share content directly through linked accounts. Once again - there is the "anti-spam" protection mechanism present in EmailComposeTask and SmsComposeTask - no status will be shared without the user's consent and the user has the ability to edit it in the OS-based dialog. That being said, I believe that both classes need to support a collection of existing services for a more direct integration. When I am sharing a status, I don't necessarily want the user to share it through some outlets, even if those are bound to the OS. It would make sense to restrict some sharing to a single (or multiple) service(s) only. Eventually, I hope that we will see more granularity here.
Isolated Storage is not that efficient when it comes to large amounts of data, especially if that data is often reused and modified. SQL CE was more a necessity than an unexpected bonus with the new SDK. There are alternatives (No-SQL), like Sterling, but that will involve an external third-party reference, still relying on Isolated Storage. With native support, data access is more streamlined and the overall performance indicators are better.
Believe it or not, at one point you will need those, especially if you are downloading a file and the user won't be waiting for it to finish the process in your very own application. There are significant restrictions on background processing for third-party apps, and sometimes concurrent background downloads/uploads might not be that reliable due to potential interruptions (there are too many factors that can cause that). I would highly recommend having a backup plan for transfers that are initiated in the background.
The need for a clipboard was there a long time ago. Although you cannot directly read the clipboard contents, you can set them and have the data accessible in system applications or third-party applications where there is a TextBox in the UI. This is one of the under-used capabilities that actually can save a lot of time for the users when implemented correctly in various parts of the application.
Bottom line: The 7.1 SDK is the Windows Phone SDK done right.
Opinions expressed by DZone contributors are their own.