Windows Phone Login

In this article i will write about our lessons learned - WP7 login page development.

Windows Phone apps are composed of pages that exist on a backstack and
can be reversed by user with the hardware back key.

There are some screens you do not want to come back. Like the login screen.
After successfully logged in, the login screen should removed from the backstack.
But explicit navigating away and from the login screen will cause to infinitly growing up your backstack. There are some solutions of keeping screens out of the backstack.

The Xing-App main page is a panorama control. The first approach for a login was kind of interesting.
We implement the login screen as a panorama item. This item is visible when you are not logged in. After successfully logged in, the item is hidden. The other items have the inverse behavior. 
In this solution we prevent the backstack problem.

While thinking about a different solution, we discussed the difference between transition and navigation. Navigation is a transition between different places. A Page is a place with a state.
But what is with this stateless pages? Here we have this splash screen or our login screen.
A common way to implement a login screen is as the first page of your app.

But is it really what you want?
While thinking about this, we came to that point the login screen can come up from everywhere in our app. The login screen has no place and it is stateless.

source: http://blogs.msdn.com/b/ptorr/archive/2010/08/28/introducing-the-concept-of-places.aspx

It is useful for example when you loose your access key and you have to login again.
The login page will popup at this place and you can continue after success.
The Silverlight Popup control is a great solution for showing content that (partially) covers the screen without doing a full navigation.You can also override the back key pressed event to handle the hardware back key to have more control over the popup.

This login behavior can also be useful for other platforms.

Windows Phone Marketplace Test Kit

There is a new Toolkit for WP7 available.
The Windows Phone Marketplace Test Kit help to prepare your application to be accepted in the Marketplace.
The Test Kit enables you to identify and fix issues prior submission.
You can use the test kit to evaluate applications that target Windows Phone OS 7.1 or later and it is part of the Windows Phone SDK.
Here are some of the tests from the msdn page:

• Whether the specified images and screenshots meet certification requirements.
• Whether the application icon and background image used in the application meet the certification requirements.
• What capabilities the application uses.
• Whether the XAP meets size requirements and whether the application manifest is valid
• Whether the application handles errors properly.
• Whether the application starts quickly enough to meet certification requirements.
• Whether the application exceeds memory usage requirements.
• Whether the Back button in the application is being used properly.
• Whether the application uses APIs that are not allowed on the phone.
• Whether the application uses APIs that are not allowed with background agents.

Using The Test Kit

Application Details

 

Automated Tests

Monitored Tests

Manual Tests

How to force Windows Phone Mango update early

Windows Phone Mango has started rolling out but not all customers are actually scheduled to receive the update on day one.
The entire process may take one month.
Those of us they won't wait here is a way to force the update immediately.

Program your phone directly on your phone

With TouchDevelop you do not need a separate PC. Scripts can perform various tasks similar to regular apps. Any TouchDevelop user can install, run, edit, and publish scripts. You can share your scripts with other people by publishing them. 

Let us see in the oracle and the impact on Software Engineering.
Will this spawn something like the VBA cottage industry?
In the future you might be able to create powershell script or similar for an enterprise.
Also you will now have not only a consumer device and can create useful software, after all if you can create your first game, then you can do just about anything. Other platforms will come with the same idea and end user can actually build useful products.

Unit Testing for Windows Phone

In this article I am going to talk about unit testing for Windows Phone 7.
First, there is no option for a windows phone test project within the IDE.

In our XING-App we use Silverlight Unit Test Framework and NUnit as the provider for test metadata.
We have an additional test project to run unit tests called TestRunner. 
Reference these Microsoft.Silverlight.Testing.dll and Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll assemblies from the Silverlight Unit Test Framework to these project.

Note: You will get a warning about adding silverlight 3 assembly, it is fine and you can click yes to continue.

Set up the testpage
Hide the system tray to have more space if you like.

Register NUnit as the provider for test metadata (attributes etc).  That tells the silverlight testing framework to use the NUnit test attributes instead of the default MSTest attributes.

tell the silverlight testing framework to use the NUnit test attributes

1.             UnitTestSystem.RegisterUnitTestProvider(
2.                 new NUnitProvider());

We use an additional project for the unit tests. 
So we need to add assemblies, that contains the tests. 

Add unit tests

1. settings.TestAssemblies.Add(typeof(Hook).Assembly);

Now any NUnit test fixture you add to the project should work.
Note that you can only have NUnit tests or MSTest tests in a project, not a mixed combination.

Create the testpage and let the unit testing framework take over.

Set the testpage

1.  var testPage = UnitTestSystem.CreateTestPage(settings)
2.      as MobileTestPage;
3.  BackKeyPress += (x, xe) => xe.Cancel =
4.      testPage.NavigateBack();
5.  (Application.Current.RootVisual
6.      as PhoneApplicationFrame).Content = testPage;

Using NUnit
Download the binaries from the nunit-silverlight project and add NUnit.Silverlight.Compatibility.dll and  NUnit.Silverlight.Metadata.dll as reference to the test project.
Tag your unit tests to run specific subsets of tests. When you start your TestRunner-App you can choose to only run tests with a certain tag, a certain set of tags, or not run tests with specific tags

Tagging a testmethod

1. [Test]
2. [Tag("UnitTestTag")]
3. public void AlwaysPass()
4. {
5.     Assert.IsTrue(true, "method intended to always pass");
6. }

Integration Tests
Now combine unit tests (modules) and test it!
For the integration tests we follow our created test plan to chose aggregates.

Id	XXXX
Test Type	Explorative / Serversimulation
Title	Logon is necessary after logout.
Test Goal	Ensure that the user has to log on again after he performs a log off.
Precondition	Same as XXXX
Steps	Automated Test: IntegrationTests.
Expected Result	The network news page is shown.
Note

Our WP7-App has a lot of asynchronous method calls like web service calls.
To test asynchronous methods you will first have to make sure your TestClass inherits from SilverlightTest.
Next, you will need to mark the test method as asynchronous. Finally, you will have to call EnqueueTestCompleted() to tell the test when it has completed.
If you do not call this then the test will never complete.

The XING-App make use of a TestBase class. This class inherits from SilverlightTest and overrides EnqueueConditional.
To make sure all tests end, EnqueueConditional becomes a timeout mechanism. The test will fails and EnqueueTestCompleted is called and the test is really completed.

Asynchronous testmethod timeout

1.             var timer = new DispatcherTimer();
2.             timer.Interval = new TimeSpan(0, 0,
3.                 ConditionalTimeout);
4.             timer.Tick += delegate
5.             {
6.                 // remember
7.                 // to stop timer or it'll tick again
8.                 timer.Stop();
9.                 throw new TimeoutException();
10.             };
11.             EnqueueCallback(timer.Start);
12.             base.EnqueueConditional(conditionalDelegate);
13.             EnqueueCallback(timer.Stop);

Fake test server
We are in the test process and we do not want to run the tests against the live XING-Server, so we need such as a fake XING server. This fake server also helped us in the development process.
During the development we got no test XING-Accounts. The only way to test was with our live accounts. 

Our fake server is a normal web service and is similar to the XING API. We also have functions like:

• make many users
• make visit
• make many messages
• make number of contacts

These helper functions are very useful to use this test server and to write easily these integration tests.
It was also very useful to test functionality against this test server. For example, if you need some contact requests.

wp7 emulator tip of the day: Adding an E-Mail account

Here you can find a useful hack to add an E-Mail account to your Windows Phone emulator.
These steps only works with the new Windows Phone SDK 7.1

wp7 emulator tip of the day: Use your keyboard

I am frustrated not be able to use my keyboard to input text in the windows phone emulator.
So login into our XING-App was a funny task every day.

But there is a shortcut to activate the hardware keyboard in the emulator.
You can use Page-Up to activate the hardware keyboard and Page-Down activates the normal software keyboard. You are now able to use your keyboard on your development machine by  pressing Page-Up.  You also can tab between fields.

More shortcuts are:

• F1 - hardware back button
• F2 - Hardware home button
• F3 - Hardware search button

Hope this tip will help you as much as it helps me. No more frustration!

XING-App for Windows Phone 7 Architecture

In this article I will write about our architecture for the XING-App for WP7 developed by Zühlke.

Most existing apps need connectivity to run properly. You start your app and the first you see is a "loading"-icon and in many cases working without any connection is impossible.

The default state of the XING-App is offline. First we load the local cache and display the content. The user decides when to synchronize with the server. Especially for XING it is quite useful to be able to have a quick look in your XING-Network at all times, even if you're offline. Also you will have no roaming problems. When you run the app for the first time or have no data locally cached then the app initially synchronizes with the server and saves the data in the local cache.

The application is developed using the MVVM-Pattern shown in the picture below.

Services contain web service calls. All method calls contain a success callback and an error callback. Service methods are only called from background threads. The web service responses are parsed and translated into objects. 

sample service call

1.     IsSyncing = true;
2.     contactService.GetContacts(
3.         userScope.UserId, updatedContacts =>
4.         {
5.             this.userScope.Contacts.Data = updatedContacts;
6.             userScope.Contacts.LastUpdated = DateTime.UtcNow;
7.             IsSyncing = false;
8.             HandleSuccessHandlers();
9.             Status = StoreStatus.Online;
10.         },
11.         Dispatch.Action<Exception>(ex =>
12.         {
13.             RemoveSuccessHandle(callback);
14.             IsSyncing = false;
15.             HandleError(ex);
16.         }));

Stores observe the access to a web service and manage the cache.  

The store decides if the data will come from the cache or from the web service. After the application starts the data is loaded from isolated storage. When the application is shut down,  data is saved into isolated storage. Each store has a LocalStorage class for loading and saving. These classes load the content from their own file and save the data using a BinarySerializer. The store contains the information when the data was last synchronized. And each store has its own validation time for the cache.

A store has an Offline-, Online or Broken-State.

 

The store has no UI code like INotifyPropertyChanged or ICollectionChanged. Views receive the requested data from the success callback. Each store method is called with a success callback, most likely from the ViewModel, PropertyChanged event is called to inform the UI. If an error occurs the StatusChanged event from the Store is called. In our XING-App each ViewModel implements the StatusProvider interface to handle the status changed in the UI. Therefore each page has a statusbar to display the current status. For example if there is currently no connectivity the offline status is displayed along with the time when the data was last synchronized. The color of the status depends on its state.

sample store call

1.     IsSyncing = true;
2.     visitStore.GetMoreVisits(loadedVisits =>
3.     {
4.         AppendVisits(loadedVisits);
5.         RaisePropertyChanged("HasMoreData");
6.         IsSyncing = false;
7.     });

Store methods and events are only called from the UI-Thread.

The stores do not know one another.

If several methods are called in a row then the success callbacks are queued. The first web request is called and no further success callback are called during the synchronization. After the web response the upcoming success callbacks are called.

In order to ensure a better response and a better feedback of our data for the UI, the success callback is first called with the data from the local cache. The success callback is called again after the web request has sent its response.  

The ViewModel prepares the data for the UI. If a store method is called to receive data, we will actually send a web request.

All methods in the ViewModel are called from the UI-Thread. ViewModels do not know one another. You can use a message infrastructure to inform other ViewModels and your business logic is done.

XING-App for Windows Phone 7 - developed by Zühlke

Our "baby" say hello world.
It is done, our first Windows Phone 7 app is released!
Download

Follow the next articles to find out more about the XING App development.

MVVM Light for Windows Phone EventToCommand Memory Leak

When you use EventToCommand like this, be careful!

<Button>
  <i:EventTrigger EventName="Click">
     <mvvmLight:EventToCommand Command="{Binding MyCommand "/>

  </i:EventTrigger>

</Button>

The memory usage will be growing up.

The Attach of the DependencyObject is working fine, but the detach will never called. That causes severe memory issues.

It's a known issue on codeplex:

http://mvvmlight.codeplex.com/workitem/7293
http://mvvmlight.codeplex.com/workitem/7512

We tried to find good ways to detach our event handler. But to remove the EventToCommand stuff was much easier than any workaround we found.

Windows Phone 7.1 "Mango" new application profiler beta 1 throws ArgumentNullException parameter s:

The cool new Windows Phone 7.1 update called "Mango" is released and I wanted to try the new cool profiler for my current App. The first big thing was to get it running for the new release. You have to update all your used libraries to the new 7.1 version. I started to profil my app wich caused a crash. It took me several hours to figure out the problem. The issue is that the PropertyChanged event throws a ArgumentNullException with parameter s: I have still no solution for it and I am just waiting at Microsoft to get a hotfix for it.