Monthly Archives: September 2011

Running for the first time

This time I cannot be objective, because today I created an Android application for the very first time and I created a Windows Phone application (definitely not for the first time). So what I am really doing is comparing my first Android experience with my first Windows Phone experience, way over a year ago already. At that time, even with the beta tools installation was a simple one click operation, after which I could create a typical hello world application and immediately execute it on the emulator. The whole process took less than 30 minutes. Even though Silverlight was new for me, I was of course familiar with Visual Studio, C# and the .NET (Compact) Framework.

Today I did something similar. I already described my experience installing the Android development tools. Now it is time to try my first application on Android. I have to admit that I have no experience at all with Java or with Eclipse, so my comparison is a bit unfair. That is also the reason to chose a very simple Hello World application to get going. Of course this is a good idea in general, since such a simple application can quickly be used to verify if the development environment is installed correctly and to see if things simply work.

Before I could get to work, I first needed to add an Android Platform in my Eclipse environment. This additional step is necessary because Eclipse is a versatile development environment and because there are different Android versions. The other thing that needs to be done is to actually create an Android Virtual Device, which is the emulator that can be used as target to run / test applications. Building an AVD takes some time, but is not really a bad thing. At least you know that you will have a target for a specific Android version.

Creating a new project differs slightly between Windows Phone and Android. The same is true for the functionality of the application. The two differ because they are using different development environments and programming languages, but they are of similar complexity.

My Windows Phone application looks like this, created in Visual Studio 2010 Express for Windows Phone:

Visual Studio 2010 With my app

Deliberately I created all functionality in code to better compare this application to the Android application. A corresponding Android application looks like this:

Eclipse with my Android App

Compiling and deploying the Windows Phone application to the emulator was no problem at all. The emulator booted within 30 seconds after which the application was deployed and automatically started. It was a bit harder to get my Android application up an running in an emulator though. The first problem I ran into was a cryptic error I got when trying to deploy my Android application. The error was shown in the Eclipse console window:

image

It turns out that this error is caused by spaces in directory paths. I am not sure if this is an Eclipse issue or an Android SDK issue, but a solution to this problem was to create a logical link to the folder where the Android SDK was installed using a Command Prompt. This did the trick (of course after making sure inside Eclipse that the IDE now pointed to the newly created logical link).

MKLINK /J C:\Android "C:\Program Files (x86)\Android\android-sdk\"

Adding this link assured that the AVD did start. However, I still could not deploy the application to the virtual machine, this time because of another error:

image

It seems that this was simply a timeout error, because it takes quite some time to boot the AVD. Once it was entirely booted I tried running the application again and this time it was successful.

image

The scores for this exercise are clear. I needed to solve two (more or less cryptic) problems before I was able to run my application on the Android emulator. Deploying to the Windows Phone emulator caused no problems at all. Booting time for the Windows Phone emulator was around 30 seconds, the Android (3.2) emulator needed several minutes.

After installing the tools, my score was:

Windows Phone vs. Android: 1 – 0

After developing and creating a Hello World application, the scores are now:

Windows Phone vs. Android: 4 – 1

The reason why Windows Phone is a clear winner for me is the fact that deploying to the emulator just works and that the emulator boots relatively fast. The point I gave to Android might in fact belong to Eclipse. I really love maximize icon in the edit window, great for demos and something that I would not mind having in Visual Studio as well.

Over the upcoming weeks I will continue to compare Windows Phone with Android application development. So far there is a clear winner for me, but I want to really and honestly compare several aspects of developing applications on different platforms. Oh, just to be complete: My winner today is without any doubt

Windows Phone.

Ease of installation

Of course I am a bit biased, even though I am trying to be objective, independent and open minded. Over the last hour or so I have been busy setting up an Android development environment. If you are wondering why, it is not just out of curiosity, I am also preparing for a training I am taking next week. Over time it is going to be cool to find and understand differences between developing for Windows Phone and for other mobile platforms. I am planning to share my experiences in one way or another.

When I started developing Windows Phone applications, I just went to the App Hub, clicked on the link to download the free tools, and waited for Visual Studio 2010 Express for Windows Phone and Expression Blend 4 for Windows Phone to download and install. The development / design environment comes with a great emulator and within 30 minutes I was up and running (yes, I was using a slow Internet connection).

Today the story was slightly different. In order to start developing my first Android application, I had to download and install a Java SDK for which I went to Oracle. The next step was to download and install the Eclipse IDE for Java EE. Everything so far installed without any problem, but there is more to install. The next thing to install is the Android SDK, which has a nice Windows Installer. But wait ….  what is installed is the SDK Starter Package, with which you can download the SDK’s you need for your particular target. It looks like the SDK Starter Package is a specific download manager for multiple Android SDK’s. The challenge now is to find out which SDK I need. I decided to just install the latest version, being SDK Android Plaform 3.2, API 13, revision 1. Hopefully this is the right SDK to get started. Finally, the ADT plugin for Eclipse is needed. Installing the plugin is done from inside Eclipse. In order to get the plugin, you have to run through 8 different, but easy steps. Once Eclipse is restarted, it now should be possible to develop my first Android application. Now, instead of 30 minutes to install a development environment, it took me over 2 hours. However, remember, this is the very first time that I am going to work with Eclipse, a Java SDK and Android. I can imagine that experienced Android developers install the tools way faster than I did. However, so far my conclusion for the day:

Windows Phone vs. Android: 1 – 0.

Introducing Windows Embedded Handheld

After the release of Windows Phone to the market, you might wonder what became of Windows Mobile. If you are not really familiar with the embedded product line of Microsoft, you might think that Windows Mobile is completely gone. However, if you take a look at a particular Windows Embedded product, being Windows Embedded Handheld, you can see that this is the continuation of Windows Mobile, modernized and rebranded. If you want full device access and be able to use all exposed Win32 API’s, if you want freedom to deploy applications outside marketplace, if you want interoperability possible between different applications, Windows Embedded Handheld might be your best choice.

Windows Phone Application Development & Debugging – Deactivation versus Tombstoning

While creating an update of an existing application I ran into a problem that sometimes occurred when the application was moved to the background. It turned out that the application behaved consistent with no exceptions raised when it was tombstoned after being moved to the background. However, the application sometimes crashed when it was deactivated and immediately became the executing application again without being tombstoned. In a later post I will explain the specific problem that caused the application to crash, for now I want to focus on ways to easily test deactivation scenarios.

Visual Studio 2010 has great support to test tombstoning scenarios for Windows Phone applications. Simply start debugging an application on a device or on device emulator and click the start button on the device (emulator). You will notice that the application moves to the background but that Visual Studio does not terminate its debugging session. Putting a breakpoint inside Activated / Deactivated event handlers shows us that the application is indeed being tombstoned / resurrected.

Visual Studio and Tombstoning

The debugger shows that the application is still running even though the application is no longer visible on the device. By using the back key on the device, it is possible to return to the application and to continue debugging it. However, if you start the application again on the device (so not using the back key), the debugger terminates. This means that a brand new instance of the application was started. Inside an application, it is possible to distinguish between a new instance being started and resurrection from being tombstoned by acting on the Launching or Activated events respectively. In both cases, the constructor of the page that becomes visible will be executed. More information about the application life cycle of a Windows Phone application can be found in this excellent series of blog entries by Yochay Kiriaty.

There are situations where an application is moved to the background without being tombstoned. In those situations, the application simply remains resident in memory, with its process being kept alive. When the application is activated again, it simply continues running without the need to create a new physical instance of the application. For end users the behavior is identical to tombstoning, after all, the application becomes invisible when another application starts executing. For developers there is a difference though, because no Launching or Activated event is raised and no constructor code (for instance for the currently visible page) is executed. To be able to consistently test application deactivation requires some additional work. One of the ways to ‘force’ deactivation over tombstoning is by starting a PhotoChooserTask. In my own application I simply use the application bar to add a new ApplicationBarIconButton to display a PhotoChooserTask.

To assure that this ApplicationBarIconButton is only visible in Debug mode, a bit of conditional compilation is needed. The following code snippet shows how to create a new ApplicationBarIconButton programmatically, add it to the ApplicationBar and add an event handler to its click event.

Adding an ApplicationBar Item
  1. #if DEBUG
  2. PhotoChooserTask _pt;
  3. #endif
  4.  
  5. public MainPage()
  6. {
  7.     InitializeComponent();
  8.  
  9. #if DEBUG
  10.     _pt = new PhotoChooserTask();
  11.  
  12.     this.ApplicationBar.IsVisible = true;
  13.  
  14.     ApplicationBarIconButton pauseButton = new ApplicationBarIconButton
  15.     {
  16.         Text = "Pause App",
  17.         IconUri = new Uri("/Images/appbar.transport.pause.rest.png", UriKind.Relative),
  18.         IsEnabled = true
  19.     };
  20.  
  21.     pauseButton.Click += new EventHandler(pauseButton_Click);
  22.     this.ApplicationBar.Buttons.Add(pauseButton);
  23. #endif
  24. }

Of course, adding a button to an existing ApplicationBar only works if the application has 3 or less ApplicationBarButtonIcons in use. An alternative could for instance be adding a MouseLeftButtonDown event handler to the application’s title. When clicking the ApplicationBarButtonIcon you created specifically for debug purposes, what you now can do is display the PictureChooserTask. This results in your application being pushed to the background, without being tombstoned.

Forcing us to the background
  1. void pauseButton_Click(object sender, EventArgs e)
  2. {
  3.     _pt.Show();
  4. }

This approach makes it relatively easy to test the different scenarios for your application going to the background and returning to the foreground again. Here are the results in a little test application.

TombstoningOrNot

In the left screen you can see the application immediately after the main page became visible. In the center screen you see the result of clicking the pause button, after which a PhotoChooserTask was activated and closed again. What you can see is that there is no Application_Deactivated / Application_Activated combination. You can also see that no constructor is called after returning from the PhotoChooserTask. In other words, the application is not tombstoned while the PhotoChooserTask is active. Finally, the right screen shows how the application returns from being tombstoned. In this case constructors are called and Application_Activated is raised.

The issue I had in one of my applications had to do with counting on constructors to be called to dynamically add a few controls to my visual tree.

Note: This blog entry is applicable for Windows Phone 7. For the next version of Windows Phone (codenamed Mango), developers can choose between tombstoning and fast application switching by setting the corresponding property in the project settings. Fast application switching could be considered as another state in the application’s life cycle, being very similar to the situation that was described in this post using the PhotoChooserTask.

MEDC Revitalized?

This is something I really hope will happen one day. Until 2008, Windows Embedded and Windows Mobile developers had their own conference, MEDC. Since that time, Windows Embedded and Windows Mobile developers could find some interesting content at the various Tech-Ed conferences around the world. However, it is of course very different to be part of a larger conference, owning one track with something like 16 breakout sessions, or having your own dedicated conference with perhaps as much as 100 breakout sessions. At Tech-Ed, it seems that Windows Embedded presence is getting smaller and smaller. Of course the mobile arena has changed a lot over the last 2 .. 3 years. Windows Mobile has been rebranded to Windows Embedded Handheld. Apart from that, Windows Phone, being a brand new platform has been released. Windows Phone technical content has been presented at MIX and at Tech-Ed over the last two years. Windows Phone will also at least be present at the brand new Build Conference later this month.

So what about Windows Embedded in all its flavors? Some time ago, there was an intriguing pre-announcement here at the Windows Embedded website. The information about a possible new embedded developer conference is still there. However, I was just looking at the listed twitter feed for updates around this conference, but I didn’t find any updates. Hopefully this announcement was not just a teaser. I think it would be great if there would be another large scale developer conference, organized by Microsoft and dedicated to Windows Embedded technologies. To make my dream even better …. It would be great if Windows Phone would be present at such a conference as well, after all, Windows Phone runs on one of the Windows Embedded Operating Systems.