Author Archives: tjerkw

About tjerkw

Software Engineer focus on Backend and Android

An Emerging Android UI Pattern for Contextual Actions

When showing a ListView on Android, there are often more actions associated with a single list item. Providing access to these actions in a simple manner is not easy. This article provides insight into how this problem was solved in the past.

Consequently it explains an emerging UI pattern which provides a much better solution. And last-but-not-least, an open source implementation, which you can use in your Android project.

Important note: I did not invent this pattern, it is already used by some high quality Android apps, such as the new Spotify app. Which initially gave me the idea to implement it myself.

Older Approaches

Some different approaches where used in the history of Android (1).

  • By long-pressing on the list item.
    • This would bring up a context menu, where the user can choose the appropiate action.
  • By swiping the list item left or right
    • After the swipe the list item would reveal the options for that list item.
    • It was the twitter app that introduced this intially
  • By a popup showing the actions
    • This is better known as the quick-actions popup. It looks like a balloon from a comic.

All of these approaches have disadvantages. Long-pressing and swiping are difficult to discover. They all hide the information presented below them. Conclusion: they kinda suck.

The new Slide-Expandable Pattern

The new way to solve this problem is to accompany every list item with a “more” button. Once that button is clicked, a panel slides out of the bottom of the list item which provides access to the contextual actions.


As with all ui-patterns, an example are worth a thousand words.  The Spotify app has one of the best implementations. A normal listview looks as follows:

It shows a list of songs. For each song there are different actions, such as playing the song, enqeueue the song, navigating to the album of the song, etc.

When tapping on the text of the song, the main action will be executed. In this case it is playing the song.

The other actions are hidden in an contextual menu. After the user taps on the triangle in the bottom-right corner of a list item, the contextual menu slides reveals itself. It is shown together with a sliding animation, giving the impression that the contextual menu was hidden below the list item

The following pictures shows the state after the contextual menu is fully shown:

When a context menu is already open, it will be hidden when another context menu is opened. The new menu will animate in, while other will animate out.

This can be seen in the frames on the right showing the context menu in the 3DWeapons app, which I developed:


The main advantages of this pattern are the following one:
  • Discoverability
    • The “more” button (in spotify a triangle) is easy to discover, indicating that there is more to be shown.
  • No Overlays
    • Once the contextual menu is shown, it does not hide any other data that the user is currently working with.
  • Physical Analogy
    • It feels like you open a drawer. This relation of a UI pattern with the physical world is often what it makes a success.

An Implementation for Android

Since I liked this pattern so much, I wanted it in my own apps. But I could not find any library for Android to solve this problem, so I took to oppertunity to create one myself.

The result is the Android-SlideExpandableListView project (4). Usage documentation can be found on the github page.

Feel free to embed it in your Android project!



An Overview of Platform Integration on Android

One of the strong points of Android is that it allows apps to be tightly integrated with the platform. Apart from just opening an app it is also possible to write an app that enables users to access the functionality of that app in other ways.

I noticed that a lot of people are either not aware these features exist, or they don’t understand them fully. Because I think these features are important I decided to write a small article that dives into these features. I will also focus a little bit on how this work on Android 3.0 (the next version of Android that also works on tablets). Each section will focus on a certain platform integration feature.

This article focuses on the functionality and is not meant to be technical.

Quick Search Box (QSB)

Searchable content

Quick Searching

Each app has the ability to register itself with the QSB. The app can then provide searchable content that a user can find using the general Android QSB. This adds a new entry point to the application. For example by installing the Spotify app you can search your music trough the QSB. Clicking on a found song will start the Spotify app which will show the details.

The official video below shows all the features in the QSB.

Continue reading

The Future of Software Engineering: Model Driven Engineering

In this first article I will cover Model Driven Engineering (MDE , also called Domain Driven Design DDD) and briefly explain the core concepts of MDE. MDE is a relatively new research field in software engineering, the first ideas are from research papers in the end of the 20th century. A lot of research is done in the last decade and it has become more prevalent in the software industry.

First some of the problems that MDE tries to tackle are  discussed. After that the core concepts of MDE are covered. The article will end with some applications of MDE.

What MDE Tries to Solve

As a programmer you may not notice this on a first glance, but there are some basic problems with the current programming approaches. The holy grail of software engineering is to perform software development in a similar way to how they do it in mechinical engineering: create a model of your software, check that model for failures and use that model as a blueprint for actually creating your product. Lets look at the problems we have in achieving that goal.

The gap between Problem Domain and Implementation

Software is written to achieve a certain goal for a certain domain. This domain is called the problem domain. Examples of such domains are banking, healthcare, social network etc etc. The goals are made explicit by a joint effort between the domain experts and software developers in some kind of requirements document. These requirements are mostly specified in human readable text and refer to concepts in the problem domain. It is the task of the development team to implement the software given the requirements.

The problem here is that the solution to the problem (the implementation) is expressed in a (relatively low level) programming language, which only provides algorithmic concepts. The requirements, on the other hand,  are specified ambigously in text using problem domain concepts. This makes it difficult to check if your requirements are met. It would be easier if we could express the solution, or even the requirements themselves, in a model which refers to concepts related to our problem domain. The solution that MDE provides is the ability to create intermediate languages in which one can use problem domain concepts to specify a model. Or as Douglas C. Smith puts it:

“Model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively.”

Dealing with Software Evolution

Change is a major factor in software systems, requirements change, personnel leave and join, and even the software/deploy platforms change over time. When requirements change the software is out of sync and also needs to be changed. When new programmers join the company they have to understand code written by someone else. A change to a new software platform may require a complete rewrite of the implementation!

Again the solution that MDE proposes is the use of higher level models. These higher level models are closer to the problem domain, smaller then the implementation and with no boilerplate code. The model is platform independend, easier to understand and therefere it copes better with change.

Model Driven Engineering Concepts

While not all problems MDE solves are discussed we move onto the real deal: MDE itself. In this section the MDE approach is discussed briefly to give you a glimpse into the future of software development!

The Unifying Power of Models

The major corner stone of MDE are models. Without going into much detail you can view a model as a representation of system written in a certain modelling language. In MDE any software artifact is viewed as a model. This may be a code, but also requirements are specified as a model. All models conform to a  metamodel. Suppose we have a model written in a modelling language A, then that model will conform to the metamodel of the language A. This is similar to how a C++ program (the model) conforms to the C++ specification (the metamodel). Or how an XML document (model) conforms to an XMLSchema (metamodel). Or how a BNF syntax specification (model) conforms to BNF (metamodel). This is visualised in the diagram below.

The 3 Layers in MDE

The diagram also shows the metametamodel layer, which is out of the scope of this article. But let’s just say that the metametamodel has a nice property: it is defined in itself (for example xmlschema defined in xmlschema).

The concept of model might look a bit vague at this point. It may look like just a cosmetic change: what we call a program is called in model in MDE. This is partially true. A program may be a model, but a model does not have to be a program. For example the data in google maps provides a partial model of the world, this however can not be seen as a program. Also a model does not have to be textual like most programming languages. A model is a logical entity and it can be edited visually or textually depending on the MDE framework you use. For now one can see a model as some kind of annotated graph.

Increasing the Level of Abstraction

Abstraction is an important concept in computer science. Developers and researchers used abstractions to express their programs in terms of their design instead of the underlying computer technology (assembly, c, c++, php, sql, java etc). This shielded them from the complexity of those underlying platforms. Again MDE takes a similar path, it too increases the level of abstraction.

Currently most software projects are written in general purpose programming language (GPLs). As explained in the problem section these language are not close to the problem domain. A solution that to this problem is the use of domain specific languages (DSLs). Current GPLs are language like Java, C++ and PHP while DSLs are languages like SQL, Excel, HTML. The problem with DSL’s is that they are limited and not easy to create.

An ideal DSL is a language that fits your problem domain perfectly. Here is where the main power of MDE comes in: it allows one to a create DSL very easily using your own domain concepts. The DSL can then be use to create models which are closer to your problem domain. These models can then in turn be used to define your final implementation.

Bridging the requirements gap

Code Generation

An attentive reader might think: so where is the actual code/implementation? The most used approach is to write a code generator which generates GPL code from your DSL model. If the model changes new code can be generated. However if the DSL metamodel changed the code generator also has to be changed to generate new code. This is actually how it is often done in most industry applications today. Maintaining your code generator may seem like a disadvantage. However if your DSL is good enough the code generator only has to built once for each target platform. The rate of change of a well designed DSL is also low compared to the rate of change of your DSL, therefore the code generator does not have to change that often.

Code generation is nothing new. For example when you compile your C++ application it basically generates a low level model (opcodes) from your high level model (your program). A database management system translates (generates) your SQL query to relational algebra, optimizes it, and executes code to retrieve the data. XML Data is fed into an XSLT stylesheet to generate a website / digital print etc. MDE basically provides a framework on a higher level.

Another approach is to make your DSL executable. This is a more theoretical approach; one has to define the semantics of your DSL formally. This approach is currently under heavy research. In fact my master thesis was about this approach.

Model Checking, Model Transformations and More

Another important advantages of MDE is that it allows certain rigorous mathematical techniques to be applied on it. For example model checking can be applied on a model of the software. In this sense MDE brings us closer to the holy grail of software engineering: 100% bug free software!

There are other advantages of having models as artifacts: we can transform models to other models using model transformation. Suppose we could generate an initial software model from the requirements model. Using model transformation we could trace how a certain change of a requirement impacts the software model, this is called impact analysis.


MDE can basically be used in any software project. However its main benefit is prevalent in bigger software projects with multiple stakeholders. A short list of concrete applications is given below to give the reader some concrete examples:

  • Usage in data centric applications: The model describes the data, constraints, relationships and workflow. The implementation (a web applicaton) could be generated from this model. Forms, form validation, SQL Code, correct control flow, etc are all generated from your domain model.
  • Usage in function critical applications: A model is needed to perform model checking.
  • Mobile Application Development: writing the same application for multiple platforms proves difficult due to the differences between the platforms. A DSL provides one language for all platforms.

Most applicatons of MDE are domain specific and therefore only used by a certain company or in a certain domain. Therefore it is difficult to give some real world examples.


MDE basically raises the level of abstraction as has happened always in computer science. It is fairly new and of course time has to tell if it succeeds. However its goal is ambitious: it provides a solution to the growing complexity of software systems and takes a big step from moving from programming to mature software engineering.

MDE itself is maturing. MDE is used more and more in practice. Big companies are adopting it (for example ASML, Microsoft, Motorola, SAP, Ordina, Atos Origin and IBM). And also tool support becoming better and better (for example: Eclipse EMF).

Below are some references if you want to continue reading:

And one in Dutch:

Welcome to Tjerk’s Tech Blog!

Welcome to my tech blog. In this blog I will discuss anything related to computer science. I will try to keep a objective viewpoint and discuss disadvantages and advantages of different approaches. It is important to keep an academic view on subjects and I will try to give a high level summary about each subject. If a specific technology is discussed it should be put into a proper context.

The general subjects I am thinking about now are:

  • Software Architecture
  • Programming Languages
  • Mobile Development / Networking
  • Relation between Software and Mathematics

I only will place an article about a specific subjects that are:

  • Subjects that are in the news
  • Subjects that i am excited about
  • Subjects that i am working on
  • Subjects about things i think every Software Engineer should now.

It is not my intention to tell the one-and-only truth. I will only try to give my own opinion on matters, of course I will back this up by arguments and references to great resources. I encourage people to challenge my views and give constructive remarks to improve my articles!

So again, welcome to my blog.

Tjerk Wolterink