Accessing the Android Barometer using Xamarin.Android

Easily:

< ![CDATA[
[Activity (Label = "HelloBarometer", MainLauncher = true)]
public class Activity1 : Activity, ISensorEventListener
{
    TextView mainLabel;  

    protected override void OnCreate(Bundle bundle)
    {
        base.OnCreate(bundle);
        // Set our view from the "main" layout resource
        SetContentView(Resource.Layout.Main);
        //Detect the barometer
        var sm = (SensorManager) this.GetSystemService(Context.SensorService);
        var barry = sm.GetDefaultSensor(SensorType.Pressure);
        //Subscribe to it
        sm.RegisterListener(this, barry, SensorDelay.Normal);
        // Get our button from the layout resource,
        // and attach an event to it
        mainLabel = FindViewById<textview>(Resource.Id.myText);
    }

    public void OnAccuracyChanged(Sensor sensor, SensorStatus accuracy)
    {
        Console.WriteLine("Things have changed");
    }

    public void OnSensorChanged(SensorEvent pressureEvent)
    {
        Console.WriteLine("Under pressure " + pressureEvent);
        var hPAs = pressureEvent.Values[0];
        var msg = string.Format("Current pressure: {0} hPA!", hPAs);
        mainLabel.Text = msg;
        var calcedAltitude = calculateAltitudeInFeet(hPAs);
        FindViewById<TextView>(Resource.Id.altitudeText).Text = string.Format("Calculated altitude is {0} ft", calcedAltitude);
    }

    double calculateAltitudeInFeet(float hPAs)
    {
        var pstd = 1013.25;
        var altpress =  (1 - Math.Pow((hPAs/pstd), 0.190284)) * 145366.45;
        return altpress;
    } 
}
]]

I mean, I know I work for the guys, but this is just *ridiculously* easy. An hour ago I was installing the SDK…

And, yes, I live high on the side of an active volcano.

Tap 7 Times to Enable Developer Options in Android Jelly Bean

How to enable developer settings on Android 4.2 | Android Central.

I just got myself a Nexus 4 for cross-platform development, but it didn’t initially appear as a device in Xamarin Studio. Initial Googling and SO’ing indicated a non-existent “Settings->Application->Developer” route to enable debugging on the phone.

Instead, the correct sequence is “Settings->About phone->{tap 7 times} Settings->Developer Options”

The Governor vs. Boyd Crowder

The Justified finale had a scene that summed up one of it’s greatest strengths: Raylan, the putative hero, and Boyd, the putative villain, demonstrate how parallel they are to each other: Raylan points to Boyd’s career and sneers at the thought that Boyd imagines himself anything other than “the bad guy.” Boyd points to Raylan’s actions and sneers that Raylan thinks he’s any different. Perfect: They are different, and make different choices, but both focus on different aspects, highlighting the ambiguity of the moral dilemmas that, taken one way, lead to acclaim and promotion in the US Marshall’s Service and, taken another, lead to universal contempt and jail.

Which they’d similarly set up with the Governor and Rick in The Walking Dead. Rick crazily hung on to the voice and visions of his dead wife while making the fateful decisions necessary for survival, the Governor hung on to the physical body of his dead daughter while doing the same. While the hard truth is that both are in the business of ordering the brutal actions that are necessary to make their group survive, Rick soothes himself by wallowing in guilt based on pre-zompocalypse morality. The Governor steels himself by sitting and staring at decapitated heads in fishtanks that are still gnawing to get at him. But why do people dwell on things? To bolster their weak spots: Rick’s belly-aching about morality implies that he needs to remind himself to not let it disappear, while the Governor’s zombiequarium implies that he needs to remind himself to never let himself relax. A similar point was made when the Governor said that, had he acted forcefully from the beginning, his daughter would fear him, but be alive. Meanwhile, we saw that Rick’s son is a little disdainful of his Dad’s morality.

But instead of developing the theme of parallelism between Rick and the Governor, they just put the Governor on the crazy train. Oh, he wasn’t just brutal, he was a sadist. He wasn’t just committed to pre-emptive murder, he was a psychopath. And most frustratingly of all, in the finale, he wasn’t a competent leader. And not only wasn’t he a competent leader in his assault on the jail, he apparently had never been competent in training his people to have the proper level of paranoia and response to deal with sneak attacks.

And just at a basic dramatic level, they cheated us of a final confrontation between the Governor and one of our protagonists. Instead, he slunk off with his A-team baddies and will now be a possible occasional appearance. Very disappointing for a show whose greatest strength is its willingness to kill off established characters.

Hungarian Monadic Notation: Call Me Maybe

Update: this is an April Fool’s joke. It’s the most incoherent, illogical thing I could think of. It’s a bad idea, it wouldn’t work, and it misses the point of everything.

Hungarian Monadic Notation: Call Me Maybe()

Update: This was an April Fool’s joke. If you are interested in monads and are a C# or Java programmer, I strongly suggest this series of posts by Eric Lippert, which explains monads in a very pragmatic way.

If you follow the world of software development at all, you know that there has been a big uptick in discussion about “functional programming languages,” a type of language that emphasizes immutability and composition of functions to achieve higher reliability and, arguably, higher productivity.

On the other hand, functional programming languages look like Klingon, but with math:

instance Monad[] where
   return x = [x]
   xs >>= f = concat (map f xs)
   fail _ = []

WTF, ammiright? (And for extra points, it’s not a right-shift, it’s “bind.” Because arcana.)

The most laughable claim of the functionistas is that functional code is easy to comprehend and debug. Lemme’ tell ya, bud, I’ve been a dozen lambdas deep trying to figure out behavior and this whole “functional code is stateless,” is more full of crap than an Oklahoma feedlot at slaughter time.

Functional programs have every flutter of state that an imperative program has, just not in any convenient stackframe. Or — and this is awesome to debug — it’s not yet in the stack frame — what’s in the stack frame is a bunch of goddamn function pointers and not-yet-enough parameters to call them. Sometimes the thing you’re stuck on is a dozen lambdas down and it’s building a goddamn function pointer that will calculate the parameters (Excuse me! I mean calculate exactly one parameter!) to another goddamn function pointer. Thank heavens you don’t have to struggle with the mind-numbing complexity of an if branch (“Oh my God! The code could go this way or it might go that way! What kind of cephalopodic mind could comprehend this tangle‽”).

And don’t get me started on compilation speed. I love this idea that the “compiler finds certain errors.” What they don’t say “And it does this in a mere several minutes. So don’t worry about missing one of those show-stopping narrowing conversions! We’ll take a look at it every goddamn time you want to fix a typo in a different source file.”

But, nonetheless, there are a few things that the FP world does that actually make sense once you machete away all the obfuscatory mathematical rigor.

Maybe Something Functional Does Right

The biggest practical thing, on a day-to-day basis, is that functional code doesn’t have to deal with null values. If you have some complex object that may-or-may-not initialize properly (let’s say a camera which may or may not be available on your phone), you are probably used to writing code that looks more or less like this:

var theCamera = AttemptCameraInitialization();
if(theCamera == null){ 
   DealWithNoCamera(); 
}else{ 
   var aPhoto = theCamera.TakePhoto();
   if(aPhoto == null)
   {
      DealWithNoPhoto();
   }
   …etc…
}

Or maybe:

try{
    var theCamera = AttemptCameraInitialization()
    var aPhoto = theCamera.TakePhoto();
}catch(npe){
    DealWithNullPointerException(npe);
}

And while the try-catch style isn’t nearly as wordy as the constant-error-checking style, it’s a little harder to debug and good coding style says that one ought not to rely on exceptions to deal with common alternatives. Contrast this with what one might see in the functional world (exact names and syntax differ between functional languages, so I’ll use Scala, whose Klingon-y parts can be swept under the rug, and can actually be comprehended by humans):

 val theCamera = AttemptCameraInitialization();
 val thePhoto = theCamera.TakePhoto();

And even if there was a problem during AttemptCameraInitialization(), no exception would be thrown. Instead, theCamera would be represented by a None object and, when a function is called on a None object, that None object simply returns another None.

So this may look like no big deal with a couple lines of code, but if you have an A that has a B() function that returns a B that has a C() function that returns a C that…a Y that has a Z() function that returns a Z, you can write code like:

var myZ = a.B().C().D().….X().Y().Z(); 

Which is much more readable than putting a bunch of checks-for-null between every method. And in this situation, you just are ploughing along nicely through your functions until one returns a None, in which case every function subsequent to that returns a None. (So how much fun is it when you’ve stepped your debugger up to that one line of code? But put that aside for now…)

So, talk to a functional guy about what’s going on and BOOM he drops the “M” word. Of all the gatekeeper-words in the mystical arcana that guard the entrance to the D&D den where all the cool functional kids are hanging, none has the power of “Monad.” It evens sounds like something that Gandalf would warn you about: “Beware the realm of endofunctors, for there, monoids become monads!”

Lemme’ tell ya’, I’ve been There and Back Again and monads are no big deal. They’re just goddamned parameterized types with a handful of easy semantic rules. Seriously. That’s it. The reason that they’re confusing is that the semantics are so stupidly underwhelming that you keep thinking “Yeah, okay, but what else?” It’s like the gate to your vast underground treasure-city being guarded by the word “friend,” a fact which is conveniently documented on the transom.

Anything Monads Can Do, Inheritance Can Do Better

So how are we gonna’ do this? Easy! Let’s say we start with a couple classes that look like this:

class Camera 
{
    Photo TakePhoto() { … etc…}
}

class Photo
{
    Bitmap GetImage() { … etc… }
    Exposure GetExposure() { …etc… }
   …etc…
}

All you have to do is define the interface to these objects, so that we can implement simple alternative “None” classes. But to help future maintenance programmers, we’re going to use a little invention of mine called “Hungarian Monadic Notation” to indicate our intent:

interface MMaybeCamera 
{
    MMaybePhoto TakePhoto();
}

interface MMaybePhoto
{
    Bitmap GetImage();
    MMaybeExposure GetExposure();
}

The way this works is that we indicate that a class or interface has this monadic intention by prefixing it’s name with an “M”. But because there are a lot of different monad patterns, you specify which monad in particular you’re talking about as the next part of the name. So in this case we have MMaybeCamera indicating that we’re looking at this particular pattern. Ditto for MMaybePhoto but you could also have, like, MEitherPhoto or MStateCamera etc. The possibilities are endless! And it’s super-easy to do and doesn’t introduce any of those stupid compilation errors!

Now that you’ve used HMN to name your interfaces, you just change your original implementations to implement the HMN interface:

class Camera : MMaybeCamera{ … original code… }

class Photo : MMaybePhoto { …original… }

But in addition, you also implement the alternative “empty” objects:

class NoneCamera : MMaybeCamera 
{
    MMaybePhoto TakePhoto()
    {
        return new NonePhoto();
    }
}

class NonePhoto : MMaybePhoto
{
    MMaybeExposure()
    {
       return new NoneExposure();
    }

    Bitmap GetImage() 
    {
       throw new MonadException("This is a none,son.");
    }
}

Isn’t that inspiringly clean code? When you call a function on a None{x} class, it just returns another new None{y} object! Or, when you need to break out a real class, you just throw a MonadException. (The details of MonadException are left as an exercise.)

Naturally, you kick this all off with a MMaybeCameraFactory to initialize your original MMaybeCamera.

Future Work

Although Hungarian Monadic Notation and it’s implementation patterns are agile best practices worthy of the enterprise, it’s true that there’s a certain amount of boilerplate code that’s associated with implementing each of the functions in the base interface.

In a future post, we’ll cover the answer:

Reflux: The Monadic Reflection Dependency Injection Framework