Answers to Questions

On this page:	Download:
Chapter 2, Building the Mobile Client | Chapter 3, Using Services on the Phone | Chapter 4, Connecting with Services

Chapter 2, Building the Mobile Client

1. Which of the following are good reasons to use the MVVM pattern for your Windows® Phone application?

   1. It improves the testability of your application.
   2. It facilitates porting of the application to another platform, such as the desktop.
   3. It helps to make it possible for designers and developers to work in parallel.
   4. It may help you avoid risky changes to existing model classes.

   Answer:

   (a) True. This is a valid reason for using the MVVM pattern. (b) False. The view and view model are often tightly coupled and use features of the Windows Phone platform, making these elements difficult to port. (c) True. Designers can work on the XAML files that make up the view independently of the developers working on the code in the view models. (d) True. Sometimes you may have existing model objects that encapsulate complex domain logic that you don't want to change. In this case, the view model acts as an adaptor, exposing the model to the view.

   For more information, see the section, "Benefits of MVVM," in Chapter 2, "Building the Mobile Client."

2. Which of the following are good reasons not to use the MVVM pattern for your Windows Phone application?

   1. You have a very tight deadline to release the application.
   2. Your application is relatively simple with only two screens and no complex logic to implement.
   3. Windows Phone controls are not ideally suited to the MVVM pattern.
   4. It's unlikely that your application will be used for more than six months before it is completely replaced.

   Answer:

   (a) True. The MVVM pattern tends to add complexity to the application, especially during the initial development. However, you should carefully evaluate the long-term benefits of using the MVVM pattern. (b) True. Such a simple application may not warrant the overhead of implementing the MVVM pattern. (c) False. The Windows Phone controls support binding in the same way as standard Microsoft® Silverlight® browser plugin controls. In some cases though, you may have to develop custom behaviors to get specific functionality. (d) True. One of the advantages of the MVVM pattern is improved maintainability. For an application with a short shelf life, in may not be worth the overhead of the development process associated with the MVVM pattern.

   For more information, see the section, "Benefits of MVVM," in Chapter 2, "Building the Mobile Client."

3. Which of the following are correct about tombstoning?

   1. Tombstoned applications have been terminated.
   2. Tombstoned applications remain intact in memory.
   3. Information about a tombstoned application's navigation state and state dictionaries are preserved for when the application is relaunched.
   4. A device will maintain tombstoning information for up to five applications at once.

   Answer:

   (a) True. The tombstoning process does terminate an application. (b) False. The tombstoning process terminates an application; therefore it does not remain in memory. (c)True. When an application is tombstoned, information about its navigation state and state dictionaries populated by the application during the Deactivated event are preserved. (d) True. A Windows Phone device will maintain tombstoning information for up to five applications at a time.

   For more information, see the section, "The Structure of the Tailspin Surveys Client Application," in Chapter 2, "Building the Mobile Client."

4. Which of the following describe the role of the view model locator?

   1. The view model locator configures bindings in the MVVM pattern.
   2. In the Tailspin mobile client, the view model locator is responsible for instantiating view model objects.
   3. The view model locator connects views to view models.
   4. Data template relations offer an alternative approach to a view model locator.

   Answer:

   (a)False. Although the view model locator establishes the link between a view and a view model, the bindings are configured in the view's XAML code. (b)False. In the Tailspin application, the dependency injection container instantiates the view model objects and manages their lifetimes. (c)True. This is the core functionality of the view model locator. (d) True. This is an alternative way to connect views to view models.

   For more information, see the section, "Connecting the View and the View Model," in Chapter 2, "Building the Mobile Client."

5. Where does the Back button take you?

   1. To the previous view in the navigation stack.
   2. It depends on what the code in the view model does.
   3. If the current view is the last one in the navigation stack, you leave the application.
   4. If your application is on the top of the phone's application stack, it takes you back to your application.

   Answer:
   (a) True. This is what happens within your application. (b) False. The behavior of the hardware Back button is determined by the operating system. (c)True. This returns you to the phone's Start screen. (d) True. You can use the Back button to navigate back to your application from the phone's environment.

   For more information, see the section, "Page Navigation," in Chapter 2, "Building the Mobile Client."

6. Why should you not use code-behind when you're using the MVVM pattern?

   1. The view model locator always intercepts the events, so code-behind code never executes.
   2. The MVVM pattern enforces a separation of responsibilities between the view and the view model. UI logic belongs in the view model.
   3. If you are using the MVVM pattern, other developers will expect to see your code in the view model classes and not in the code-behind.
   4. Code-behind has a negative effect on view performance.

   Answer:
   (a) False. The view model locator does not intercept control events. (b) True. This is the separation of responsibilities between the view and the view model. (c) True. This is the expected place for UI logic. (d) False. Whether code is in code-behind files or in view model classes has no effect on the application's performance.

   For more information, see the section, "Using the Model-View-View Model Pattern," in Chapter 2, "Building the Mobile Client."

Chapter 3, Using Services on the Phone

1. The Data Protection API (DPAPI) can be used to encrypt and decrypt data in isolated storage. What does the DPAPI use as an encryption key?

   1. A user-generated private key.
   2. The user credentials.
   3. The phone credentials.
   4. The user and phone credentials.

   Answer:

   (a)False. The Windows Phone platform does not support generated private keys for encrypting and decrypting data in isolated storage. (b) False. User credentials alone are not used to encrypt and decrypt data in isolated storage. (c) False. Phone credentials alone are not used to encrypt and decrypt data in isolated storage. (d) True. The DPAPI solves the problem of explicitly generating and storing a cryptographic key by using the user and phone credentials to encrypt and decrypt data in isolated storage.

   For more information, see the section, "Security," in Chapter 3, "Using Services on the Phone."

2. What happens when your application is reactivated?

   1. You return to the first screen in your application.
   2. The operating system makes sure that the screen is displayed as it was when the application was deactivated.
   3. The operating system recreates the navigation stack within your application.
   4. The Launching event is raised.

   Answer:

   (a) False. You are returned to the last screen that was visible before the application was deactivated. (b) False. It's your application's responsibility to restore whatever state is required to reset the application's appearance and behavior. (c) True. If you were several pages deep within the application when it was deactivated, you will still be several pages deep when the application is reactivated. (d) False. The Launching event is raised when the application is run from scratch, not when it is reactivated. There is an Activated event that is raised when the application is reactivated.

   For more information, see the section, "Handling Activation and Deactivation," in Chapter 3, "Using Services on the Phone."

3. What data should you save when you handle the deactivation request?

   1. State data required to rebuild the state of the last screen that was active before the application was deactivated.
   2. State data required to rebuild the state of previous screens that the user had navigated through before the application was deactivated.
   3. Data that is normally persisted to isolated storage by the application at some point.
   4. The currently active screen.

   Answer:

   (a) True. It's the application's responsibility to manage the state data used to redisplay the UI, although the operating system will remember which page in your application was visible when it is deactivated. (b) True. It's the application's responsibility to manage the state data used to redisplay the UI, including any screens in the application's navigation stack. (c) True. There is no guarantee that an application will be reactivated, so you should save anything important. (d) False. The operating system will record which screen was active for you.

   For more information, see the section, "Handling Activation and Deactivation," in Chapter 3 "Using Services on the Phone."

4. Why does Tailspin use the Reactive Extensions (Rx) for .NET?

   1. To handle notifications from the Microsoft Push Notification Service.
   2. To handle UI events.
   3. To manage asynchronous tasks.
   4. To make the code that implements the asynchronous and parallel operations more compact and easier to understand.

   Answer:
   (a) False. You don't need to use the Rx for this task. (b)False. You don't need to use the Rx for this task. (c) True. This is a core use of the Rx. (d) True. This is a benefit of using Rx.

   For more information, see the section, "Synchronizing Data between the Phone and the Cloud," in Chapter 3, "Using Services on the Phone."

5. What factors should you take into account when you use location services on the phone?

   1. The level of accuracy your application requires for its geo-location data.
   2. Whether the device has a built-in GPS.
   3. How quickly you need to obtain the current location.
   4. Whether the user has consented to your application using the phone's GPS data.

   Answer:

   (a) True. You can specify the required level of accuracy, and this will affect how the phone obtains its current position: using GPS, or from triangulation. (b) False. The hardware specification for the Windows Phone device includes a GPS module. (c) True. Using GPS is often slower, though more accurate, than triangulation. (d) True. The guidelines for the phone state that you must obtain the user's consent before using geo-location data from the phone in your application.

   For more information, see the section, "Using Location Services on the Phone," in Chapter 3, "Using Services on the Phone."

6. Which factors constrain the use of a ResourceIntensiveTask agent?

   1. Resource-intensive agents do not run unless the Windows Phone device is connected to an external power source.
   2. Resource-intensive agents do not run unless the Windows Phone device has a network connection over Wi-Fi or through a connection to a PC.
   3. Resource-intensive agents do not run unless the Windows Phone device’s battery power is greater than 90%.
   4. Resource-intensive agents do not run unless the Windows Phone device screen is locked.

   Answer:

   (a) True. A Windows Phone device must be connected to an external power source for a ResourceIntensiveTask agent to run. (b) True. A Windows Phone device must have a network connection over Wi-Fi or through a connection to a PC for a ResourceIntensiveTask agent to run. (c) True. A Windows Phone device must have battery power of greater than 90% for a ResourceIntensiveTask agent to run. (d) True. A Windows Phone device screen must be locked for a ResourceIntensiveTask agent to run.

   For more information, see the section, "Synchronizing Data between the Phone and the Cloud," in Chapter 3, "Using Services on the Phone."

Chapter 4, Connecting with Services

1. How does Tailspin pass authentication requests to the web service?

   1. Tailspin uses basic authentication with the credentials in an authorization header.
   2. Tailspin uses Windows Live® ID.
   3. Tailspin uses OAuth.
   4. Tailspin uses the Windows Identity Framework (WIF).

   Answer:
   (a) True. This is Tailspin's current approach. (b) False. However, this might be a mechanism for Tailspin to adopt in the future. (c) False. However, this might be a mechanism for Tailspin to adopt in the future. (d) False. Tailspin uses WIF to process the authentication request in the web service.

   For more information, see the section, "Authenticating with the Surveys Service," in Chapter 4, "Connecting with Services."

2. What notification methods does the Microsoft Push Notification Service (MPNS) support?

   1. Toast notifications.
   2. Tile notifications.
   3. SMS notifications.
   4. Raw notifications.

   Answer:
   (a)True. Used for important notifications for immediate viewing, such as breaking news. (b) True. Used for informational notifications such as a temperature change for a weather application. (c) False. This is not a feature of MPNS. (d) True. You can use raw notifications in addition to tile and toast notifications to send information directly to your application.

   For more information, see the section, "Notifying the Mobile Client of New Surveys," in Chapter 4, "Connecting with Services."

3. Which of the following are elements of a toast notification?

   1. A title string that displays after the application icon.
   2. A content string that displays after the title.
   3. A background image.
   4. A parameter value that is not displayed but is passed to the application if the user taps on the toast.

   Answer:

   (a)True. Toast notifications contain a boldface title string that displays immediately after the application icon.(b) True. Toast notifications include a non-boldface content string that displays immediately after the title. (c) False. This is not an element of a toast notification. (d) True. Toast notifications include a parameter value that is not displayed but is passed to the application if the user taps on the toast.

   For more information, see the section, "Notifying the Mobile Client of New Surveys," in Chapter 4, "Connecting with Services."

4. Why does the client need to register with MPNS before it can receive notifications?

   1. Because MPNS requires clients to authenticate before it will send notifications.
   2. Because MPNS can then notify your service that the client is ready to receive notifications.
   3. Because the client must obtain a unique URI to send to your service.
   4. Because the free version of MPNS has a limit on the number of clients who can receive notifications from your service.

   Answer:

   (a) False. There's no requirement for MPNS clients to authenticate. (b) False. It is not the responsibility of MPNS to notify your service about clients. Clients must also register directly with your service. (c) True. Your client obtains a unique URI from the MPNS that it then forwards to your service. Your service can then pass the URI to the MPNS when it asks the MPNS to notify your client. (d) False. The free version of the MPNS has limits on the number of messages that you can send in a day, but does not limit the number of clients.

   For more information, see the section, "Notifying the Mobile Client of New Surveys," in Chapter 4, "Connecting with Services."

5. How does Tailspin transport data between the client and the web service?

   1. Tailspin uses the Microsoft Sync Framework to handle the data transport.
   2. Tailspin uses the Windows Communication Foundation (WCF) Data Service framework.
   3. Tailspin uses data transfer objects with a WCF REST endpoint.
   4. The mobile client application uploads directly to Windows Azure™ technology platform blob storage.

   Answer:

   (a) False. However, Tailspin may consider this in the future. (b) False. However, Tailspin may consider this in the future when it fully supports Windows Azure table storage. (c) True. Tailspin currently uses this approach. The data transfer requirements are relatively simple, so this approach was not too difficult to implement. (d) False. This approach would not be secure or robust enough. The application also uses Windows Azure table storage.

   For more information, see the section, "Accessing Data in the Cloud," in Chapter 4, "Connecting with Services."

6. Why does Tailspin filter data on the server and not on the client?

   1. To minimize the amount of data moved over the network.
   2. To simplify the application.
   3. For security reasons.
   4. To minimize storage requirements on the phone.

   Answer:

   (a) True. Bandwidth costs are a significant consideration for any mobile application. (b) False. In some ways this complicates the application because the client has to send the filter criteria up to the server. (c) False. Not in Tailspin's scenario, but in other applications the filtering may determine what data the user is allowed to see rather than what they want to see. (d) True. This is not the primary reason for Tailspin but it does mean that the phone does not download data that is not relevant to the user and cache it while it filters.

   For more information, see the section, "Filtering Data," in Chapter 4, "Connecting with Services."

Next Topic | Previous Topic | Home

Last built: May 25, 2012