101 Windows Phone 7 Apps, Volume I: Developing Apps 1-50
Lessons
- Orientation
- On-Screen Keyboard
- Hardware Keyboard
- Text Box
- Input Scopes
- Scroll Viewer
- Size Properties
- Margins and Padding
- Emulator-Specific Code
Click to view larger image
The “In Case of Emergency” app is meant to help save your life in the event you become a victim of a serious accident. The idea is that if someone finds you in a state in which you are unable to communicate, that person might check your phone for important information about yourself. (Hopefully this is done after calling 911!) If this person launches the “In Case of Emergency” app, they will see an emergency contact whom he/she can call, as well as any important medical information that the paramedics should know.
To help this Good Samaritan stumble upon your “In Case of Emergency” app, its app icon and tile icon are bright red, as shown in Figure 3.1. Basically, this app is for super-prepared people who don’t password-protect their phones! As ridiculous as this might sound, there is a market for this type of app.
Figure 3.1 The tile for “In Case of Emergency” clearly stands out (unless the user’s theme accent color is red).
Although the “In Case of Emergency” title fits (barely) in the app list, it does not fit on the tile. Therefore, this app modifies the default token title in the application manifest (as described in Chapter 1, “Tally”) to simply “ICE,” a somewhat-common abbreviation for “In Case of Emergency.” (Some people store a contact on their phone named “ICE,” in case their rescuer is familiar with this convention.)
This is the first app that must do work to support multiple orientations and the first app that involves typing, so before creating it we will explore the following three topics:
- Orientation
- The On-Screen Keyboard
- The Hardware Keyboard
Orientation
As shown in the preceding chapter, Windows phones support three orientations:
- Portrait (vertical, with the screen above the hardware buttons)
- Landscape Left (horizontal, with the screen to the left of the hardware buttons)
- Landscape Right (horizontal, with the screen to the right of the hardware buttons)
What is the difference between a page’s SupportedOrientations and Orientation properties?
SupportedOrientations is the only one you should worry about. Most of the apps in this book remove the confusing Orientation property, so it made its only appearance so far inside the initial contents of MainPage.xaml in Chapter 1. Orientation is for design-time use only, so Visual Studio and Expression Blend display the page in the desired orientation. Setting Orientation has no effect at run-time.
To support orientations other than portrait, you can change the value of a page’s SupportedOrientations property to Landscape to only support the two landscape orientations, or to PortraitOrLandscape to support all three. You cannot choose to support only one of the landscape orientations; if your app works with one of the landscape orientations then it must work for both of them. Therefore, do not assume which side of the screen the application bar resides for a landscape page. As seen in the preceding chapter, it can appear on either the left or right side.
What orientation(s) should my app support?
If users never need to do any typing inside your app, it’s okay for it to be portrait-only. After all, many built-in phone experiences (such as Start and the app list) are portrait-only, and auto-rotation can sometimes be more annoying than helpful. When I’m lying down in bed and trying to use my phone, automatic rotation to landscape is frustrating! Therefore, I recommend that apps that support all orientations consider providing an “orientation lock” feature. Chapter 4, “Stopwatch,” shows how to do this.
For apps that involve typing, however, supporting landscape orientations is practically mandatory (unlike with iPhone). The reason for this is that some phones have a landscape-oriented hardware keyboard, and typing on it would not be a great experience if its orientation doesn’t match the screen’s orientation.
Supporting only landscape is okay for some games and novelty apps, but weird for anything else. Of course, if such an app involves typing (such as typing a user name for a high score), those parts should support the portrait orientation for the sake of phones with a portrait-oriented hardware keyboard!
When you set SupportedOrientations to PortraitOrLandscape, the page automatically rotates to the proper orientation at the appropriate times (based on the angle the user holds their phone and whether a hardware keyboard is activated). This rotation is instant; your content is not animated. System-provided components, such as the status bar, application bar, message boxes and other notifications, adjust automatically as well, but with animations.
How can I get orientation changes to animate, as seen in built-in apps such as Internet Explorer, Messaging, and Outlook?
Animated orientation changes are one of many nice touches that are not exposed to third-party apps. With transitions from the Silverlight for Windows Phone Toolkit, described in Chapter 19, “Animation Lab,” you can easily perform animated orientation changes similar to the built-in apps.
What are the screen dimensions given to my app?
All Windows phones currently have Wide Video Graphics Array (WVGA) screens that are 480 pixels wide and 800 pixels tall. Your app can consume all of this space if you are not showing the status bar or application bar. In the portrait orientation, the status bar consumes 32 pixels of height and a fully-opaque application bar consumes 72 pixels of height. In the landscape orientations, the status bar and application bar each consume 72 pixels of width because they don’t move from their original locations, as seen in the preceding chapter.
Another consideration when designing your user interfaces is that toast notifications, when they appear, temporarily cover the top 60 pixels of the screen. If your app is used in the midst of a phone call, a bar with call information covers the top 64 pixels of the screen. When the user adjusts the phone’s volume or interacts with the audio transport controls, the resulting volume control covers the top 93 pixels. This is one of the reasons that the standard page design of showing the application name at the top works out nicely, as only that gets covered in these cases.
That said, it’s best to avoid depending on the specific screen dimensions. Future phones will undoubtedly have different dimensions. You can dynamically discover the resolution with the following two properties:
(Application.Current.RootVisualas FrameworkElement).ActualWidth (Application.Current.RootVisualas FrameworkElement).ActualHeight
or:
Application.Current.Host.Content.ActualWidthApplication.Current.Host.Content.ActualHeight
You can also discover the current page’s dimensions (minus the status bar and application bar, if applicable) by checking the page instance’s ActualWidth and ActualHeight properties.
If you wish to perform a custom action when the orientation changes, such as a full-screen animation or custom rearranging of elements, you can leverage a page’s OrientationChanged event.
