Categories
Development Linux Ubuntu Ubuntu SDK

uLuas – Developing a real-time Luas app for Ubuntu

uLuas logoOver the last few weeks I’ve been working on a project called uLuas. uLuas is an open source smartphone app developed using the Ubuntu SDK. It provides real-time tram stop information for Dublin’s Luas light rail service. In this post I’d like to talk about my reasons for developing this application and why I chose the Ubuntu platform.

First – and most importantly – I live and work in Dublin and commute daily using Luas. I rely on the Luas real-time passenger information (RTPI) system to provide me with information on stop times and, on unfortunate occasions, service stoppages. To consume this information, I use a number of end-user services, including the Luas website, Real Time Ireland Android app and, despite crashing on every second launch, the Luas Android app. While the backend data that these apps play with is impressive, I feel that they are presented pretty poorly, being essentially wrapped web apps with non-native and clunky interfaces.

I’ve been following the development of Ubuntu for Phones/Tablets (“Ubuntu Touch”) since its announcement just over a year ago. What excited me about it wasn’t necessarily the idea of having Ubuntu on my phone, but instead the consolidation (or “convergence”, as Canonical call it) of the code base, meaning a standardised platform to develop for. Up until this point, developing an app for Ubuntu meant relying on numerous external tools using Gtk+ bindings for drawing GUIs. The Ubuntu SDK, which was announced around the same time as Ubuntu Touch, is based around Qt Quick, which uses QML for GUI markup and JavaScript for programmatic elements. I skimmed through the documentation and followed the Currency Converter tutorial, then never did much more than that until late last year.

After the release of Ubuntu Touch 1.0, which was a release aimed at developers, I decided to flash it to my Nexus 7 and Samsung Galaxy S2. While I could see the potential in the OS, there were still some apps missing that I would require for a device to be my daily driver. One of the missing elements was an app to track the real-time information for the Luas. A quick web search for “Luas API” later and I stumbled upon Neil Cremins’ Luas PHP endpoint. The endpoint consists of a simple PHP script which, when called, returns inbound and outbound tram times for a specific stop in a meaningful JSON format:

aaron@zefram:~$ curl 'http://localhost/luas-api.php?action=times&station=BLA'

{"message":"All services operating normally",
"trams":[{"direction":"Inbound","dueMinutes":"2","destination":"Connolly"},{"direction":"Inbound","dueMinutes":"7","destination":"The Point"},{"direction":"Inbound","dueMinutes":"14","destination":"Connolly"},{"direction":"Inbound","dueMinutes":"18","destination":"The Point"},{"direction":"Outbound","dueMinutes":"1","destination":"Tallaght"},{"direction":"Outbound","dueMinutes":"5","destination":"Saggart"},{"direction":"Outbound","dueMinutes":"9","destination":"Tallaght"},{"direction":"Outbound","dueMinutes":"18","destination":"Saggart"}]}

Armed with my data source and a server to host the PHP script on, I went to work on the actual application. I opted for an interface utilising Ubuntu’s Tabs class, with one tab each for the Luas Red and Green Lines. Choosing a stop is done with an unexpanded OptionSelector which, when tapped, expands to reveal a scrollable list of stops. I have a dedicated Message box which receives updates straight from the Luas API during a service disruption. I even made the box change colour from green to red when such an event occurs – I’m overly proud of that achievement. Finally a list of inbound and outbound trams for the selected stop is presented to the user, with expected times in minutes.

Red Line and Green Line tabs with typical displays:

  red_line_0.17green_line_0.17

Example of an RTPI outage, gracefully handled by uLuas. The Message comes straight from the Luas API:

rtpi_error

Expanded OptionSelector:

OptionSelector

The dedicated site for uLuas can be found at my development website:
http://uluas.thecosmicfrog.org

The source code for uLuas is released under the GNU General Public License and is available on my GitHub profile at the link below:
https://github.com/thecosmicfrog/uluas

uLuas icon kindly created and donated by Sam Hewitt.

Categories
Linux Ubuntu

Getting Ubuntu notifications to appear on the correct monitor

Like many of you, I use Ubuntu at work with a dual-monitor setup. One of the most frustrating things I’ve always found is its behavior regarding pop-up notifications. I regularly miss new emails or chat messages due to the notification popping up on my secondary monitor, right on my eye’s blind spot.

I’ve been putting up with this up until now, deeming it to be a bug in either Unity or notify-osd itself. I had always intended on filing a bug report, but I’m glad I never did; it turns out this is desired behavior. Fair enough, I suppose, but the fix I have found is far more correct behavior in my eyes (literally – heh…).

Rather than only displaying notifications on the connected monitor, entering the below command at the terminal will make it so that notifications appear on the active monitor, i.e. the monitor currently in use. Far more sensible, no?

gsettings set com.canonical.notify-osd multihead-mode focus-follow

If you’re new to Linux, or if entering odd-looking commands into text-based interfaces makes you uncomfortable, you can also apply the above fix graphically using the following steps:

  1. Open the Unity Dash (Windows/Super key).
  2. Search for and launch dconf Editor.
  3. On the left-hand menu, expand apps and click notify-osd.
  4. Next to the multihead-mode entry, double-click dont-focus-follow and change it to focus-follow.

And that’s it. Your Ubuntu notifications should now appear on the screen you are actually working on. Resetting it to the default behavior is as simple as adding back in the dont- before focus-follow.