Calendar and specification for the course assignments.

Android introduced a new user interface language to the world, one that is gradually evolving in flexibility and expressiveness. The first application we will build exhibits range of new concepts you will not have come across before. Here we tour this app in detail, exploring each of the artifacts we have composed, and attempt to get a sense of how they fit together to form a running app.

Android, like IOS, has introduced a new visual language for interaction on the devices it supports. This language is different from previous graphical environments (Windows, OSX), and is optimised for touch based interaction. In the second version of the donation app we start to get a sense of this language and the programming paradigms to support it.

We continue developing the Donation app, providing solutions to the exercises set in the previous lab. Additional widgets are introduced as well as a model class and simple authentication.

This first application is already composed of a range of classes related to each other in via different types of relationships. We can capture this design graphically in UML, exploring the true nature of the structure of the app. We then move on to a new app though which we will explore the major features of the SDK.

Android is a sophisticated, multi-layered operating system encompassing a wide range of features, capabilities and components. This is organised into a 'Stack', whereby each layer communicates with the layer immediately below. Here we review this stack and briefly examine the primary components at each layer. We also press on with exploring the SDK.

The Activity is at the heart of almost all android applications. You have already experience in designing and implementing a number of simple ones. Here we review the general nature of activities and define the principle the concerns of the programmer has to bear in mind. In particular, we review navigation principles in Android and the visual language that it provides.

We conclude our treatment of navigation with instructions on how to implement the up button. We also briefly explore some of the features newly introduced in Java 8, in particular lambdas, the implementation of which we demonstrate with some simple examples.

We review the file I/O implemented previously where we incorporated a serialization mechanism to write Java objects to a Json file format. This required some significant enhancements to the models package, including a completely new Serializer class. Experience is provided in the use of implicit intents in two new features which facilitate selecting a contact from the phone's contact lists and sending an email to the selected user.

Modern Android Activities tend to be composed of one or more Fragments - as opposed to consisting of a single layout. This introduces a slightly more complicated creation process. However, using fragments opens up other opportunities we will explore in later labs.

Two new features are introduced - the ability to delete a subset of the list view and the ability to swipe horizontally in either direction and display each details view in turn.

Our application allows storage of configuration data in the form key-value pairs. Menu access is provided to a layout that allows input of credentials and other settings that will be used later when cloud access capability is added. We avail of a number of Android types such as the PreferenceFragment class and SharedPreference interface.

We examine how maps from two providers, Google and MapBox, may be integrated into an Android application. Both providers have published a rich API, a subset of which we use to implement a simple MyRent feature.

SQLite is a relational database management system (RDBMS) that becomes an integral part of the application. It implements most of the SQL standard. It is a very popular database engine and is widely used in web browsers, operating and embedded systems and mobile applications.

In an earlier lab we developed an application to persist the MyRent Residence model class state using a SQLite database. Here we port the core elements of this app to the MyRent application.

Data within an app may be stored using an SQLite database. But further steps are required if this data is to be made available to other applications. This additional feature may be incorporated using a content porovider. A content provider presents data to external applications in the form of tables similar to those used in the SQLite database.

To date we have developed MyRent as a standalone application in which its data is stored in a SQLite database. In this topic we split the app into client-server modules. SQLite is retained but functions as a local cache, the primary model data repository now being allocated to a service. In developing the service we adopt a test-driven-development (TDD) approach, using a simple Play JUnit app to verify the service before refactoring the standalone MyRent app into a client capable of consuming the service api.

A service is an application component that can perform a background task. A receiver is a component that allows registration for system or application events. We use both as a means of automatically refreshing cache data from the service. A BroadcastReceiver listens for a particular intent, sent either in response to booting the device or when our application starts. It then sets an alarm that triggers the refresh service at either default or user-define intervals. We also demonstrate how to manually refresh data by making a direct call to service.

Here we explore how to capture photos using an existing camera application. Although most Android devices have at least one camera we, nevertheless, verify this in advance of shooting. We show how to capture a thumnail, save the photo and add it to a, for now one-photo, gallery.

We conclude the course with instructions on how to sign an app and with a brief discussion on the supporting cryptographic technologies.

This is a supplementary topic that addressess refactoring the MyRent suite to make it compatible with databases, such as Mongo, where the model id (the primary key) is auto-generated in the service. To date the id has been generated in the client and passed to the service (Play). It also provides a pattern applicable where the Retrofit Callback is required with more than one type of response body T.