It has been a long time since my last blog entry and many things have changed (including my job). Even though the site is still called DotNETForDevices, the topic will become broader from now on. Today, like everybody else of course, I am really involved in IoT solutions. From now on, I will irregularly blog about IoT related topics. On the cloud side, I will write about Azure, on the device side it will most likely be a mix of Windows and Linux powered devices. The world of IoT is huge and moving fast. However, sometimes you are running into challenges that slow you down, because things are not working the way you expect them to. I’ll take those personal experiences to blog about, showing you what works and what does not work for me. Keep checking for new blog entries.
Category: Getting Started
With a lot of people talking about the Internet of Things, there is renewed interest in the .NET Micro Framework (NETMF). The current version, SDK v4.3 (QFE2- RTM), can amongst others be used in combination with Visual Studio 2013 to develop applications for very small target systems.
Last week I got a FEZ Spider Board with a lot of peripherals to create a number of (hopefully) cool demos. The first step is to install all necessary software on the development system and to make sure that a working USB connection is set up between the development machine and the target system. Installing software on the development system is easy and straight forward. The only thing to keep in mind is that you need to remove any previous NETMF installations before installing the latest version. This is also true for .NET Gadgeteer installations and optional GHI SDKs. The next step is installing the different NETMF packages that are necessary to develop NETMF applications with Visual Studio 2013.
The following software needs to be installed in this order:
- Net Micro Framework SDK v4.3 (QFE2-RTM) – SDK.MSI
- VS20xx Project System for the version of Visual Studio you have installed (in my case VS2013 Project System)
- Gadgeteer Core 2.43.1000
- Vendor SDK (from GHI Electronics, same product for all boards)
After installing all software, you can start developing your first project, which in my case is the Hello World for IoT: A blinking LED. When you develop a Gadgeteer project, you can make use of a designer to connect different hardware peripherals to the motherboard (and automatically create an object to be able to use the peripheral in your application). For the initial test, my hardware looks very simple, just the FEZ Spider Board and a USB module to power the motherboard and connect to the development machine.
Once all components are connected to the motherboard, it is time to connect the USB cable to the development machine. After installing necessary drivers on the development machine, it is now possible to select the FEZ Spider Board as target device inside Visual Studio. After doing that, your application will be deployed automatically to the target device when you start debugging. You will also have a full debugging experience when you deploy your application in this way to the target. However, this will only work if you have the right version of the boot loader and the TinyCLR present on the device. If you have an older version of the firmware on the device, Visual Studio cannot deploy your application and gives an error message instead. In my situation I had the right loader, but an older version of the TinyCLR. To update to the latest version of the TinyCLR, you can use the application FEZ Config, which is installed together with the Vendor SDK you installed previously. FEZ Config can be found under C:\Program Files (x86)\GHI Electronics\GHI FEZ Config for a default installation.
The application I developed is extremely simple, it just uses a timer to toggle the onboard LED for 10 times.
Using Visual Studio 2013, it is very easy to develop a simple NETMF application targeting the FEZ Spider board. Having said that, depending on the peripherals you are using and depending on the desired functionality, you can create complex projects that participate in an IoT type of solution. In the upcoming time I will post more articles about application development with the .NET Micro Framework.
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:
Deliberately I created all functionality in code to better compare this application to the Android application. A corresponding Android application looks like this:
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:
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:
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.
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
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.
If you start developing a new Windows Phone 7 application, you usually start by creating a new Visual Studio 2010 project. As part of the initial project, Visual Studio creates a default splash screen for you, consisting of a waiting clock.
A Windows Phone splash screen is simply a jpg file with a resolution of 800 * 480 pixels. This means that it is very simple to replace the default splash screen (which is conveniently stored in your Visual Studio project under the name SplashScreenImage.jpg). Just make sure you have a jpg file with the right resolution and also make sure that it is placed in the root of your Visual Studio project. The name must be SplashScreenImage.jpg and its Build Action must be set to Content in the Properties window. Leaving the original splash screen unchanged in your own application gives end users a somewhat boring experience. After all, a splash screen is used to give users the impression that your application starts fast, and it also occupies users while your application is loading. If all applications use the same default splash screen, it will not help giving users a fast starting impression about those applications. So it is important to provide your own splash screen. If an application does not spent much time initializing, the actual amount of time that a splash screen is displayed is very short. For one of my applications, I did create a reasonably nice splash screen, to find out that the splash screen often is displayed for less then a second. My initial thought was to delay application start to allow end users to admire my splash screen. Of course this is a very bad idea, something you should not even consider doing.
This splash screen is used in a little game that is available on Marketplace. Typically the game starts up in under a second, meaning the user hardly has time to see the splash screen. The good news is that it is at least not the default splash screen. I have to admit that I considered adding a delay in my application for users to see the splash screen. Of course, and end user might like it once to take a look at this splash screen, but after starting an application several times, the splash screen will become boring since it is just a static image.
On a side note, if you are curious about this game, you can find it here on the Windows Phone 7 Marketplace. Note: This link will work from a Windows Phone 7, or from a PC with Zune software installed.
Back to the story about splash screens though. If you are developing a Silverlight application for Windows Phone 7, take the following idea into consideration. By far the best experience you can give end users for fast starting applications, is to take a screen shot from your application’s main page. If your application starts with some animation, make sure to take the screen shot from the initial situation (before the animation starts running).
Also, leave the application title / page title out of the splash screen. What I did for my latest application was taking the following shot from the main screen. Once the application is initialized, the application and page title animate in from the top, nice and gently. This gives a very nice experience for end users, and you don’t have to worry that your splash screen is only visible for a very short time, after all, your splash screen partly is your main page.
To have some nice page transitions on your main page, you can make use of functionality that is available in the November release of the Silverlight for Windows Phone Toolkit. An in-depth explanation of how to use these page transitions can be found in this MSDN blog entry by Will Faught.
This is the code that I am using to bring in the application title and page title in an override version of the OnNavigatedTo method:
Only when my application is launching (a new instance of the application is started, or the application returns from being tombstoned), the animation will run. In all other situations ‘normal’ page transitions will be executed. I keep track of the application being launched in the app.xaml.cs source file like this:
As you can see, a little bit of code and an additional screen capture from of your application gives you a simple splash screen that is effective for fast loading applications, yet giving the end users a very nice starting experience of your application.
Windows Phone 7 applications can either be Silverlight based or XNA Framework based. Often, it is obvious which framework to use for a particular type of application. Typically, games will either use Silverlight or XNA, depending on the desired functionality they need. All other types of applications typically will be Silverlight based although from a technical point of view it is possible to create ‘non-game’ applications using XNA as well.
Silverlight uses an event driven model for your application. Events are raised by the operating system (often as a result of some user action) and an application can either react on the event or ignore the event. Inside an application you will ignore the majority of events that will be raised, but act on a number of specific events to achieve the desired functionality of the application. A Silverlight based application is often battery friendly, especially if it only reacts on user actions. In this type of scenario, the application will be idle for most of the time. However, if repetitive behavior is needed for an application (for instance, a clock application might want to update the time every second), a timer object can be used that periodically raises an event on which your application can react. In this scenario you have to keep in mind that you are draining the battery faster, because your application is repeatedly executing code. If your application wakes up to react on a raised event, it will execute code that is defined in an event handler for a particular event. The event handler will get information from the operating system about the source that raised the event. That source, for instance, can be a User Interface element, an expiring timer or a hardware interrupt. Because the event sender is known, the application can assure that it executes the code, belonging to a specific event.
The XNA Framework uses a loop driven model for your application. Periodically your application will wake up and it is up to the application to determine if something needs to be done. In order to achieve this, every XNA Framework application maintains a ‘game loop’ that executes 60 times per second (when using default values). It is the application’s responsibility to first Update the state of the application, for instance by getting user input, updating variables etc. Once a new application state is determined, the application is responsible to Draw to the Windows Phone 7 screen accordingly. Both Update and Draw will execute periodically, with Update taking priority over Draw. Note that these types of applications will drain the battery whenever the user is playing a game, because the application will wake up frequently, even if there is no work to do in either Update or Draw.
From a developer’s perspective, there are a number of reasons to either develop a Silverlight based Windows Phone 7 application or a XNA Framework based Windows Phone 7 application. Silverlight contains a nice collection of ready to use controls like buttons, text boxes etc. You can modify or extend these controls inside your own applications and you can create new controls. The XNA Framework contains functionality to make it relative easy for you to create 2D sprites that support rotation, scaling, stretching and filtering. There is also extensive support to create 3D graphics, including functionality for lighting and shading to create a great 3D experience. When making use of the XNA Framework however, you are responsible to create all of your artwork that is visible inside your application.
In certain situations, a distinct choice between Silverlight and XNA is not that easy to make. Also, in some scenario’s you might want to combine Silverlight with XNA Framework functionality. Using XNA Framework specific functionality inside a Silverlight application will be the topic of another blog entry. For now, if you want to know more about developing applications for Windows Phone 7 and if you want to read more about the initial choice between Silverlight and the XNA Framework, make sure to read this high level overview in the Windows Phone 7 documentation.