This document discusses virtual orienteering and location-based applications. It covers model-view-controller patterns, notification of property changes, and the application lifecycle from launch to exit. It also discusses using WCF services, different sources of location like GPS, cell towers, and WiFi, as well as considerations for location accuracy, power usage, speed, and support for indoor, wilderness and urban areas. A consistent API is desirable across platforms, though emulators pose challenges for location support.
Two flavors of applications that can run on Windows Phone 7 (over time the differences between the two flavors might get smaller). There is already overlap by sample games written in Silverlight and sample apps written using XNA. Silverlight flavored application ‘ traditional’ application Metro style UI Rich controls + XAML XNA flavored application Highly user interactive Use of 3 D Typically games The Windows Phone Application Platform
-Does not have a presenter, has a controller -Request first comes to controller, binds the model with the view -Logic is stored in controller
-State and Logic stored in Presenter -Presenter is an abstraction of view, Presenter unaware of view -View is aware of Presenter, however isolated from Model -Uses WPF and Silverlight bindings -A very loose coupling between view and viewmodel, very easy to write unit tests -Growing in popularity (several toolkits MVVM Light, Prism, Caliburn) -Used internally at Microsoft during Expression Blend creation - Why MVVM ? ( Separation of concerns ; Easy data binding(XAML); Testability via unit tests (TDD); Designers vs. developers; Consistency, Maintainability, Scalability )
The application life time on a phone is basically similar to any other application. An application that is not running can be started, therefore becomes running and after some time it might be terminated, reentering the not running state. A phone application differs slightly from a ‘normal’ application. [Animate] While you are running on the phone two things can happen, each with their own behavior that we will cover in detail: The application can be obscured The application can be paused
There are three different ways to retrieve location on the phone: GPS Location information very accurate Radio drains significant power Initial reading slow (especially if the device has been moved over a long distance without GPX fixes) Does not work indoors Cell Tower Lookup Not that accurate (depends on the distance between cell towers) No additional power requirements (assuming the phone radio is switched on already) Fast location retrieval (if the phone radio is switched on, you are already connected to tower(s)) No 100% coverage WiFi Lookup In between GPS and Cell Tower in both accuracy, speed and battery consumption Works pretty good in larger cities Independent of physical location retrieval, one consistent API is used inside your application. The cloud can help getting more accurate location readings, based on other people having been at the same location (without the need for enabling GPS on a particular, individual device) Location services do not only retrieve Lat/Long readings, but can also resolve address information through reverse geocoding services.