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.
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.
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.
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
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.