GoToMyPC - Access Your PC From Anywhere

Two signature components of the WP7 platform are the panoramic control and the pivot control, with them we can create experiences that engage and delight the user. Although both may look like they serve the same purpose they were built to serve very different ones.

Unlike standard applications that are designed to fit within the boundaries of the phone screen, the applications using panoramic view or the pivot control offer a unique way to view content by using a long horizontal canvas that extends beyond the confines of the screen. That is where the similarity ends. Understanding the differences in these controls will help you design a better application.

Explore, Panorama
A panorama evokes interest—it provides featured content, occasionally dynamic, attracting user attention. A panorama is also great at aggregating information from multiple sources. Similar to a magazine cover, panoramas allows users to explore content that highlights what is more relevant for them, serving as an entry point to further action. Panoramas should not provide the standalone interaction of an application—it should entice further navigation to task specific features, completing the whole user experience. Imagine a cookbook app, the panorama may showcase the recipe of the week, what your friends are cooking, what’s featured on your local market and other relevant, enticing content. The recipe step by step, your notes or how to connect with friends could be accessed from the panoramic view but the task oriented tasks shouldn’t, that’s when pivots are for.

panorama

Focus and filter, Pivots
If it is important to filter sort or organize content within your application, then your application should use a pivot. The pivot titles should be natural categories of the data that you are presenting. The left to right navigational affordance will help users efficiently find the information that they seek.

In our imaginary cookbook pivots will be used to navigate the top sections of the app like Recipes, reviews, my favorites, and what my friends are cooking.

pivots

Recommendations for Pivots
Unlike tabs that are all visible on one screen, pivot titles will be hidden as they fall beyond the boundaries of the screen. Pivots facilitate browsing and exploring. Therefore you should try to keep the number of pivots to about 6 or 7 categories at a maximum. If you have to filter or navigate more than six sections the use of pivots would not be efficient as the user will not be able to remember those sections or would be an exhausting task to browse many pivots until finding the right one. If the number of categories you want to use exceeds 6 or 7, then we recommend that you split them using an item list first (figure below) Indeed there are some scenarios where it may make sense to use a pivot even when you have more than 6 or 7 categories, for example months of the year. In this case there would be 12 pivots, and the chance of a user’s getting lost in the categories is pretty low. However, even this example can lead to some really bad scenarios … you don’t want your pivots to itemize sequential days of the year, because they’ll go on forever (seemingly)!

MORE-THAN-SIX-PIVOTS-small

You can download Photoshop templates for pivot and panorama controls here.

I hope this will help you to fully leverage the pivot and panoramic controls for your app.

- Alfred Astort
Follow the Windows Phone Design Team on Twitter: @WPdesignteam

Today’s post is from David Trupkin, Sr Product Manager from our Windows Virtualization Team.

As I’ve talked to IT pros at events around the world, many of you have told me that the biggest barrier to your Windows 7 deployments has been incompatible legacy applications. These applications may run on Windows XP or they might be browser-based applications that run in Internet Explorer 6 or 7. While many older applications just work in Windows 7, some may require compatibility shims. Others may require upgrades or patches. You may decide to replace some applications or retire them altogether. For those applications that are left – the ones that simply must run on Windows XP – you should know about Microsoft Enterprise Desktop Virtualization (MED-V) 2.0. MED-V bridges the “last mile” of application compatibility between Windows XP and Windows 7, allowing older applications to run inside Windows XP compatibility workspaces but integrate seamlessly into your users’ Windows 7 environment.

Don’t confuse MED-V with Microsoft’s consumer and small business compatibility tool, Windows XP Mode. MED-V expands on the capabilities in Windows XP Mode by adding enterprise features such as the ability to use a custom Windows XP image, automated first time setup, control of Internet Explorer URL redirection, automatic network printer mapping and easy packaging for enterprise distribution. MED-V version 1, first released in 2009, was based on a client-server model and required dedicated management servers. MED-V version 2, in Release Candidate status now and due for release before the end of March, 2011, is based on an application model which eliminates the need for a dedicated server. You can deploy and manage MED-V 2.0 with your existing software distribution management tools, like System Center Configuration Manager (SCCM).

med-v workspace packager

Let’s spend some time looking at MED-V 2.0 and its requirements. On the client, the MED-V Host Agent installs on Windows 7 Professional, Enterprise or Ultimate with a minimum of 2GB RAM and will support either x86 or x64 architectures. At least 10 GB of disk space is recommended, although you may use more or less disk space depending on your particular workspace image and combination of applications. You’ll also need to deploy WVPC and WVPC KB977206 (which allows WVPC to run on systems without hardware-assisted virtualization) to systems that do not have them installed already.

MED-V Workspace Packager lets you package your Windows XP virtual machine for use as a MED-V workspace. The documentation included with the Workspace Packager will guide you through the process of:

Often, you’ll deploy a management agent such as the SCCM client inside of your MED-V workspace to allow for application distribution and update along with patch management. The SCCM team has provided a client hotfix, to be installed on your SCCM SP2 Site Server, which improves SCCM functionality when you’ve configured your MED-V workspace to use network address translation (NAT). The hotfix allows a MED-V workspace that is also an SCCM client to use the same SCCM site and distribution point assignment as its host.

Once you’ve created your MED-V workspace package you’ll have a MED-V Workspace Package – a standard application file set that’s ready to deploy. You’ll find:

You can create installation tasks within your software deployment tool to install MED-V and its prerequisites together, or you can create separate tasks that deploy the individual components. If you are using SCCM, you can create packages and a Task Sequence to install the MED-V and WVPC components.

In this sample batch script for MED-V component installation, the MED-V components are installed in inverted order, allowing the installation to complete with a single reboot. There are two things to keep in mind about this batch script. First, while the MED-V Client installer and MED-V workspace package installer will detect if they are running on an x86 or x64 system and will install the appropriate “bitness”, the WVPC update and associated hotfix are specific to x86 or x64 systems. Second, the MED-V installation will not be complete until the system is restarted.

REM install the MEDV Host Agent
start /WAIT msiexec /i MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
REM install the MED-V workspace package
start /WAIT .\setup.exe /qn OVERWRITEVHD=1
REM Install Windows Virtual PC (this example is for Windows Virtual PC x64)
start /WAIT Windows6.1-KB958559-x64.msu /norestart /quiet
REM Install Windows Virtual PC update (this example is for the x64 version of the update)
Windows6.1-KB977206-x64.msu /norestart /quiet

Here are command line examples for creating packages within SCCM:

Once MED-V 2.0 and Windows Virtual PC have been deployed, and any necessary reboot completed, the MED-V First Time Setup runs and legacy applications published from MED-V are available in the Windows 7 Start menu. Legacy web based applications or sites defined by the MED-V administrator are seamlessly redirected to Internet Explorer 6 or 7.

For more information on MED-V 2.0 and to try it yourself, register on Connect and check out the MED-V 2.0 Release Candidate today and for a complete library of information on MED-V, App-V, VDI and other desktop virtualization solutions, visit the Desktop Virtualization Zone on the Springboard Series on TechNet.


All Windows Phone devices have a built-in Assisted GPS (aGPS), which is used by various phone applications including maps, camera, and search (to provide location-based search results). Developers can access location information on Windows Phone by using the System.Device.Location namespace, which is supported in .NET 4 and later. The GeoCoordinateWatcher class supplies location data based on latitude and longitude coordinates.

Working with the GeoCoordinateWatcher is relatively simple. Later in this piece, we’ll explain in more detail how to work with that class and how to test your application on a Windows Phone 7. However, sometimes your application requires more than just a single location, it requires tracking movement, and you may need to test how your application behaves in different locations.

At these times, it may look odd to be driving around the block with your Windows Phone attached to a laptop while you try to debug your application.

Don’t worry—you’re in good hands. The Windows Phone GPS Emulator (a small WPF application) and one WP7 DLL enable you to debug your application on the Windows Phone emulator or a real device without leaving the comfort of your home or office. Once you’ve completed your testing and debugging, you only need to change a single line of code to switch to the device back to real GPS.

With the GPS Emulator, you can set a location anywhere on the globe by using the map display. Furthermore, you can plan routes with multiple intermediate waypoints, or use Bing services to calculate driving directions between locations. Once you’ve planned a route, you can simulate driving through the pre-defined waypoints along the path.

The recipe includes:

Using the GPS Emulator lets you create complex path that you can playback just as if you were driving or walking. Then, you can choose your Windows Phone application and receive the location information form the GPS Emulator just as if you got it via the real GPS.

image

 

Using GPS Emulator with your Windows Phone Application

But first thing first, let’s figure out how does the GPS Emulator helps you debug your Windows Phone client application?

When you download the Windows Phone GPS Emulator recipe, you’ll notice there is an assembly called GPSEmulatorClient. This DLL has a class called GeoCoordinateWatcher, which is the same name as the System.Device.Location.GeoCoordinateWatcher class, just in a different name space. This homebrew, “fake” GeoCoordinateWatcher class implements the IGeoPositionWatcher interface, which is the same interface that the “real” System.Device.Location.GeoCoordinateWatcher class implements. Therefore, we can say that the GPSEmulatorClient.GeoCoorinateWatcher implements the same API as the real System.Device.Location.GeoCoordinateWatcher. This means that both classes are transparent to the developer in terms using the location APIs. We added all the functions that are not defined by the IGeoPositionWatcher interface but are public in the System.Device.Location.GeoCoordinateWatcher class. As a result, you can write your application to use the GeoCoordinateWatcher and only change the initiation process based on your environment. You’ll need to add a reference to the GpsEmulatorClient as well as the using GpsEmulatorClient; statement.

In the GpsEmulatorPhoneTestClient application, we define the symbol by using the #define keyword. Next, in the MainPage constructor, we use the #if GPS_EMULATOR statement to distinguish between our testing environment and a real device, as shown in the next code snippet:

// This line has to be the first line in the file
#define GPS_EMULATOR // defining a compiler GPS symbol. 
 
// Init
IGeoPositionWatcher<GeoCoordinate> _Watcher;
#if GPS_EMULATOR
            _Watcher = new GpsEmulatorClient.GeoCoordinateWatcher();
#else
            _Watcher = new System.Device.Location.GeoCoordinateWatcher();
#endif

Since _Watcher is of type IGeoPositionWatcher<GeoCoordinate> both implementations—the real and the fake—can be casted to that variable. From this point on, it is simply a matter of using the GeoCoordinateWatcher method and properties to listen to location and status changes.

Working with the GeoCoordinateWatcher

As we said, the GeoCoordinateWatcher class is part of the System.Device.Location namespace. The GeoCoordinateWatcher class has the following properties:

There is one more property, MovementThreshold, which defines the minimum movement threshold, which by default is set to zero. You need to know that the GPS fires a lot of events, about one per second. That may not seem like a lot, but if you don’t move that fast or if your application doesn’t need to keep track at such a high resolution, make sure you set MovementThreshold to something other than zero. You can read more about this in a post by Jaime Rodriguez.

Next, you’ll want to register to the following events:

There’s not a lot more to it besides handling the events and updating your application accordingly. In our test sample, we simply read the values and print them on a screen, as shown in the next code snippet and image.

void watcher_PositionChanged(object sender, GeoPositionChangedEventArgs<GeoCoordinate> e)
{
     tbTimeAcquired.Text = e.Position.Timestamp.ToString();
     tbLatitude.Text = e.Position.Location.Latitude.ToString();
     tbLongtitude.Text = e.Position.Location.Longitude.ToString();
}

As you can see, the GeoPositionChangedEventArgs holds the position relevant to the location reading that triggered the PositionChanged event. The Position, which is of type GeoCoordinate class, includes, among other properties, Lat, Long, and time. It can include additional information, including VerticalAccuracy, altitude, speed, and more.

The output of our client application looks something like this:

image

The purple circle represents the current location transmitted by the Windows Phone GPS Emulator. It turns out that Microsoft building 24, where my office is located, is at Lat 47.6416 and Long -122.1306.

Follow a Few Rules

Before we dive into the technical details of the GPS Emulator, there are few rules you need to follow:

The Windows Phone GPS Emulator is a great tool for testing your location-based Windows Phone applications without leaving the comfort of your home or office. But be sure you test your application on a real device, as location-based info or the lack of it could result in interesting edge cases in your application.

The Windows Phone GPS Emulator recipe includes detailed documentation including few samples and explanation on how the GPS emulator works.

Follow Windows Phone announcements on Twitter at WP7DEV

Follow Yochay on Twitter

Get started with free tools and free training

keep looking »
eXTReMe Tracker