Here we proceed to explore in detail the creating of a simple activity class + the associated layout. This process will seem quite complex on first contact - but as we proceed through the labs over the next few sessions the deep structure should start to emerge.

Introduce a second screen to display the list of donations made by the user. In addition, enable our app its first "Model" objects, which will be used to store the individual donations made by the user.

We continue the implementation of Donation to including the welcome, sign up and login. Support these views with a User model, and validate the users on log in. Continue to build on your Donation repository.

A total of 5 exercises were set at the end of the earlier lab - Donation-03.

We start a new application in this lab, which will be succeeded by numerous version over the next few topics. In the first lab the focus is on explaining the essential 'plumbing' of the app, and introducing the first Interface based listener you may have encountered.

In this version of MyRent, we introduce a range of UI Widgets to evolve the UX into something more useful. These widgets will be 'active', meaning that the host Activity will be intercepting and responding to events the user may generate when interacting with the application.

Our current version of MyRent (V01) only permits a single Residence to be entered. In this lab we seek to manage a list of residences. To do this we need to extend the model by including a new class - 'Portfolio' - to manage all our residences. We will also need a new Activity - ResidenceListActivity - to display the full portfolio of residences.

This is a short lab whose aim is to provide a detailed explanation of event handling via a simple standalone non-android application

In a significant update to the app, we introduce navigation within the app using an Action Bar. This will allow us to create new residences, or navigate to existing ones. Additionally, we will explore a simple date picker dialog to allow the user to select a registration date for the residence.

Introduce into MyRent a serialization mechanism to save and restore the residence list to and from a file. The app will load the contents of this file on launch and update the file if residence data is updated.

We continue to evolve navigation support in the app, providing an 'up' button in the action bar to allow navigation from the ResidenceActivity to the ResidenceListActivity.

Java 8, initially released in March 2014, is a major upgrade providing many new features one of which we examine here, namely lambda expressions. We consider situations where such expressions may be used to provide a less verbose alternatitive to anonymous classes.

This is a solution to the event handling lab.

Activities within an application can reach out to activities in other applications to perform specific tasks. In this lab we introduce two new features - selecting a contact from the phone's contact lists, and sending an email to the selected user. Both of these features require the use of 'implicit' intents.

Supplementary MyRent lab to demonstrate how to request permissions at run time. We restrict ourselves to the single permission READ_CONTACTS.

An Activity may comprise one or more fragments, each of which represents a portion of a user interface. Multiple fragments can be combined in a single actiity to build a multi-pane screen. In this lab our purpose in introducing fragments is to later facilitate the inclusion of a horizontal swipe feature to the ResidenceActivity class.

In the previous lab we gained experience in using single-pane screens, a pane containing only a single fragment. Here we develop a simple application to demonstate how two fragments may be successively rendered on a single pane in portrait mode. We provide the same feature in landscape mode but additionaly allow the simultaneous rendering of an additional fragment. This is sometimes referred to as the master-detail pattern.

We introduce a facility to select and delete a subset of residences in the list view. The selected items need not be contiguous. The Android MultiChoiceModeListener interface is key to the implementation of this feature.

Here we incorporate a new feature to support horizontal 'swipe' interaction. This allows a user to page through the entire residence list, beginning from within any details view, in either direction. In providing this feature, we make of the Android ViewPager layout manager PageAdapter abstract class.

Settings allow a user to modify application features and behaviour. In this lab we demonstrate the use of settings to input a username, password pair, the size of the list of residences to download from the cloud and the frequency at which this list is automatically refreshed by a service or services. Services will be the subject of a future lab.

In this Lab, you will be required to refactor our CoffeeMate Case Study, called CoffeeMate.2.0. We will build on the previous lab and add in some new features and UI Design. In this version we will add in a few more activities and some extra layouts. On completion of this lab you'll be able to

In this Lab, you will continue to refactor our CoffeeMate Case Study, this version is called CoffeeMate.3.0. We will build on the previous lab and add in more new features and UI Design. In this version we will add in a few more activities and some extra layouts. On completion of this lab you'll be able to

This lab continues our Case Study CoffeeMate but with a major refactoring of the UI (using a Navigation Drawer) and a more detailed look at the use of Fragments and persistence (through an SQLite Database) in an Android App.

This lab continues our Case Study CoffeeMate and once again, yet another major refactoring of the app, where we introduce the ability to make API calls to our CoffeeMate Web App using Volley and introduce some basic security using Google Sign-in.

This lab is the final lab in the current version and completes our Case Study CoffeeMate with the introduction of Location Awareness and Google Maps in version CoffeeMate.6.0.

This lab 'takes a big step forward', in that we refactor the previous version (6.0) of our Case Study CoffeeMate and introduce Firebase Support via Google Authentication and a Realtime Database in version CoffeeMateFBI.1.0

Reintroduce the Donation Android app, refactor it to interact with the donation-web API

Refactor the donation-android client to use the JWT secured routes.

We avail of two Android classes, BroadcastReceiver and IntentService, to asynchronously refresh local data obtained by querying a cloud-based service. The BroadcastReceiver receives intents sent by a Context method, sendBroadcast. The IntentService handles asynchronous requests. Our approach is to initialize an alarm in the BroadcastReceiver to exercise the IntentService at interverals configurable from the settings. When the alarm fires, the local data is asynchronously refreshed.