Android’s lessons learned


Google released a new language, trying to follow the pattern Scala vs Java, F# vs C# which is a typical facade strategy, on top of the real, but invisible, Kernel.


API level

Indeed, real world apps are based on the API level, and the discontinuity there – think about the complete reengineering needed for Google Drive&Docs from version 20 to 23 – reveals a terrible impedence mismatch.

Modern GUI

Exactly there, the UI is where a pure FP language (read Haskell and Scalax) fails to deliver its promises. Let’s focuses on the navigation drawer, the archetype of the coolest sites’ sliding menus (read Bootstrap and the html5/css3/js web) in the following paragraphs.

Applicative parallelism

How does the multitasking (or better said multi intents) machinery translate into math?? Think it twice.


When A and B go parallel instead of serial, they are graph-connected from a common source, to which they’re relative successors.

First lesson: our menu must be implemented by a RelativeLayout or by a FrameLayout.

Applicative parallelism translates into UI overlay

Safe or dynamic?

Heisenberg uncertainty principle is just entropy

Second lesson:

you can never observe the scroll position

You’ll learn how stackoverflow sucks when you try to apply their old Android’s solutions to extract the Y position of a scroller. Well, I’ll tell you that one simply doesn’t observe such a variable. After long hours, I’ve realized that I had to change my viewpoint.


Android GONE corresponds to .NET  Collapsed.

First view under the framelayout is your list of “business” items (tweets, whatever…), the second one is for the menu items. The “business” items – and they only – must be wrapped by a scroller (how many crashes otherwise!): the menu items are only an overlay, no need to capture the scroller’s position.

Finally (are you still with me?) the menu icon simply consists of a button to switch the visibility of the two views above.

3 thoughts on “Android’s lessons learned

  1. Web browsers and smartphone platforms, from the viewpoint of resources, see world in a similar way: they lay at the low end of the scale in terms of resource availability, so, the makers of dev languages for such platforms have to figure out a way to offer expressive languages that at the same time are not “resource-thirsty”.

    Javascript has followed the idea of a offering the developers a “light smell” of object orientation so as to NOT to be “resource-thirsty” and offer some “sensation” of expressiveness of the language.

    Google with Android has tried a different approach, with a more complete Object Oriented experience and expressiveness of the languages and looking for ways to AVOID “resource.thirstiness”.

    Google’s way for Android dev tools has so far been like offering a complete Object Oriented paradigm, but at the backstage level there is some “cutting at the corners” going on so as to stay at the low end of resource consumption as possible.

    If you develop with Google’s tools for Android without paying too much attention to some details, you may not realize that the “cutting at the corners” is in fact happening.

    But the truth is that it is actually going on, all the time!

    Like for instance, the use of the inflate function in Kotlin, so as to offer extensibility without the need of inheritance.

    (BTW, the use of inflate in Kotlin has some smell of extension methods in .NET)

    We know that implementation inheritance is a resource guzzler, so, the use of inflate offers a better balance between language expressiveness and resource consumption.

    When you say that “you can never observe the scroll position”, there is clearly some “cutting at the corners” going on!

    And just as you have mentioned Heisenberg, here we have another reason to remember him, as we actually “never observe” something … just like when he thought … if we cannot observe the orbits, let’s work with the quantum leaps between orbits, which is something that we can observe, even if indirectly (we can measure the photons either emitted or absorbed).

    If we cannot observe the scroll position just because it is not available due to the “cutting at the corners” going on, let’s work with and use what we can observe.

    Again, there is value to be attained with the compromise between expressiveness and resource consumption that Kotlin offers, which, for the most part, it much better than the compromise offered by JavaScript.

    Great analysis on Kotlin!

    Kind regards, GEN

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s