Jonas Follesø

Turning on the GoPro

Sat, 23 Apr 2016 16:49:58 +0200

The source code for the Arduino Sketch (firmware) for the SeeStar camera is available as part of the SeeStar repository. I struggled a bit to build an deploy the code to the Arduino Pro Mini. The SeeStar documentation says you should use the online IDE from Codebender. I had some issues getting it to work, so after filing a bug on the SeeStar repo software developer on the SeeStar team Thom Maughan uploaded the code and library to the repo.

The way you configure the SeeStar camera to set interval length is using the serial port. When you connect to the camera using serial, you get some version information etc. You can also issue commands to test different features, such as turning on and off the GoPro or LED light.

I had some challenges having the camera register my commands. The SeeStar firmware use a SerCmd library to handle commands entered sing the serial port. The library lets you assign commands to handler functions like this:

SCmd.addCommand("HELP", menu);
SCmd.addCommand("MENU", menu);
SCmd.addCommand("PARAM", get_param);
SCmd.addCommand("TIME", get_time);
SCmd.addCommand("SETTIME", set_time);

From the Arduino IDE you can connect to the board using the Serial Monitor tool:

The problem I ran into was that commands wouldn’t execute when I typed them in and hit enter. After doing some debugging, looking through the source code of SerCmd.cpp I realized that the command terminator character was set to \r, (Carriage return), while the Serial Monitor defaults to \n (New line). You can change the delimiter in Serial Command tool, and after doing that I was able to issue commands.

The SeeStar is connected to the GoPro camera using the Hero bus connector. The GoPro supports accessories such as external battery and LCD screen though backpacs. Using that port, and setting pin 12 to HIGH for 100ms will turn the camera on. I was able issue the test command to turn on the camera, and it was quite satisfying hearing the beep of the GoPro turning on!

A video posted by Jonas Follesø (@follesoe) on Apr 17, 2016 at 12:29pm PDT

Soldering and the Arduino Pro Mini

Sat, 26 Mar 2016 19:19:27 +0100

Today I’ve done the first bit of work on the actually SeeStar camera. I’ve soldered breakout pins onto the Arduino Pro Mini, so that I can program it and connect it to the SeeStar Arduino Shield. I’ve only done soldering a couple of times before, so to learn the basics I followed this How to solder - Through-hole Soldering tutorial from SparkFun.

I had a “learn to solder” kit I bought years ago laying in my box of electronics, so I used that for practice. SparkFun has a whole series of these kits that teach you soldering by building simple electronics and toys. The kit I built used a microphone to blink four LEDs when ever sound was detected. I was quite pleased when it worked when I connected the battery.

Complete sound-to-LED kit

After building some confidence on the sound to LED kit I soldered the breakout pins onto the Arduino Pro Mini. SparkFun has a tutorial on Using the Arduino Pro Mini 3.3V which provides some good information on the Arduino Pro Mini and how to program it. To power and program it I use the FTDI Cable from SparkFun.

Arduino Pro Mini running blinking LED example

Once I had verified the Arduino Pro Mini was working correctly I tried to hook it up to the SeeStar Arduino Shield. The SeeStar documentation describes the procedures to power and test the shield. I used an old 12 Vdc adaptor I had laying around for power. Once the Arduino Pro Mini was connected to the shield it powered up and the blinking LED sketch was running.

Arduino Pro Mini connected to SeeStar Arduino Shield

That concludes a productive day, both in terms of learning new skills and making actuall progress on the SeeStar camera. Next task is to program the Arduino Pro Mini with the actual SeeStar code and have the Arduino Shield connect to the GoPro Hero 3 to turn it on/off at set intervals.

Learning the basics

Sun, 06 Mar 2016 14:45:32 +0100

Part of the reason I wanted to take on the SeeStar project was to learn more about electronics. I write software and program computers every day, but building custom hardware and electronics is something I do not have much experience with.

This weekend I’ve spent some time learning more about the basics of electronics. The SparkFun web site has a wealth of fantastic learning reasones. Some of the articles and tutorials I’ve work through over the weekend are:

I also spent some time installing the Arduino software and getting it connected to old Arduino Duemilanove. I bought the Arduino and some components back in 2009, but haven’t really done much with them, so it was fun to try out some of the concepts from the SparkFun tutorials.

The SeeStar uses an Arduino Pro Mini, a much smaller version than the Duemilanove, but the same principles apply. The SeeStar software is already written, but understanding how the different parts work will make it easier to test each component in isolation when I start putting together the camera.

The little circuit on the picture is turning the LED connected to the Arduino on or off. The source code is included below.

Right now I’m waiting for break away headers for the Arduino Mini Pro. Once I get them I need to do some soldering, so the next SparkFun tutorial I plan to go through is on how to do through-hole soldering.

#define LED 13    // LED connected to digitial pin 13
#define BUTTON 7  // input pin for push button

int val = 0;
int old_val = 0;
int state = 0;

void setup() {
  pinMode(LED, OUTPUT);   // LED is output
  pinMode(BUTTON, INPUT); // button is input
}

void loop() {
  val = digitalRead(BUTTON);

  if (val == HIGH && old_val == LOW) {
    state = 1 - state;
    delay(10);
  }

  old_val = val;

  if (state == 1) {
    digitalWrite(LED, HIGH);  // turns on LED
  } else {
    digitalWrite(LED, LOW);   // turns off LED  
  }
}

Bringing this blog back to life!

Wed, 17 Feb 2016 21:00:00 +0100

My previous blog post was published on the 28th of April 2012, almost four years ago! I’ve kept the blog online for reference purposes, as I still get a bit of traffic from people Gooling for various .NET-related topics.

As most programmers, I return from a period of absence from writing not by writing something new, but by upgrading my blog platform. I’ve migrated all my old content over from Toto, the 10 second blog-engine for hackers to Hugo, A Fast & Modern Static Website Engine. The reason for the move was the fact that I wanted a static, fully customizable platform. Toto runs on Ruby, and hasn’t received any commits since 2013.

All the old content is available in a separate section called Blog Archive. I’ve kept the old URLs working so that I don’t loose any Google-mojo this blog might have left. I wanted to keep these posts separate, as they span the years 2005 to 2012, and allot of the content is outdated. Going forward the content on my page will probably be more diverse and cover other topics that interest me; such as traveling, triathlon training, GoPro videography and the under water world. Hugo has great support for organizing your content, so I might set up different sections for specific projects or types of content.

The first major project I will cover on this blog is my build of the SeeStar II open-source underwater time-lapse imaging system. I will introduce this project in a separate post.

First components have arrived!

Wed, 17 Feb 2016 21:00:00 +0100

The first set of components have arrived. This week I received the Arduino shield, the GoPro 3 Battery Eliminator, and the DC-DC converter.

The Arduino shield is one of the key components in the SeeStar. The Arduino Pro Mini attaches to the shield, and through the shield it will provide power and control the GoPro Camera and the LED light.

The GoPro Battery Eliminator will be used to power the GoPro through the SeeStar battery module, instead of using the normal GoPro battery.

If you are using the GoPro camera for extended periods, it is better to power the camera with a Battery Eliminator instead of connecting it to the camera’s mini-USB charger.

The coupler style Battery Eliminator snaps into the battery slot of all GoPro HERO3 and HERO3+ models and latches like the GoPro lid for a secure fit. Using a Battery Eliminator eliminates two sources of heat. The charging circuit in the camera and the battery itself, which gets warm while charging. Less heat makes the camera more reliable. Overheating can cause unexpected shutdown of the camera. A Battery Eliminator also bypasses the problems that some users have had with the GoPro charging logic causing the camera to freeze and require a reset.

CamDo Battery Eliminator Product Description

I don’t have enough components yet to start the build, but once I get the Arduino Pro Mini and the 30-Pin Ridax Connector I should be able to automatically turn the GoPro on and off at given intervals.

Looking for battery alternatives

Thu, 11 Feb 2016 21:00:00 +0100

I’ve been in contact with Battery Specialities to order the battery. They do not list the item on their website, nor do they ship it internationally. So currently I’m looking for alternatives. I have filed a bug on the Bitbucket repository, and have gotten the following reply from Chad:

Our battery is a custom part number for them so I wouldn’t expect it to be on their website. Their sales team should be able to reference it, though. I will check with my contact there and make sure it is available. However, the battery is the easiest module to modify. It just needs to be in the 12-16Vdc range.

I have decided to build the SeeStar II

Mon, 08 Feb 2016 21:00:00 +0100

I have decided to build the SeeStar II Project, and today I ordered the first set of parts.

Two Arduino Pro Mini (3.3v/8MHz) and a FTDI Cable 5V from SparkFun: $43.47.
DC-DC Converter OKX-T/10-D12P-C from Mouser Electronics: $28.80.
GoPro Battery Eliminator from CamDo: $69.79.

I have also contacted Chad Kecky, Electrical Engineer at Monterery Bay Aquarium Research Institute, who have offered to send me an Arduino shield (the only custom hardware part in this project) for beta-testing. The Arduino shield was the part I was most uncertain about, and which would be outside my skill level to build my self.

Building testable WP7 apps using Microsoft.Practices.Phone.Adapters

Sat, 28 Apr 2012 00:00:00 +0000

I’m a big believer in Test Driven Development as an effective practice that helps me write high quality, maintainable code. TDD is a practice I not only apply on larger enterprise applications, but something I try to do even on smaller mobile apps. In the day of the Apple App Store or Microsoft Marketplace you are relying on Apple or Microsoft to approve your application before it’s made available to your users. The process typically takes around a week – meaning it can potentially take a week before you fix a bug and the update is made available to the users. Introducing a bug in your mobile app can greatly hurt your rating in the Marketplace/App Store. Given the fact that you cannot simply upload a quick fix to the app stores, like you can on a web application, having solid testing for mobile applications is even more important than for other types of applications.

With this in mind I was thrilled to see that Microsoft Pattern & Practices had taken this to hearth in their latest guidance for building Windows Phone 7 applications. The latest guide includes three major topics:

I have previously written several blog posts and given presentations on how the MVVM Pattern can help you separate the state and behavior of a piece of UI from the actual View-code. By moving state and behavior into a View Model-class with no UI dependencies, you can easily unit test the View Model in separation. If you would like to learn more about the MVVM-pattern I would strongly recommend my presentation from NDC 2009, or the MVVM-chapter from the P&P WP7 Guidelines. To ensure that the View Model classes can be tested independently it is important that they do not have any external dependencies that are hard to test. Whenever a View Model depends on some external resource, such as a web service, we introduce an interface for that dependency, and enable some form of Dependency Injection on the View Model so that we can replace the dependency with a stub or a mock during test.

When working against the Windows Phone 7 APIs you will quickly realize that they are not very test-friendly. The API consists of several static or sealed classes that provide access to core phone-functionality such as Location Services, Compass, Camera, Gyroscope or other sensors. Since the classes are sealed, and do not implement an interface, there is no simple way to test code accessing these classes directly. The solution in such cases is typically to define your own interface mimicking the underlying API, and then implement an Adapter class delegating through to the underlying API.

To demonstrate this principle I have created a simple application that displays your current location and compass heading. Such an application would need to use two classes that are hard to test; the GeoCoordinateWatcher-class and the Compass-class. A simple design, using the View Model pattern, would look something like this:

The problem with this design is how the TrackingViewModel-class is using the Compass-class and GeoCoordinateWatcher-class directly. It would be impossible to unit test the View Model, both because the Compass-sensor is not available in the simulator, but also just because of the fact that getting a location/compass reading takes time, and would make the tests slow and unreliable. Instead we are going to modify the design, and use the abstractions introduced by the Patterns & Practices team. We change our TrackingViewModel-class to depend on ICompass and IGeoCoordinateWatcher. At test-time we pass in mock-implementations of these two classes to enable testability, while at run-time we use the adapter classes GeoCordinateWatcherAdapter and CompassAdapter.

With this small change we can now write unit tests for the TrackingViewModel-class. Here is an example of some of the tests I have written for the View Model.

Many people assume that you have to use an IoC-container to use Dependency Injection. That is not the case. My personal preference is to not introduce an IoC-container until it is necessary, and instead use overloaded constructors. The TrackingViewModel-class has two constructors, one that accepts the ICompass and IGeoCoordinateWatcher interfaces as parameters, and one default constructor that calls the parameterized constructor passing in the adapter classes as default. This enables testability, yet at the same time keeps the architecture of the application simple.

In this example I only use two of the wrapped classes provided by the Microsoft.Practices.Phone.Adapters project. In addition the project contains adapters for the following classes in the Windows Phone 7.1 SDK:

Wrapper	Implements	Abstracted Class
AccelerometerAdapter	IAccelerometer	Accelerometer
ApplicationFrameNavigationService	INavigationService	PhoneApplicationFrame
CameraCaptureTaskAdapter	ICameraCaptureTask	CameraCaptureTask
CompassAdapter	ICompass	Compass
GeoCordinateWatcherAdapter	GeoCoordinateWatcher, IGeoCoordinateWatcher	GeoCoordinateWatcher
GyroscopeAdapter	IGyroscope	Gyroscope
IsolatedStorageFacade	IIsolatedStorageFacade	IsolatedStorageFileAdapter, IsolatedStorageFileStreamAdapter
IsolatedStorageFileAdapter	IIsolatedStorageFile	IsolatedStorageFile
IsolatedStorageFileStreamAdapter	IsolatedStorageFileStream, IIsolatedStorageFileStream	IsolatedStorageFileStream
MessageBoxAdapter	IMessageBox	MessageBox
MotionAdapter	IMotion	Motion
AccelerometerSensorReading	ISensorReading	AccelerometerReading
CompassSensorReading	ISensorReading	CompassReading
GyroscopeSensorReading	ISensorReading	GyroscopeReading
MotionSensorReading	ISensorReading	MotionReading
PhotoResultTaskEventArgs	TaskEventArgs	PhotoResult

The Microsoft.Practices.Phone.Adapters project can be added as a NuGet-package. The package adds the interfaces/adapter files to your project, and you can choose to delete the once you don’t need (it is not a pre-compiled package). If you download the example project from the MSDN site you also get a set of pre-written mock-classes you can use in your Unit Test project to mock the different interfaces.

If you want to learn more about making your WP7 applications testable I would strongly encourage you to read the full guide on this on MSDN. As I mentioned in the introduction, testability is just one aspect of the Patterns & Practices Guide for WP7, and I will be covering other areas in a later blog post.

The example application for this blog post is available at https://github.com/follesoe/TestableGeoTrackerDemo.

Cross platform .NET mobile apps talk at NDC 2011

Fri, 22 Jul 2011 00:00:00 +0000

Earlier this summer I gave a presentation at NDC 2011 about writing cross platform mobile applications using C# and .NET. At the time of the presentation the future of MonoTouch and Mono for Android was uncertain, but with the recent news of Xamarin gaining ownership of the products, the future of C# on iOS and Android looks brighter than ever.

The presentation covers 8 concrete strategies for designing applications for maximum code re-use across all three platforms, as well as techniques to make development more productive and hassle-free. The strategies/techniques covered in the presentation are:

Portable Class Libraries
Linked Files
The "Project Linker" tool
VSMonoTouch to open MonoTouch projects in Visual Studio
Pre-processor directives
Abstract common functionality
Leverage MVVM on all platforms
Use pre-built abstractions such as MonoMobile.Extensions

All the presentations from NDC 2011 are available in a torrent file, but to make the presentation more discoverable and accessible I have uploaded it to my Vimeo account. The slides are available on SlideShare.

Cross platform .NET mobile apps in practice from Jonas Follesø on Vimeo.

Cross platform mobile apps using .NET

View more presentations from Jonas Follesø.

QR code scanning on Windows Phone 7.5 using ZXlib

Fri, 22 Jul 2011 00:00:00 +0000

One of the big new features of Windows Phone 7.5 (code named Mango) is direct camera access. Having access to the camera stream enables several new scenarios, such as in-app QR and barcode scanning, augmented reality applications or custom looking photo camera UI. There are some good resources on how to use the new APIs to access the camera in Mango, but I haven’t found any complete examples of how to implement a QR code scanner, which is what I am going to do in this blog post.

Mango adds two API to access the camera. You can either use the webcam APIs introduced in Silverlight 4, or you can use the new PhotoCamera class introduced in Mango. I’m not going to cover all the details of the two APIs; instead I will focus on how to solve the scenario of implementing a QR scanner. If you want to learn more about the Silverlight 4 APIs for accessing the camera I would highly recommend Rene Schulte’s detailed blog post. For information on the PhotoCamera API I would recommend this MSDN article showing how to build a camera application for Windows Phone.

When starting on the task of building a QR scanner one of the first things I did was to research different open source libraries to do the image recognition. Thankfully there are multiple libraries available, but the ZXing library from Google seems to be one of the most popular. The ZXing library is ported to multiple programming libraries, and supports a wide variety of 1D/2D codes (QR, Code128, Code39, EAN and many more). There is a C# port of the library, which has later been ported to Silverlight and Windows Phone 7. So the actual task of writing the QR scanner is to integrate the ZXing library with the Mango camera API.

The XAML code for the scanner consists of 4 main components. A Rectangle is used as to display the viewfinder video stream. The way you hook the camera up to the rectangle is through a VideoBrush. A VidoBrush let you paint any XAML element using a video source of some kind. To control orientation (depending on landscape or portrait) a CompositeTransform is added to the VideoBrush. This transform lets us programmatically set the rotation of the video brush to match the rotation of the camera. The final component is a ListBox used to display the text decoded from the QR codes.

In the code behind file we need to add some initialization code. In the constructor we instantiate an ObservableCollection which will be the ItemsSource of the ListBox. Whenever a QR code is successfully scanned the result is added the collection, which in turn will update items in the ListBox. We also create a DispatcherTimer that will execute every 250 millisecond. On each tick we will try to decode the image for any QR codes. In the OnNavgiatedTo method we instantiate the PhotoCamera class and hook the Initialized event for the camera. We also set the source of the VideoBruch created in XAML to the photo camera. This will start drawing whatever the camera sees on the Rectangle. We also hook the ShutterKeyHalfPressed event to focus.

When the photo camera is initialized we run some more setup code. The code needs to access the width and height of the preview resolution, so it cannot run before the camera is initialized. Next we create an instance of PhotoCameraLumianceSource. This is a custom class extending the LumianceSource class from the ZXing library. This class is responsible for extracting luminance data from any image. Since you could have different image formats, ZXing has mad the framework extensible by providing a base class you can extend with the code needed to get luminance data from the specific image format you are working with. Next we create an instance of the QRCodeReader. This is the class responsible for decoding the image to scan for a QR code. The ZXing library comes with multiple readers, so if you want to read Code128 bar codes you simply create a Code128Reader instead. Finally we set the rotation of the preview VideoBrush and start the timer.

Every time the timer ticks the ScanPreviewBuffer is executed. This method is responsible for getting the image data from the photo camera and tries to decode it. The photo camera offers multiple methods to get images. You can either capture a full resolution image, or you can get the preview buffer. Capturing a full resolution image would be too slow for a computer vision application, but thankfully we got methods to access the preview buffer. You can get the preview buffer as either ARGB format or YCbCr format. The camera sensor is internally using YCbCr, so getting it as Argb format would require conversion. If you only care about luminance (the Y in YCbCr) there is a convenient method giving you the Y component of the YCbCr format. This is perfect as this is exactly what we need to pass to the ZXing library. Rene Schutle got a good blog post going into the details of Argb vs YCbCr.

The GetPreviewBufferY method takes a byte array as its parameter and will populate this byte array with the luminance data from the preview buffer. We pass in the PreviewBufferY property from our luminance source class (which will be explained later). Once we have captured the luminance data we create a HybridBinarizer and a BinaryBitmap. They are part of the ZXing library. I haven’t worked enough with ZXing yet to fully understand the architecture, but these classes are steps the luminance data pass through before being passed to the decode method of the QRCodeReader. If the decode is successful the decoded text is added to the ObservableCollection, which in turn will update the ListBox. The QRCodeReader decode method will throw an exception if it is not able to decode the image, so we need to wrap the code in a try-catch block.

The PhotoCameraLumianceSoure implements the LumianceSource base class used by the ZXing library. The class is responsible for exposing the luminance data for the image format you are working with. Conveniently the PhotoCamera class gives us the luminance data directly, so implementing the class does not take much code. There are basically one property and one method you need to implement. The Matrix property simply returns the luminance data for the complete image. The getRow method returns the luminance data for a given row. Both the property and the method simply read the PreviewBufferY byte array which is filled every time the timer calls the GetPreviewBufferY method.

So how does this work in practice? Below is a YouTube video demonstrating the QR scanner. As you can see it’s fairly quick and accurate (well, at least on bright images of my computer screen). I have not yet tested it in the wild, and the ZXing library offers many customizations to fine tune how you want the scanner to behave, but at least this demonstrates how you can combine ZXing and the Mango PhotoCamera API to implement a QR scanner in less than 150 lines of user code!

The complete QR code scanner example code is available on github.

WP7, iOS & Android: Is .NET the platform to rule them all?

Sun, 20 Mar 2011 00:00:00 +0000

The following blog post is an article originally published in the most current issue of "The Developer", a magazine distributed to Norwegian developers. The article discusses the exciting possibility to use C# and .NET across the three major smart phone platforms WP7, iOS and Android. Since the magazine is only distributed in Norway I decided to post it on my blog as well. You can either read it here, or download a PDF version of the article as presented in the magazine.

If you ask me 2010 was the year of the mobile app. Everyone was talking about them, from consumers around the lunch table, to CEOs in the boardrooms. It was like 1999 all over again; only this time it was not about building websites, but to have some kind of offering in one of the major mobile app stores. According to the analysts at IDG the huge interest in mobile apps is not just a fad. They expect download numbers to grow from 10.9 billion in 2010 to 76.9 billion in 2014. As a result app revenue will surpass $35 billion the same year. In short, mobile is going to play an important role for software developers over the next few years.

As a .NET developer you are faced with some tough decisions. Which platform do you bet on? How do you get your skills up-to-date quickly enough? Do you suck it up and learn CocoaTouch and Objective-C to target the popular Apple iOS devices? Should you learn Java and go for the Android? Or should you skip two of the most popular mobile platforms and stick to C# and develop for the newly released Windows Phone 7?

Businesses face some of the same decisions, as they need to decide where to focus their resources and efforts. Should they target all the major platforms, or focus only on iOS devices? What will be the cost of maintaining these applications over time? A quick search for “DnB NOR” (Norway’s largest financial services group) in the iTunes App Store reveals that they already have five apps available. This is for iOS devices alone. In addition, two of the applications are also available in Android Market. With seven apps published already one can start to imagine what the cost and technical challenges of maintaining them over time will be.

When choosing which technology to use for implementing mobile apps, the popular choices have traditionally been either web-based apps written in HTML, CSS & JavaScript, or alternatively fully native apps tailored to a specific platform. Both alternatives have their pros and cons. Web-based applications might be quicker to build and easier to make cross-platform, but the drawback is that you do not have full access to the phone specific APIs. And it is harder to provide the same high fidelity user experience as a native app offers. With native apps, the challenge might be a steep learning curve and having to re-implement the same app across different platforms.

With the release of MonoTouch at the end of 2009 Novell introduced a new way to build apps for iOS devices. Against all odds the programmers at Novell had found a way to bring Mono, the open source implementation of .NET, to the iPhone without requiring unlocking or jail-breaking the device. The MonoTouch framework enables developers to build native iOS apps using the C# programming language using many of the core .NET libraries. MonoTouch is designed to conform to the strict requirements set by Apple for App Store eligibility. MonoTouch allows .NET developers to take advantage of their existing skills, reuse existing code and libraries, making the transition to the iOS platform easier.

Instead of porting Windows Forms or WPF to the iPhone, MonoTouch provides a thin .NET layer on top of the native CocoaTouch APIs giving your applications a fully native look and feel, making them indistinguishable from the traditional iPhone applications. And where it makes sense, MonoTouch will provide standard .NET APIs instead of the CocoaTouch counterparts. For example, you use standard ADO.NET to talk to SQLite databases on the device, and XML can be processed using the familiar System.Xml.Linq API. MonoTouch apps are developed using the MonoDevelop IDE, an experience very similar to that of Visual Studio.

Managed runtimes like the CLR (Common Language Runtime) and JVM (Java Virtual Machine) typically use just-in-time (JIT) compilation, where byte code is translated to machine code at runtime. Apple forbids the inclusion of mechanisms that enable execution of arbitrary third party code, effectively blocking the use of non-standard runtimes, interpreters and virtual machines. The developers at Novell were able to overcome this obstacle by using an alternative ahead-of-time (AOT) compilation model where .NET Common Intermediate Language (CIL) is compiled directly to native code. AOT compiles the MonoTouch applications to native executables that do not rely on a virtual machine to run.

With the success of MonoTouch, Novell decided to take a similar approach to bring .NET to the Android platform. MonoDroid provides .NET bindings against the Android API, as well as a .NET-to-Java interop mechanism. Android is a more open platform than iOS and allows for JIT compilation of code. The Mono runtime will run side-by-side with the Dalvik runtime, providing direct access to many of the core Linux OS APIs through the standard .NET libraries like System, System.IO and System.Net. Just as with MonoTouch, a MonoDroid app will use the native UI toolkit, giving the user the same great user experience as with any other native app. MonoDroid integrates with Visual Studio making the experience of writing apps for Android even more familiar.

Both MonoTouch and MonoDroid expose the same subset of the .NET core API, which is a subset based on the Silverlight API. This is the same subset Microsoft chose to use for their newly released Windows Phone 7. This means that there now exists a core set of APIs that are the same across the three major smartphone platforms. By carefully crafting an application in such a way as to separate business logic from user interface code, it is possible to reuse code and libraries across all platforms. I expect patterns to emerge over time that describe how to best structure your code for maximum reuse across the different mobile platforms.

For many developers mobile apps have made it fun to program again. Within weeks you can go from an idea to an app that can be downloaded by millions of users through one of these app stores. Who knows, something that starts of as a hobby project might turn out to be the next Angry Birds. No matter if you do app development as a hobby or professionally there is nothing more gratifying as seeing your first app being available in one of the app stores. Happy app-ing everybody!

I’m joining BEKK

Sun, 01 Aug 2010 00:00:00 +0000

Tomorrow will be my first day as a BEKK employee. I will be joining the BEKK Trondheim office as a senior consultant. After three good years in Capgemini I decided it was time for a change. I will continue to work on different projects as a consultant, but my role in BEKK also gives me some dedicated time for other activities like exploring new technologies, preparing presentations, writing articles etc. I will continue to be just as involved in the developer community as I am today, and I already got some cool speaking gigs lined up for the fall. More on that later.

BEKK have some really talented people working for them, and over the years I’ve noticed how they’ve been one of the early adopters of agile processes and techniques (XP, Scrum, Kanban, TDD/BDD etc), as well as new technologies (Ruby on Rails, Cucumber) here in Norway. I hope that by working for BEKK I’ll get a chance to broaden my technical experience, and perhaps do some projects on alternative platforms (I’m sure .NET will continue to be my main platform so don’t worry about me leaving the .NET community).

NDC2010 - Patterns and techniques for building Windows Phone 7 applications

Wed, 07 Jul 2010 00:00:00 +0000

Last month I was lucky enough to both attend and speak at the Norwegian Developer Conference. It was a fantastic conference, and the conversations following the conference are still buzzing on twitter and in the blogosphere. For me NDC must have been one of the best conferences I’ve ever attended, offering a diverse range of topics from some of the best speakers in the industry. I’m humbled to be invited to speak at such a great event.

My session was on building Silverlight applications for the Windows Phone 7 platform. Instead of doing a feature tour of all the new APIs I decided to focus on some of the patterns and principles I find important when doing Silverlight development, and showing how to apply these in a Windows Phone 7 context. Some of the topics I covered in my talk included:

How to do TDD in Silverlight on WP7
The MVVM design pattern and MVVM Light Framework.
How to use dependency injection in a WP7 context and how it can help you inject stub implementations of APIs that isn’t available in the emulator.
Asynchronous web services using Rx (Reactive Extensions).
How to use the location APIs and how to make stub implementations for the emulator.
How to use the push notification API.
Making your views Blend-friendly by supplying design time data.
The Metro design language (look and feel of WP7 applications)

To best illustrate these concepts I’ve built a full Windows Phone 7 application that lets you monitor arrivals and departures from any Norwegian airport. The application consumes a set of REST services exposed by Avinor that lets you look up arrivals and departures for a given airport. I’ve made the entire application available on GitHub as open source, and I do plan to polish it enough to actually publish it on the app marked place as soon as the WP7 is released.

Most sessions from NDC2010 where recorded, and can be downloaded from the Tandberg streaming server or as a complete torrent with all the sessions. I’ve also uploaded my session to Vimeo (for my personal video archive), and to make it easier to embed it on my blog.

Silverlight Applications for Windows Phone 7 from Jonas Follesø on Vimeo.

The slides are available on Slide Share, and the source code is up on GitHub. I do plan to update the code as new versions of the WP7 platform is released, and hope the application can serve as a good example of how to architect a WP7 application.

Get a flying start with Windows Phone 7 - NDC2010

View more presentations from follesoe.

Thanks to everyone who showed up for my session, and for the great feedback on Twitter, in person and through the conference evaluation system. Thanks to everyone I meet during the conference that I got a chance to talk to – it’s amazing how many talented people you meet at a conference like NDC. Also big thanks to the people behind NDC – they did an amazing job and I’m truly looking forward to next year’s conference!

XP2010 and BlackBoxRecorder

Fri, 04 Jun 2010 00:00:00 +0000

This week I have been attending the 11^th international conference on Agile Software Development, XP2010, in Trondheim. It has been an amazing week, filled with learning, excellent food and awesome social events, making new friends and catching up with old. I gave two lightning talks during the conference, one on UI prototyping in agile projects (the same I gave at Smidig 2009), and one on Generating Characterization Tests for Legacy Code. The talk on characterization tests was based on some work I did back in October – December 2009. I was involved in a partial rewrite of some pretty bad legacy code. One of the techniques we discovered was that we could use the slow running integration tests to code generate fast and more targeted characterization tests for the code we were rewriting.

For the last three-four months I’ve been working on an open source testing tool that streamlines the technique of generating characterization tests for your legacy code. The project is called BlackBoxRecorder and is available on Github.

BlackBoxRecorder is a tool that uses AOP-techniques to automatically record and generate characterization tests for legacy .NET code (code without tests). You apply a [Recording]-attribute on the method you want to generate tests for, and a [Dependency]-attribute on any class accessing external resources such as the file system, web services or databases.

Each method invocation of a method marked with the recording-attribute will be stored in an XML file. The XML file contains information about the method, copies of input parameters, output parameters and return values. If the method being recorded invokes any methods on a class marked with the Dependency-attribute, the return values of the dependency will also be recorded in the same XML file. This enables automatic mocking of external dependencies when playing back the characterization test.

For each method recording BlackBoxRecorder will generate a unit test that will play back the recorded XML file against the method. The return values from the method will be compared against the recorded return values using reflection. If any change is detected the test will fail. The test will serve as a change detector (which in essence is what characterization test is), notifying you of any changed behavior in the method being tested. If the change was intentional you can configure the generated test to ignore that property on next run.

The generated tests supports automatic stubbing/mocking of the types marked with the Dependency-attribute. When the test is played back, the dependency will load return values from the XML recording and return these instead of actually calling the external resource. You do not have to change your code for this to work and even static methods are supported.

I got some really good feedback on the session, and it was pretty cool that Michael Feathers attended the session. I referenced his book and quoted him a few times in the presentation, so I was really glad he enjoyed the talk.

I also got questions from several people who where interested in what it would take to port BlackBoxRecorder to Java. So on Thursday evening I organized an open space session where we walked through the code and discussed how to implement a Java version. We continued the talk over lunch Friday, and soon enough Ole Christian Rynning, Johannes Brodwall, Geir Amdal, Marius Kotsbak and myself where hacking away on a spike implementing BalackBox for Java.

We called the implementation JackBox, and the code is up on Github if you want to jump in and contribute.

I will definitely blog more about BlackBoxRecorder as soon as I’m done with my NDC2010 presentations. Thanks to organizers, speakers and attendees for making XP2010 a memorable experience!

Simulating multitouch on the Windows Phone 7 Emulator

Sun, 21 Mar 2010 00:00:00 +0000

Over the weekend I have had tons of fun playing around with the Windows Phone 7 Developers Tools. The platform looks awesome, both from an end user perspective as well as a developer perspective.

One of the scenarios I’ve been exploring involves some simple multitouch pinch and zoom gestures. It’s fairly simple to add custom touch functionality by subscribing to the Manipulation Events hanging off all UIElements. If you got a touch enabled Windows 7 computer you can even test multitouch directly in the emulator. However, I was a little bummed when I read that, unlike the Surface SDK, simulating multitouch input using multiple mice was not supported:

“The Windows Phone Emulator does not support multitouch input through the mouse, so you must test scale transforms on a development computer that supports touch input, or test on an actual device.”

This is not entirely true. When I read this I remembered this cool blog post from Szymon Kobalczyk on emulating a multitouch device in Windows 7. In his post Szymon talks about the MultiTouchVista project. It’s an open source piece of software that lets you install a Windows 7 touch driver. The driver talks to a multitouch service that can read input from multiple sources and turn them into standard Windows 7 multitouch events. Sources for input include things like multiple mice, web cameras and Wii remotes. Since the MultiTouchVista application appears as a standard Windows 7 touch driver it will work in any Windows 7 touch-enabled application, like the Windows Phone 7 emulator.

For detailed installation instructions, check out the projects official CodePlex site. I have recorded a quick demo showing multitouch in Silverlight 3, MS Paint and the Windows Phone 7 emulator using two mice connected to my iMac.

Emulating Multitouch on the Windows Phone 7 Emulator using multiple mice from Jonas Follesø on Vimeo.