With this article I'm starting a series derived from how I'm designing blueBill Mobile, an Android application, but in addition to technology-related topics (not only Android) I'll talk a lot about general design strategies. A relevant effort has been made to define a design that makes testing easier and also reduces the technology-relevant part of the code to a minimum.
In fact, the whole application is being developed as a core which is just plain Java and can be implemented by different UI solutions, such as Android, web apps and desktop; examples will be given in future articles which cover also Vaadin, Wicket (for the web part) and the NetBeans Platform (for the desktop part). The articles will focus on different topics case by case, moving from design considerations to lower level details concerning the implementation, even including tools, such as Maven, the NetBeans IDE, the maven-android-plugin and the NetBeans Android plugin.
In this first article we're going to deal with design considerations about the use of MVC together with some ideas inspired from a technique callled Continuation-Passing Style (CPS). The last part of this article deals with testing and assumes prior knowledge of Mockito.
I have to thank many friends at JUG Milano and at the JavaPosse for having helped me to better understand CPS and the correct way to refer to it.
Code examples are mainly taken from blueBill Mobile for Android, version 1.0-ALPHA-3.
Let's start with a simple thing. blueBill Mobile contains a small RSS feed reader, called "News", which is used to deliver to users posts from the project blog. The requirements are easy:
The user enters a specific screen and sees a list of topics (with caption and publication time).
Each topic can be marked as read or not read by means of a context menu and it's rendered in a different way to reflect its state.
A topic can be selected so it can be read in full (and will be marked as read).
The feed can be cached in memory in case there's no network connection, or the user doesn't want to connect.
A preference says whether the application is allowed to connect to the internet.
If network connections are allowed, the news service retrieves a fresh copy of the feed.
If network connections aren't allowed and a cached copy is stored in memory, news are rendered with a warning and no attempt is done to retrieve a fresh copy.
If network connections aren't allowed and no cached copy is available, the user is explicitly asked for the permission to connect. If it doesn't confirm, the interaction terminates.
Unexpected errors (such as network connection failures) are be properly reported.
It's pretty simple, but it makes it possible to explore some design directions about the control flow moving from the backend (the news service) and the user interface (confirmations), as well as strategies for testing.