Samsung Mobile Innovator: A Step in the Right Direction

Windows Mobile developers that have used the Windows Mobile Unified Sensor API may know that painful reverse engineering process took place to add support for Samsung and HTC phones. This is because no phone manufacturer has released the internal API specifications for their device sensors!

However, Samsung recently released the SDK for their Light Sensor and Accelerometer on their new Samsung Mobile Innovator website. I don’t have a Samsung phone available at the moment, but the SDK looks pretty straightforward! And although it would have been ideal if Samsung had officially supported the Sensor API, this is a step in the right direction! A published API is better than no API. Hopefully HTC follows suit!

Here’s a snapshot of the managed bindings that were included with some of the SDK sample code:

namespace SamsungMobileSdk
{
    public class Accelerometer
    {
        public struct Vector
        {
            public float x;
            public float y;
            public float z;
        }

        public struct Capabilities
        {
            public uint callbackPeriod; // in milliseconds
        }

        public delegate void EventHandler(Vector v);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetVector")]
        public static extern SmiResultCode GetVector(ref Vector accel);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetCapabilities")]
        public static extern SmiResultCode GetCapabilities(ref Capabilities cap);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerRegisterHandler")]
        public static extern SmiResultCode RegisterHandler(uint period, EventHandler handler);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerUnregisterHandler")]
        public static extern SmiResultCode UnregisterHandler();
    }
}

I’ll be adding support for the official Samsung API to the Sensor API shortly.

Back from Hawaii!

The deafening silence for the past week on my blog was due to my being in Maui! It was a great trip overall.

High point: I swam with a 4 foot long sea turtle.

Low point: I let someone convince me that the Road To Hana was a good idea. I am pretty sure that Road To Hana is actually the largest man made fractal. Here’s my artistic rendition:

hana

The scenery and such is unbelievably beautiful, but not even that can offset the nausea that sets in after the 300th hairpin turns on the highway. Here’s an actual satellite image of a typical 1 mile stretch of road along Hana (tile this image 40 times for actual representation):

hanareal

Learn Something New Every Day...

Recently I started jotting down anything new that made me say "oh cool!". Some are rarely used C# language features, some are API mechanics, and some are just random trivia. Here's what I've come up with so far:

C#'s stackalloc Keyword

stackalloc is basically handy way to allocate an array on the stack and can provide several conveniences.

Instead of allocating a locally scoped array (which is backed by the heap and managed by the garbage collector), you can get better "bare metal" performance by using stackalloc:

float SomeFunction(float[] input)
{
float dataResults;
float[] data = new float[3];
// we are calculating a result from input and storing interim results in data
return dataResults;
}

At the end of this method, a float array is sitting around waiting to be garbage collected. Instead, that function can become:

unsafe float SomeFunction(float[] input)
{
float dataResults;
float* data = stackalloc float[3];
// do something with the data and input
return dataResults;
}

In addition to taking the garbage collector and heap allocation out of the equation to eek out a little more performance, you also get a native float pointer. This can make interop with unmanaged code quite friendly, rather than a giant mess of fixed statements that would come about as a result of using float arrays.

 

C#'s ?? operator

Consider the following method:

Foo EnsureNotNull(Foo foo)
{
if (foo != null)
return foo;
return new Foo();
}

You can trim that down a bit by using a ternary operator:

Foo EnsureNotNull(Foo foo)
{
return foo == null ? new Foo() : foo;
}

But why use that when ?? is a binary null check operator; I.e., it returns the left if it is not null and the right otherwise:

Foo EnsureNotNull(Foo foo)
{
return foo ?? new Foo();
}

 

Hardware Graphics Acceleration and Asynchronous Calls

This is a tip I learned way back in my hay day of amateur game development. Many OpenGL/Direct3D may be just asynchronous calls on the hardware, and subsequent operations may end up resulting in them waiting for the previous operation to finish. The following is a very common pattern in drawing routines:

void OnPaint()
{
glClear(GL_COLOR_BUFFER_BIT);
// paint a bunch of stuff
// glDrawStuff();
glSwapBuffers();
}

Here, the code is immediately making paint operations following the clear. This results in those operations waiting until the clear has completed before executing. Restructuring the code as follows can squeeze out a little more performance:

void OnPaint()
{
// paint a bunch of stuff
// glDrawStuff();
glSwapBuffers();
// clear the buffer after the background and foreground are swapped
// this clear will take place asynchronously and be complete
// when we start to draw the next frame!
glClear(GL_COLOR_BUFFER_BIT);
}

I implemented this in GLMaps recently, and saw an FPS increase from 49 to 51. That's a ~4% increase! Using this technique, any static preprocessing/setup can actually just be run at the end of the drawing operations, rather than at the beginning. (Concurrently using the CPU and GPU between frames to get a net gain in FPS)

 

Handy C# 3.0 Shorthand

This tip didn't actually catch me by surprise, since I read through the C# 3.0 new features. However, old habits die hard, so I often forget to use them. Prior to C# 3.0, the following would be a standard class declaration:

class Foo
{
int myBar;
public int Bar
{
get
{
return myBar;
}
set
{
myBar = value;
}
}

double myMoo;
public double Moo
{
get
{
return myMoo;
}
private set
{
myMoo = value;
}
}

float myCool;
private float Cool
{
get
{
return myCool;
}
set
{
myCool = value;
}
}
}

With C# class declaration shorthand, developers can now eliminate much of the redundancy (the properties and backing fields are implicitly defined):

class Foo
{
public int Bar
{
get;
set;
}

public double Moo
{
get;
private set;
}

public float Cool
{
get;
set;
}
}

Also, when declaring an instance of that class, prior to C# 3.0, a common pattern is to set some initial properties:

void MakeFoo()
{
Foo foo = new Foo();
foo.Bar = 0;
foo.Cool = 0;
}

With C# 3.0, you get additional shorthand (less characters, not lines), and a more aesthetically pleasing syntax:

void MakeFoo()
{
Foo foo = new Foo()
{
Bar = 0,
Cool = 0
};
}

 

That's it for tips for now. Share 'em if you got 'em!

Blacklisted by Google's Geolocation Service

banned

Several months ago, I described how one could use Google Gears to easily add Geolocation and GPS to their Windows Mobile applications. Basically, this is a trick that would work with any embedded browser by adding and scripting a DOM element, or by using my unsavory window.location hack when that is not possible (as is in the case of Pocket IE).

I was recently trying to reuse this code, and I noticed that the Geolocation sample page I had hosted was not working on Windows Mobile anymore; the service seemed to be returning an invalid response. I navigated to that same URL in Google Chrome and Firefox and it worked fine. I then tried navigating to the Gears Geolocation sample in Pocket IE, and that worked as well. I verified that I still had the most up to date code hosted on my domain. Still no luck, as the code had not changed.

So out of curiosity, I hosted the geolocation page on a separate domain and navigated to it within Pocket IE. 'Lo and behold, it starts working. So mentally, I constructed this chart in my mind:

  Pocket IE Google Chrome Firefox
code.google.com Works Works Works
koushikdutta.blurryfox.com Broken! Works Works
supersecretdomain.com Works Works Works

My conclusion? Google has blacklisted my domain! And, to be honest, I'm not really sure why. I'm using their sample code on my domain to get geolocation data, but using the results outside of the context of the browser.

Congratulations Google, you have earned the first honorary YouBastard tag on my blog!

 

Edit:

Google Gears EULA. I haven't violated it as far as I can see, but they do reserve the right to cut off access to the service at their whim.