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 ?

Junit4 : testing Exception

Junit 4.7 introduces the ExpectedException rule that eases Exception testing.

# the ‘yeah, kind of…’ way
I love Square’s projects. They are pushing great libs, especially on Android. They push a high level of quality on their code (unit testing, decoupling, readability & so…).

However, I was kind of surprised when I looked into the Phrase project, a single Class project that processes Android String formatting. Awesome project by the way.
The code is quite clean and the test cases seem well relevant, but testing Exception is like :

Ok. it does the job, but the readability could clearly be improved as there are some uncessary extra code here. Adding try/catch blocks into Unit tests is simply not the way to do AMHA. These tests could be enhanced 🙂

# the partial way
You can use the expected parameter within the @Test annotation to specify the expected Throwable. The code is clearly more readable than previously:

@Test(expected = IllegalArgumentException.class)
  public void loneCurlyBraceIsAMistake() {
      from("hi { {age}.");

However, this way has its limit, this is why it is ‘partial’. Consider this test :

In this precise test case, you don’t know if the Constructor throws the Exception or the following method. You could (and should) of course split the test but let’s see some better way.

# a better way
As briefly evoked in the introduction, Junit 4.7 introduces the ExpectedException rule. The power of this rule lies 1. in covering the previously explained limitation, 2. in gaining in readability and 3. in the ability to not only handle the Exception type, but also the Exception message.
Consider the Square/Phrase test updated with ExpectedException :

As you can see, the test is clearly more consize and more readable. You only need to declare the ExpectedException rule in your test class as public. That’s it 🙂

I have submited a pull request to Square/Phrase project by correcting all the Unit Tests dealing with Exceptions so the quality and readability of the code will hopefully benefit to the community.

To sum up ‘Testing Exception’ :
– avoid try/catch blocks within your unit tests
– push readability as much as possible
– use ExpectedException rule to test the Throwable and the associated message