Version française disponible

Recently, I have followed an interesting course about Medias and Google on Coursera. One of the assignments raised the question of the relationship people could have with their smartphone.

If someone instinctively and repeatedly picks up a mobile device to consume media (or conduct Google searches) while engaged in another activity, which of the following do you believe is more likely to be true of that person:

• He/she is engaged, and seeking to enhance and deepen the first activity.
• He/she is bored, and is seeking to be distracted from the first activity.

It is difficult to make a choice as the answer will probably depend on the person’s behavior. But I would go for the second answer, the person is bored and is getting distracted from his/her first activity.

Nowadays, most of the applications are using the built-in notifications system of our phones. As soon as you heard a sound coming from your phone, you are tempted to check what’s going on. There are many reasons to be notified:

• You receive a new message
• An update is available
• Your RSS reader alerts you about a new article
• A friend likes your status on Facebook
• The battery is running low.

If you are really interested in your first activity, you will have the strength to wait the end before checking your phone. You are not receiving a phone call after all, so there is no reason to check on the moment. Even a text message can wait because the person would have called if it was urgent.

Some applications exist to categorize and configure your notifications depending on your current activity. I guess people use it only in rare situations like at the cinema or when attending a meeting. They will usually not use it when they are doing an activity with some friends.

I like the talk “Slow Tech” by Joe Kraus, he tells us strong messages such as:

What are we losing – of ourselves, of our relationships to one another, of what in many ways, I would say, our humanity.

People are over connected, feeling they have many friends, but at the end, they become alone in front of their screen. Ross Douthat also points it out in his article “The Man With the Google Glasses”.

I want to share my experience and can you believe it or not, I am a software engineer and I never own a smartphone! A basic features phone is enough for me. I want to be able to phone, text and setup an alarm to wake me up, that’s all I need. For the other and advanced things, I have to confess I have a tablet, but I don’t use it so often. Actually I bought it a few months ago and it was my first touch screen device. It was a bit a shame not knowing how to use it since I was working in IT for 5 years. And I wanted to try the Android platform. So there is no doubt that I can live without a smartphone or tablet, just like I did until end of 2013.

Living without a smartphone is not a problem, but I have to admit that living without Internet, Google or a laptop will be far more difficult. However, when I’m on holiday abroad, I like to be completely disconnected from reality (no Internet, no Facebook and so on) and just enjoy the moment with my fellow travelers. Maybe you notice it, but there is something strange in my last sentence. I wrote “disconnected from reality”, but I should have written “disconnected from virtual life”. This mistake emphasizes the idea that the balance between virtual and real world is hard to define.

I feel like I am part of a minority of users. I just need to look at my friends when I received a phone call, they are laughing at me because I still have an old-fashion mobile phone without Internet. Maybe it should be me to laugh at them because they are wasting their time with their gadget phone…

What about you? Will you be capable of dropping your smartphone and come back to a classic phone?

 Version française disponible

The article “API, REST, JSON, XML, HTTP, URI… What language do you speak?” gave some explanations on web services and their related technologies, REST in particular. Let’s assume that you master this topic now, so we can continue our journey and introduce HATEOAS. Although the name sounds a bit barbaric, there is no relation to any character from Lord of the Rings!

We can reuse our example about travelling by train. Note that we are using the JSON format, but you can use XML as well.

{
  "trainNum": 123456789,
  "departure": {"station": "Bruxelles-Central", "time": "07:28"},
  "arrival": {"station": "Liège-Guillemins", "time": "08:25"}
}

This message describes a trip by giving various information such as the train number, departure and arrival stations and the schedule. But there is no information related to the context. Based on the message content, there is no way to know the origin of the data or how to get extra information (on the trip, the train, etc.). This is time for our fellow HATEOAS to help us.

HATEOAS stands for Hypermedia as the Engine of Application State. You should see clearly now! Don’t you? Ok… Let’s put it simply, it is a way to add contextual information to a message. When talking about HATEOAS for REST, we often use the term “constraint” because that extra data must follow a pre-defined and universal format. This standard (like all others) is essential to avoid that everyone creates their own proprietary format, so that they become API specific.

In the case of our trip, it could be interesting to add the coordinates of the previous and next trains. To add such links between the trains and respect the HATEOAS constraint, the message becomes:

{
  "numTrain": 123456789,
  "departure": {"station": "Bruxelles-Central", "time": "07:28"},
  "arrival": {"station": "Liège-Guillemins", "time": "08:23"},
  "_links": {
    "self": {
      "href": "http://www.triptrain.com/displayTrip?numTrain=123456789&departureStation=Bruxelles-Central&departureTime=07:28"
    },
    "nextTrain": {
      "href": "http://www.triptrain.com/displayTrip?numTrain=987654321&departureStation=Bruxelles-Central&departureTime=08:01"
    },
    "previousTrain": {
      "href": "http://www.triptrain.com/displayTrip?numTrain=147258369&departureStation=Bruxelles-Central&departureTime=07:01"
    }
  }
}

The existing data remains unchanged and a block of links has been added. REST web services can be adapted without having too much impact on the existing code, so regression is minimized.

The message has a much more functional sense; from a trip, we can jump to the next or previous one. I have to admit that this example is quite limited, but imagine applying this principle in other contexts.

By providing self-described message, the API is somehow easily discoverable. The response enables to make another request without necessarily knowing in advance all the methods available on the API. HATEOAS greatly improves the readability of your API, but the interest is real when the consumers of the web services are using this added information.

However there is a downside: HATEOAS is relatively young and the specification is not clearly defined. Besides, where can we find it? Other people already asked this question earlier, it seems you can find it here: HAL – Hypertext Application Language specification. There is also this page much more easy to read which also gives you an interesting materials list (in the “Quick links” section), I would definitely recommend it for further reading.