Category Archives: C#

Xamarin acquired by Microsoft

Hi, it’s me again – Rufus. It is that time of the year again where I write a technical blog!

You may have read my previous post about the Apple technologies that were announced a few months ago. With the recent announcement that Xamarin has been acquired by Microsoft, I thought it was an appropriate time to share some of my thoughts with the world! This blog post will share a little bit our history with Xamarin technologies – and some of our thoughts on the recent news.

How we got into Xamarin

When Linknode first dipped into the world of mobile applications, it was only natural for us to begin investigating the Windows Phone platform, due to our developers having a rich history with Windows desktop and server based technologies. After creating a number of Windows Phone applications – to gain some experience with intricacies of mobile development we looked into expanding to the other platforms. Driven by our development history, our desire to build Augmented Reality applications and the small size of our development team the following requirements were important to us:

  • Share as much code as much as possible
  • Provide the user with a “Native” experience – Each application should follow the idioms of the device it is running on
  • The ability to write high performance – real time applications
  • Ideally we should be able to reuse our .net/C# skills and code.

The above list of requirements is quite steep – but the first three are easily possible using available tools. However back then, most people thought C# was a Microsoft technology and was not supported by other platforms… or was it? This is where Xamarin comes in!

xamagonXamarin

We started building some simple test applications to try out the Xamarin technologies and were highly impressed with the quality of the output, and also the lack of a steep learning curve.

Xamarin is based on the “Mono” runtime and allows you to write applications in C# for Android, iOS, Windows and Mac. Xamarin allowed us to share a large amount of code and make use of our experience with C# and the general richness of the large “.net” based API’s.

Some other options at the time were not sounding so promising. This is not to say switching to Xamarin was without issues. As an “early bird” user of Xamarin we had some issues such as the primitive nature and stability of the development tools. However we have seen the Xamarin toolchain go through various phrases of re-branding and improvements and it has now emerged as a stable and somewhat mature development platform. The Xamarin developer Ecosystem is full of libraries/components developers can make use of to accelerate development without sacrificing the experience for the end user. Another point of note is that if you are a native iOS/Android developer with a lack of sharp experience as I was – switching to Xamarin is extremely easy. All the API’s and built-in Frameworks you are familiar with are still there and easily accessed from C#.

code-sharing1

 

Acquisition + conclusion

We are happy with the decision to go down the route of building cross platform applications using Xamarin and are pleased with the somewhat expected acquisition. We hope the recent news will enrich the Xamarin development community further, not only by generating more interest for the Xamarin toolchain and growing the size of the community – but also to aid in breathing some new life into the windows mobile space.

Either way I am sure having the great experience of a company such as Microsoft cannot be a bad thing. If any of you are deliberating whether to investigate Xamarin for your own projects I strongly recommend you try it out!

xamarin-joins-microsoft

 

 

Sensor Fusion: Rolling your own

Last time, I wrote about sensors and sensor fusion. Over the last couple of years at Linknode, we’ve gained considerable practical experience with the sensors that are built into modern tablets. This blog post is a fairly technical explanation of some of that knowledge and understanding, and why we ended up doing what we did – if you don’t like maths, I suggest you skip this blog post.

I mentioned last time that most sensor fusion algorithms have been written with gaming in mind. Whatever anyone says, games are the things that push the boundaries of the hardware on mobile devices. There are two needs for speed on mobile devices these days – animating the transitions within app and providing detailed 3D experiences within games. Mobile devices are not (yet) used for number crunching or other processor intensive operations.

Problems

We have seen some specific problems with manufactures implementation of sensor fusion. A lot of the algorithms are about rate of change and responsiveness over absolute accuracy. With VentusAR, we require accuracy foremost as the visualisations we produce could end up under expert scrutiny. One of our early clients said that they would accept a tolerance of +/- 2° from the compass (and much less in the other sensors). We provide calibration tools to allow sensors to get within a tolerance of 0.1°. We found two main problems with default sensor fusion algorithms:

  • Jitter – the compass / fusion on some android tablets would jitter unacceptably. The terrain model would jump by +/- 10° while the device was sitting on the table.
  • Inaccuracy – the wireline could be a few degrees out when trying to align it to real world terrain. This could sometimes be corrected by rotating the device in 3D then pointing at the view again

Rolling your own

Rolling your own sensor fusion isn’t too hard, we started with some basic requirements:

  • Smoothing – the sensor fusion algorithm should produce a smooth output. If the device is setting stationary on a table, the inputs should not “jitter”. For example, using My View, the terrain should be accurate and not jitter
  • Accurate – prioritise the input from the compass over all over input – we should be using the other sensors to smooth and enhance the compass, not using the compass to provide stability to the gyroscope
  • Fast – The sensor data is read from the device at either 50 times or 60 times a second (50 on android, 60 on iOS). This means the CPU has 20 to 25ms to process each package of sensor data to ensure that we are keeping up.

With these requirements in mind we set about writing our own sensor fusion algorithm. The pseudo code for the algorithm we ended up with looks little like:

  • Calculate a ‘smoothed heading’
    • Calculate change between current heading value and last heading value
    • If change > THRESHOLD
      • smoothedHeading = lastHeading +LARGE_OFFSET
    • Else
      • smoothedHeading = lastHeading + SMALL_OFFSET
  • Maximise accuracy of the compass component
    • Remove current heading component from the output of the manufactures sensor fusion
    • Multiply by smoothed heading from above
  • Normalize

When smoothing, if we have a big change in magnetic heading (ie if change is > THRESHOLD) the ‘Smoothed Heading’ will respond to that quickly, however small changes will be smoothed over by the small offset. The values for THRESHOLD, LARGE_OFFSET and SMALL_OFFSET are device specific and have been found by running appropriate testing on each device.

Results

To give an example of how the smoothing function of our sensor fusion works, I did some work to export the raw data to excel and do some analysis on it. The graph below shows the input (raw heading) plotted next two the output of the sensor fusion. This graph shows the input to the sensor fusion classes in blue and the output in orange. The x axis shows the number of data points (were receiving approximately 50 per second so this shows 2000 data points over about 40 seconds). The y axis shows the heading of the device is shown on the left (values between 0° and 360°).

40 of smoothing data from Linknode Sensor fusion implementation

40 seconds of smoothing data from Linknode Sensor fusion implementation

This shows our smoothing functions working correctly:

  • The peak and troughs on the graph are less extreme
  • Curves are smoother so there is less jitter
  • The peak is delayed by approximately 15 samples. This equates to approximately 0.25s which we have decided to be acceptable performance.

Comparison
Below are two crops of the My View function of VentusAR. The left hand (red wireline) shows the jitter as seen in v2.1. While the right video (black wireline) shows much less jitter in v2.2

Our custom sensor fusion has been a considerable bit of work at Linknode which we hope is useful for other people who want to understand the way the sensors work on these types of devices.

Mobile Application Development

Our History
Linknode are an app development company. We have have a portfolio of apps available across different platforms and their stores. We focus on cross platform sensor driven applications that fit with in our Mobile Geography domain. This post is going to be a tour around our app portfolio and what we learnt along the way.

How it started: EmergencySMS

LinkemergencySMSnode’s early apps were all for the Windows Phone market. It all started with the launch of Emergency SMS in June 2011 (the company was 2 months old at the time). This application takes the devices location, looks up the address and creates an SMS message that can be sent to the UK’s National Emergency SMS.

EmergencySMS is still available in the Windows Phone marketplace, and is still used by customers: it gets 10-20 downloads a day. I don’t consider it a masterpiece of design or implementation but it is a good place to start.

  • Start small, your apps may last longer than you think.

MegaTile – free version and premium features

MegaTileAnother consumer app (and most successful in terms of revenue generated) is a called MegaTile and allows the user to customise their home screen on Windows Phone 7 and 7.5. The user can choose an image to make a MegaTile from and set an action (launch phone dialler  send SMS, open web page etc.) for each tile.

  • Have a free version, it make users download it and gets them to convert to the full version. 7% of our users purchased after running a trial.
  • Test the upgrade process of your app on each release. We didn’t and caused ourselves a lot of negative comments from users who were unable to upgrade between v1.2 and v1.3.

Album Flow – Use a Design Pattern

AlbumFlowWe had an idea to bring the iOS style coverflow to Window Phone, this resulted in the Album Flow application. The initial version of this app was ready in 3 days. We are just polishing our 9th release and have over 100,000 users. Album Flow was featured by Appvertise (Nokia and Microsoft) and won a CreativeBloq App Generator Top Ten App.

  • Use a design pattern to make your code consistent and understandable. We use the MVVM pattern and the MVVMLite library to support it.
  • Respond to user demand and comments to get better reviews and more satisfied users.

Starting out in Augmented Reality

Where On Earth, and its cut down version – Heads Up Compass, are two apps that started to define the GIality concept and are the first examples of the use of GIality on a mobile.

HeadsUpCompassHeads Up Compass takes the data from the devices motion sensor, uses it to work out which direction you are looking and superimposes that on the camera feed. Calibrating the compass and getting accuracy from the device sensors is hard. Use the Combined Motion API on Windows Phone or equivalent on Android or iOS for better results than just a single sensor.

Where On Earth goes a step further and looks up features around you to help identify features (hill tops and towns currently) that you can see in the camera view. Where On Earth was customised for a team entering the Oxfam Trail Trekker to provide them with a heads up display of check point locations and distances.

WhereOnEarth

  • Review your maths text book: Quaternions are good when working in Augmented Reality situations, but complicated to get your head round.
  • Mobile apps should work when out of mobile signal. Design to manage offline access and syncing data. These a whole other blog post in this topic.

Windows Phone Development Summary

All of the apps covered above are only for Windows Phone. I love the process of developing for Windows Phone.

  • The tools are excellent – I can use Visual Studio (which I have plenty of experience with and is set up exactly the way I want it).
  • I can switch to Expression Blend if I want to do some more complicated user interaction.
  • I can use C# a popular language that many developers who have worked in enterprise understand.
  • Having come from a web background, I would much rather do layouts in XAML than in HTML / CSS.

My biggest complaints so far have been to do with the store and submission process (not being able to cancel an app being certified) and understanding some of the SDK design decisions taken to do with the back stack and Navigation.

Evolving Beyond Windows Phone

In mid 2012 we decided that Windows Phone was not a big enough market for some of our mobile geography plans (Although it may be getting there according to the latest stats from Kantar). Specifically we wanted to expand into using running our GIality solutions on a tablet. Whilst Windows 8 was coming (it launched October 2012), we wanted to start running GIality apps on tablets right away. We chose Android as our first tablet platform: specifically the Nexus 7 and when it was released the Nexus 10 .

VentusAR: Support for Android

Ventus_logoOur first cross platform app was VentusAR. This is a Business to Business application (so it’s not available in the Play Store) to allow you to visualise what a wind farm would look like if it was built as planned. There are many different parts to VentusAR that all need to work together and need to work across multiple platforms. The main application logic needs to be complied by the Windows Phone and Mono for Android compilers (we’ve since added Mono-touch for iOS and Windows RT compilers too).

Coming from a Windows Phone background, Android development (even using Mono for Android and Xamarin tools) feels a bit of a disjointed mess. I guess it comes of saying anyone can customize the OS to run on any hardware (the Android approach) rather the OS will only run on our hardware (Apple) or the OS will only run on hardware that meets strict guidelines (Microsoft’s approach).

  • Think about making the app cross platform-able early on. Its easier to start that way than to try to change an existing app to be cross platform.
  • The android emulator is too slow to use for real development, buy a proper device to develop on – it’s much quicker.
  • Android Resource qualifiers (screen resolution, pixel density language etc.  make designing and testing Android UI’s very hard. The Xamarin Designer helps a lot.
  • Run an automated build server as changes in the android app can have unintented affects in the other builds.

3DTry.it: Available for Windows Phone, Android and iPad

3DTryit_logo_websiteOur first public cross platform GIality app to launch is 3DTry.it (available for Android, iPad and Windows Phone). This is an app that allows the user to view published 3D models on their tablets on top of the the camera view. The models rotate as though they are in the real world. Download it from the app store if you want to see it in action.

  • The motion sensor frame of reference is different on different devices (the nexus 10 is 90°different from the Nexus 7).
  • Xamarin tools allows iOS apps to be developed on a Windows PC which speeds up development for windows users.

Summary

Having tried developing apps for all three platforms, I enjoy developing for Windows Phone the most (maybe that’s because it was the first one I started developing for). Android is frustrating due to the number of different devices, screen resolutions and version available. iOS development in c# is made easy using Xamarin tools, which have done the job for us so far.

Building Cross Platform Applications

Cross Platform Applications
Having an app is a very effective way of getting information out to your users on the move. However there are several device platforms (iOS, Android, Windows Phone, Blackberry etc.) to build apps for. The percentage market share of each platform means we decided to be inclusive and support as many platforms as practical.

IDC produce reports of market share, the data for 2011 and 2012 is shown below.

From this data, we conclude that support for iOS and Android is essential and makes 90% of the market. We also support Windows Phone as it is the only other platform with an expanding market share. Full details from IDC report.

There are several broad approaches to building cross platform apps for mobile platforms. Each has its own advantages and disadvantages as described below.

Cross-platform HTML5 app

HTML5 Powered with Connectivity / Realtime, CSS3 / Styling, Device Access, Graphics, 3D & Effects, Multimedia, Performance & Integration, Semantics, and Offline & Storage

HTML5 with CSS3, Device Access, Graphics, 3D, Multimedia, Performance, Semantics, and Offline Storage

A HTML5 app uses web technology and the devices built in browser to present data to the user. It allows apps to be created quickly in a similar way to creating a website. This can then be wrapped in a framework that allows the app to be packaged into something that can be sold in the app stores. The technologies and frameworks used to make this approach possible includes: PhoneGap, Applicaiton Craft, Appcelerator and many more

The advantages of this approach are:

  • The speed an app can be created.
  • The consistency of the look and feel of the end result (app on android looks the same as app on iOS).
  • Tthe reuse of existing skills a web developer has to create the apps.

HTML5 allows access to some of the more standard device features: 3D Graphics, Geolocation, multimedia etc. It does not allow (yet!) access to the some of the low level sensors (Accelerometer, Gyroscope, Compass) we make use of in our GIality solutions.

Native applications

Building native apps is the process of building an app for one platform. It uses built presentation framework of that platform you are working on (Cocoa Touch in iOS, XAML on Windows Phone and XML in android). This type of app allows full use of the power of the device: it can make use of all the sensors and can produce richer user interfaces that are consistent with the rest of the device.

The disadvantages it that you must make separate applications (probably in separate languages, probably maintained by different teams) for each platform you want to support.

Our approach: Xamarin Studio

As a small company with a small development team, we looked at what we could do using the different approaches described above and decided we wanted the rich user interface and  speed of native applications (we do a lot of 3D work), but we didn’t want to maintain separate code bases for each project.

four platforms

Our approach has been to use Xamarin technology to create native applications using a common language and a shared code based. We use C# (a language that many developers are already skilled in) to create code that can be run natively on Android, iOS and Windows Phone. We write a native user interface for that application in whatever technology is appropriate for that device.

Monogame Logo

Working with Xamarin technology is the MonoGame project. This creates a 3D environment based on the API of Microsoft XNA. The Monogame team describe this as:

MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro.

This allows us to create out 3D visualizations in C# writing XNA code and the game to be ported from platform to platform with very little extra work required.

Final thought: native experiences driving innovation

Scott Hanselman in his article on Apps Are Too Much Like 1990s CDROMs And Not Enough Like The Web, points out (amongst other things) that new experiences currently only possible in native apps, like the 3D experiences of GIality apps, will eventually become a web standard and become possible in a standard web app.

Scott Hanselman’s Web Experience Cycle.

I’m looking forward to writing our 3D visualisations according to a published web standard, but not until working with HTML5, Javascript and CSS is as easy and rewarding as working in C# using Xamarin Studio.