A detailed specification of the Mobile Application Development first assignment. This comprises a standalone microblog.

Here we explore the general context of the android User Experience, it's role in the mobile platform space and the components that make up the the system. We are particularly interested in the version numbers and how version in general is managed.

Android introduced a new user interface language to the world, one that is gradually evolving in flexibility and expressiveness. Here we review the principle elements of this language and how its is incorporated into attractive and usable applications

The first application exhibits a 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. Here we review some of the major elements of this language and become acquainted with the some of the primary interaction patterns.

If you have completed this lab (but not the exercises yet) then we can review your achievements so far, and closely inspect the code we introduced to accommodate the new activity + the list. We will also review the challenges.

This simple 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.

These slides present the solution to the series of challenges in the Donation-02 lab, a series of 8 'challenges' introducing new feature into the donation app.

We should now begin to have a firm understanding of structure of an android project as presented in Studio. Here we review the MyRent v00 in detail, and review all its working parts

Although the app is still relatively simple, this app crosses a threshold in our understanding of Android.The Activity class implements multiple interfaces, each implementation responding to different widgits. Here we review this in detail, as it represents a pattern we will see in most of the application we develop.

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 review the structure, model and code in the MyRent 01 and 02 applications. The application at this stage has 2 views - sometimes called a 'Master-Detail' pattern. The Master presents a list of items which, if selected, will launch a detail view presenting the individual items. The List if items is randomly generated at application startup, and cannot be extended.

An overview of the Mobile Web Development & Enterprise Web Development assignments.

Central to almost all Android applications is the notion of an event. How events are intercepted and handled is an aspect of all android programmes. Here we review the underlying Java mechanisms used in this context

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. Here we review some of the major elements of this language and become acquainted with the some of the primary interaction patterns.

We have already explored the primary Android UX. Here we focus specifically on navigation within an android application, examining some typical patterns. In particular, we explore navigation within a single application, which can yield some interesting and surprising subtleties.

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.

Navigating "up" (as opposed to 'back') must be explicity implemented in the application. It involves enabling the up button in the action bar, handling the resultant event and also declaring the parent/child relationship in the manifest.

Last time we explored briefly navigation within an app. In this session we continue this discussion, with a focus on navigation from the users perspective, looking at how a user can arrive into an app, and also how they may move between apps.

Lambda expressions allow one to treat functionality as a method argument similar to data. This facilitates a terse alternative to anonymous inner classes where the interface contains a single abstract method, such an interface being referred to as a functional interface.

To date we have seen a small number of file formats for data, namely CSV and YAML. These are common and well suited to a range of simple applications. In Android we often use XML and Json. Here we review examples of all of these briefly.

In MyRent Lab 04 we incorporated a simple 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. Here we review these classes in detail.

Prior to API 23 it was sufficient to list the required permission in the manifest file. Beginning in Android 6.0 (API level 23) listing permissions in the manifest is necessary but no longer sufficient and users grant permissions to apps while the app is running, not when they install the app. Here we examine this rule change in the context of reading contacts in the MyRent app.

Fragments facilitate a more dynamic approach to UI design. By dividing the layout into fragments it becomes possible to alter the UI appearance at runtime, swapping in and out components as required. Here we examine how a fragment may be inserted into an activity layout from within the application code.

Deletion of a subset of the residence list is facilitated by the introducion of a contextual actionbar. This is created by a long press on any of the list items intended for removal. The contextual action bar contains a menu icon (trashcan) which when clicked on completes the deletion process. A suitable Android interface is implemented to facilitate the various actions.

In order to support 'swipe' between views at a specific level, we incorporate ViewPager support into the class.

We use settings to facilitate storage of credentials (username and password), the number of items to download across the network and how often the data is refreshed.

We briefly discuss the Google Maps API in advance of a more detailed exploration in the associated lab.

Mapbox, like Google, provides a commercial mapping service with a limited free offering that we avail of for learning purposes.

Ranks in the top ten most popular relational databases. Typical uses are in mobile, embedded and IoT apps.

The integration of SQLite into MyRent to replace the file io system follows easily from the SQLite demo lab presented last week. The DBHelper class ports without any changes. Removal of the file io artefacts is trivial as are changes to the model.

Content providers are Android building blocks that facilitate access to data between applications on the same device. Because Android runs in its own process with its own permissions an application does not automatically have access to another app's data. This restriction may be surmounted by integrating a content provider into an application.

The Play framework has very specific test support - facilitated by the JUnit libraries. This enables Play applications to be launched in test mode and specific simple tests executed on the application classes.

We examine how the MyRent app is refactored into a client-service pair, the service being deployed either locally or on the cloud.

Play Framework support for JUnit is used to create a simple set of tests run against MyRent service.

The Retrofit HTTP client is integrated into the MyRent Android client app to provide an effective communications channel with the MyRent service.

We configure an alarm within BroadcastReceiver's onHandleIntent method that initiates a process terminating in a refresh of local cached data obtained from a cloud service. The process is run on a worker thread and avails of the Retrofit HTTP client to communicate across the network so as to keep the local cached data in sync with that of the service.

In an accompanying presentation we showed how to use an alarm, receiver and service to automatically refresh the local data cache. Here we intervene manually and by exercising a menu option make a direct call to the service to retrieve the latest data set with which the cache is updated.

We subclass BroadcastReceiver and within its onReceive method we retrieve the user-input refresh interval and set an alarm to fire at this frequency. Each firing results in downloading the latest service data set and refreshing the local cache. The presentation examines the onReceive method in fine detail.

A review of a number of techniques for acquiring and manipulating images taken by the Camera under Android.

To date we have built and run debug versions of our apps. Android Studio transparently manages the signing of these apps using auto-generated debug keys. This process will not suffice should we wish to publish to the Google Playstore. Here we examine how to prepare our app for release which entails generating and storing keys and signing the app. We then dig a little deeper and examine the cryptograpic technologies that support these actions.

We conclude our discussion on app signing with a very brief examination of the underlying mathematics used in basic cryptographic functions such as symmetric key and public key cryptography. Simple examples are provided to demonstrate Diffie-Hellman key exchange and RSA (public key cryptography).

The mongoDB database is used in assignment 3. This database autogenerates a primary key id of type String. To date, using JPA, we have generated the id client-side. Here we discuss refactoring to adapt our app to a database where the id is autogenerated server-side.

A class may not implement more than one Callback. Yet in some compilation units the requirement is to use Callbacks where two or perhaps more response body types are used. An example would be the need to retrieve a list of residences and to delete a particular residence. Here we examine two patterns to deal with this situation: in one we use inner classes, in the other anonymous classes.