Part 11 - Working with the Windows Phone 8.1 Emulator
Download the source code for this lesson at http://absolutebeginner.codeplex.com/
We've seen the Windows Phone Emulator at work in this series. It is a crucial component to developing apps for the Windows Phone platform, so I wanted to spend a little time becoming more familiar with it and point you in the right direction for more information.
Our game plan in this lesson ...
(1) We'll learn about what the Windows Phone Emulator really is, and how it supplies different versions for different deployment scenarios.
(2) We'll learn about the function of the Emulator, including keyboard shortcuts that emulate device buttons.
(3) We'll learn about the controls to resize, rotate and simulate the act of handling the virtual device as if it were a physical one, with accelerometer support, GPS support and more.
What is the Windows Phone Emulator?
In a nutshell, the Windows Phone Emulator is a desktop application that simulates a Windows Phone device, and actually provides similar performance to a physical Windows Phone device. It provides a virtualized environment in which you can debug and test Windows Phone apps without a physical device -- in fact the emulator is running Microsoft's Hyper-V.
Now, while the Emulator is great for development and quick debugging sessions, before you publish your app to the Windows Phone Store, Microsoft recommends that you actually test your app on a real Windows Phone.
Choosing different versions of the Emulator for debugging
Up to now, when we clicked the Run / Debug button on Visual Studio's toolbar, we were running the Emulator in its default configuration ... something called WVGA 512MB.
What does WVGA and 512MB really mean?
The 512MB indicates that we're running in a memory constrained environment ... The default emulator image in Visual Studio is Emulator WVGA 512MB, which emulates a memory-constrained Windows Phone 8.1 phone. So, for example, the Lumia 520 is an inexpensive entry level Windows Phone 8 device (which can be updated to 8.1 with the Windows Phone developer preview program) device which sports only 512MB of RAM. By contrast, the Lumia 1520 has a whopping 2 GB of RAM. On lower-RAM devices, having multiple apps running at the same time or creating a memory intensive app could cause performance problems. So, to be sure that your app will run well on lower-RAM devices you can test your app using a realistic Emulator image.
There are a number of great articles about RAM usage on MSDN ... let me point out the best starting point to learn more:
App performance considerations for Windows Phone
Optimizing Apps for Lower Cost Devices
What does "WVGA" as well as those other acronyms stand for?
The Emulator allows you to test your app on a unique emulator image for each of the screen resolutions supported by Windows Phone. This default selection encourages you to target the largest possible market for your Windows Phone 8 app.
WVGA (800 × 480)
WXGA (1280 × 768)
720p (1280 × 720)
1080p (1920 x 1080)
If you run the default, then go to the Settings app in the About button, you can see this confirmed.
How does this translate into the actual phones on the market?
Display Size: 6 inch
Display Resolution: Full 1080p (1920 x 1080)
Display Size: 5 inch
Display Resolution: Full 1080p (1920 x 1080)
Lumia 1020 and 920
Display size: 4.5 inch
Display resolution: WXGA (1280 x 768)
Display size: 4.3 inch
Display resolution: WVGA (800 x 480)
Display size: 3.7 ''
Display resolution - WVGA (800 x 480)
I realize by the time you watch this there may be newer phone models. The point is that you should be aware of the fact that you'll need to support different screen resolutions and memory constraints. Like I talked about in the lesson on Layout using XAML, you will want to eliminate specific pixel sizes for layout (except for margins). Choosing from the different Emulator sizes, you can make sure you're on the right track.
Working with the Phone Emulator's special features
I'll not spend a lot of time on the phone's basic navigation. A lot of this you'll pick up by using the Emulator throughout the series if you don't already have a physical phone in your possession. Essentially, you'll have an almost identical experience, complete with the Start and Apps page, search, web browsing, clock, battery, etc.
You have the same hardware buttons on the bottom of the Emulator as you would have on a Windows Phone.
However, you'll be missing the buttons on the side of the phone. For example, my Lumia 920 has three buttons on the side ... a volume up and down, a power button, and a camera button. These can be access in the Emulator with keyboard function keys.
There's a list of keyboard mappings here:
F6 - Camera button half-way
F7 - Camera button
F9 - F10 raise and lower the volume
F11 - plays / pauses audio ... it simulates an in-line headphone button that pauses music and answers incoming phone calls. If you double-tap the button, it'll skip to the next audio track on your playlist or album
F12 - Power button / lock screen
F1 - Back button
F2 - Windows key
F3 - Search button
PAGE DOWN button - When a textbox is the target input, PAGE DOWN disables the virtualized "hardware" keyboard down, and you can use your physical keyboard for input
PAGE UP button - When a textbox is the target input, PAGE UP enables the virtualized "hardware" keyboard.
PAUSE/BREAK button - Toggles the keyboard, so you could just use that all the time.
In addition to the "virtualized" phone on screen, there's a floating menu off to the right. A little experimentation will reveal that the first six buttons, in order:
(1) Shuts down the emulator
(2) Minimizes the emulator
(3) Changes to single-finger selection mode
(4) Changes to two-finger selection mode (for pinch gesture)
(5) Rotates the emulator 90 degrees counter clockwise
(6) Rotates the emulator 90 degrees clockwise
(7) Expands the emulator to the largest size that can fit comfortably on your computer screen
(8) Brings up the zoom dialog
(9) This opens an MSDN page on how to run Windows Phone apps in the emulator.
(10) The double chevron at the bottom opens up the additional tools dialog.
There are eight tabs on the Additional Tools dialog. The first is the Accelerometer which can be used to test apps that utilize the accelerometer sensor.
(1) You can change the center point of the phone to change its position in 3D space by clicking and dragging the orange dot in the circle.
(2) You can change the Orientation to one of the presets
(3) You can play recorded data, like a "shake" motion.
For more information about the Emulator and the Accelerometer sensor in the Windows Phone SDK, a good starting spot would be this article:
How to test apps that use the accelerometer for Windows Phone
The next tab is the Location tab which allows you to set the current location of the phone. So, even though I'm sitting in Dallas, Texas, I can act like I'm testing my phone in Seattle or any other place in the world. To do this:
(1) I'll perform a search for a particular location, like "Chicago, IL".
(2) I'll right-click the map to create a pin in the suburb where I grew up.
(3) I'll verify the exact location in the list of pins marked by their latitude and longitude.
(4) I can introduce variance to the accuracy. In some areas, there are fewer ways to determine the exact location because there are fewer physical resources (like cell towers, etc.) to use to triangulate the location of the phone. The Accuracy profile allows you to adjust this to test your app and how it performs in various less accurate scenarios.
The third tab is for creating screen shots, which can be helpful when you're creating documentation or bug reports.
The fourth tab is the Network tab. In addition to seeing the IP address of the phone on the network (which may be helpful if you’re building some network monitoring app) but also you can throttle the phone’s network access to test your app’s performance when in bandwidth challenged situations.
Fifth, you can designate a location on your hard drive that will simulate the use of the SD Card so that you can test whether your app is correctly saving or working with the file system of a removable
The sixth tab allows you to simulate push notifications.
The seventh tab allows you to save the current state of the emulator as a checkpoint. This allows you to test a scenario where the phone is configured in a certain way over and over by restoring the state of the phone to a snapshot of it’s previous state. Think: virtual machine snapshots, because that is what is happening here.
Finally, the Sensors tab allows you to turn on and off certain sensors to test how your app works should it rely on one of those sensors and they don’t exist in the user’s phone.
In addition to the Emulator itself, Visual Studio has a Device window with some tooling that can affect how the XAML designer displays the phone ... orientation, theme and color, chrome, etc.
So as you see, you have so many ways to test and monitor your app during development time so you gain some confidence in how it will perform when you distribute it on the Store.
The last tip I would give about the emulator is that it's ok to just leave it up and running during development. There's no need to shut it down. When you launch and re-launch your app in debug mode from Visual Studio, part of that process is deploying the latest version of the app to the phone. It's time consuming to re-launch the Emulator each time, and Visual Studio will connect to an existing Emulator instance when it needs to.
So to recap, the Emulator is a great tool that allows you to quickly deploy your app during development to a virtualized Windows Phone. We looked at how to test different device screen sizes and memory constraints, how to manipulate the emulator to test for rotation and motion, how to make the phone think it is located geographically in a specific place, and much more. We'll use these skills extensively throughout this series.