What are you doing Google ? #3

This is the third post of a looooong list regarding what I do not agree with the Android source code.
I have the chance to create Android applications, so I regularly read codes, good ones as well as bad ones…

What is my goal of doing so ?
I give myself the freedom to criticize what Google do because, as a developer, we have to improve days after days! Improving means not only practicing, but also
exploring and studying quality open source projects. So either we have to study the right stuff, or we have to highlight what is wrong!
Btw, don’t misunderstand me, I like Google projects !

Naming consistency
Let’s talk in this post about naming consistency. To do so, we will take the MotionEvent class from the android project.
As stated in the documentation, « [MotionEvent is] used to report movement (mouse, pen, finger, trackball) events »
I am currently writing another post which will deeply describe the android touch mechanism (some teasing now 🙂 but here is the big picture :
A MotionEvent holds an action (down, up, move…). It also holds a set of axis values which represent individual fingers position(in multi touch environment).
Each finger in the set has an unique id, called pointerId. However, each finger in that set has also an index that could vary within 2 MotionEvents.

So as you can second guess, the MotionEvent object exposes methods to get the pointerId (unique value) from a varying pointerIndex.
This method is the following : public final int getPointerId (int pointerIndex)

Here, the method is quiet clean and explicite : it requires a pointerIndex as a parameter and returns the pointerId. So your sense of developer will naturaly guide you to look
for a method called getPointerIndex() from the MotionEvent object, so you could feed the previous getPointerId(int pointerIndex) method.

Guess what? No such method!
At least, no such method having this name. Yeah, why being simple and consistent when we can complexify things?
Just dig a bit and you will find a method called public final int getActionIndex ()
The documentation says : « [getActionIndex ()] returns the associated pointer index. » Well, this is exactly what we are looking for but why on earth
the name of the method (actionIndex) is unconsistent with the value returned (pointerIndex) as well as from the documentation ? This is all the more frustrating as the parameter of the previous method needs this value named differently.

So, the code we need is the following :
int pointerIndex = event.getActionIndex();
int pointerId = event.getPointerId(pointerIndex) ;

A good code is a code which has lots of specificities. Readability, naming, consistency.

As much as possible, be rigorous with yourself and don’t neglect these simple little naming consistencies.

What do you think ?

What are you doing Android ? #2

This is a second post of a long comming list, I think… Check my previous one.

Clean coding is, from my point of view, the ultimate goal for a developper. A goal that could take a life long experience. In that journey, I, sometimes, don’t undestand some design choices made by the Android Team regarding their SDK (AOSP & play-services…) that goes against that goal… I have plenty question in my mind while using the SDK, from architecture choices to naming…

Let’s take a simple example regarding the naming convention:

Check this TileOverlayOptions class as an example : 

It has various getters such as getZIndex() or getTileProvider(). However, its related setters are not setZIndex() nor setTileProvider() as expected, but defined as zIndex(float zIndex) and tileProvider(TileProvider tileProvider).

Google is so powerfull that it allows itself to break the naming convention of getters/setters.
These little changes could sound derisory but why breaking standart industry convention ? Is there any meaningfull reason for that ?
Indeed, in standard java, methods should be verbs that describe its action, as described in the documentation :

Although a method name can be any legal identifier, code conventions restrict method names. By convention, method names should be a verb in lowercase or a multi-word name that begins with a verb in lowercase, followed by adjectives, nouns, etc. In multi-word names, the first letter of each of the second and following words should be capitalized.

Here, zIndex() and tileProvider() are nouns that does not reflect at a glance what they are supposed to do. Of course we can deduce it, but it requires some -epsilon- extra effort than facing the standard naming rules.

As a developper, being effective to reach our goal goes through these simple little standard steps. Don’t neglect them.

What do you think ?

What are you doing Android ?

I, sometimes, don’t undestand some design choices made by the Android Team regarding their SDK (AOSP & play-services…)… I have plenty question in my mind while using the SDK…

But let’s take a simple example.

I was interested in the Maps v2 SDK and especially the ability to add another TileOverlay while benefiting from the maps core (gesture, rendering & so…).
So I looked into the documentation and found that the GoogleMap object has the addTileOverlay() methods that returns a TileOverlay.

This is exactly what I need. Perfect.

Then, I wanted to remove this overlay. So I looked for the equivalent method, expecting something like removeOverlay(TileOverlay previouslyAddedOverlay) from the GoogleMap object.. But no such thing…
By digging a bit more, one can find the remove() method from the TileOverlay object itself.

Wait. What is that ??

The GoogleMap object has the responsability to add an Overlay but it does not have the one to remove it ? Instead, the added Overlay can remove itself ?
This is, from my point of view, a serious responsability issue. Indeed, if we imagine the underlying implementation, this means that the Overlay has to be highly coupled with its parent so it could ask the latter to remove itself. I think this coupling is just some waste and should have been avoided.

If we try to develop a coherent Object with well defined responsability, we would expect that if Foo could add Bar, Foo should also be responsable for removing Bar…

What do you think ?