Keywords

1 Introduction

In our everyday life, we use several different types of computing devices, like desktop computers, smartphones, or tablets. Since those device types have different strengths and weaknesses, we use them for different tasks or in different situations. As a result, our favorite applications and our data are distributed across multiple devices [2]. Integrating the applications running on different devices is often a cumbersome task performed manually by the user. This is due to the fact that most apps only offer a user interface and not a service interface that can be accessed by other applications. As a consequence, users use workarounds to simplify the cross-device integration, e.g., by using tools like Dropbox, to realize some form of data level integration. In contrast, our framework supports integration on a higher level. Instead of working with the data produced by another app, we want to directly integrate the service creating the data. This, however, requires the existence of consumable service interfaces.

The Android platform encourages developers to create apps that offer services which can be integrated by other apps on the same device. For instance, a phonebook app on an Android smartphone can integrate the service to take a picture offered by the camera app. Yet, these services can only be accessed when both apps run on the same device, since Android-specific communication means are used and data is exchanged using local plattform-specific data stores. However, based on this interaction, the framework to be demonstrated is able to provide the integration of services offered by Android apps even across devices.

2 System Overview

In this section, we give an overview of our framework enabling Cross-Device Application Integration of Android apps (XDAI-A). For this purpose, we relate the different buildings blocks of our approach as visualized in Fig. 1 to the steps performed during the cross-device integration at runtime (see Fig. 2).

Fig. 1.
figure 1

Overview of our implementation [3]

Full size image

Infrastructure on the Providing Device: In order to provide services for applications running on other devices, we install two types of apps on the providing Android device: The first is an adapter app that communicates with the existing Android app and is responsible for the adaptation of requests and responses. Secondly, an interface app is responsible for providing the external service interface and receives the request and transmits the responses back to the requestor. External service requests received by an interface app are translated into an intermediate format and delegated to the adapter app. The adapter app interprets adaptation rules defined using a DSL to translate the request (details in [3]). The rules define the local data stores in which data contained in the request shall be stored, e.g., databases or file system, and which local services need to be invoked. Furthermore, these rules define how responses of the local services are translated back into the intermediate format. Within this translation, the data referenced by the local response is embedded into the response for the requestor, since references on device-internal data stores cannot be resolved by external requestors. The interface app again translates the intermediate response to the desired external response format, like JSON, and sends it to the requestor.

The decoupling of interface and adapter apps allows to support different kinds of external interfaces, e.g., a RESTful interface and an XML-RPC interface. Currently, our framework includes an interface app which provides the services of Android apps over a RESTful interface. Moreover, by realizing the adapter as a separate app, our approach can be used without having to change existing Android apps. We have defined adaptation rules for several common Android apps and by providing a DSL, we simplified the specification on further adapters compared to programmatically defining adapters.

Mediator: The mediator is a central entity, implemented as a node.js webserver, that can be compared to a service registry. The interface apps of providing devices register their provided services at the mediator. For this, the mediator has a RESTful API, which also provides different ways for the requestor to select a device which shall provide a service: (i) The mediator can be queried for a list of devices capable of providing a service. This list can be shown on the requesting device in order to select the providing devices. (ii) The mediator can broadcast requests to all devices capable of providing the requested service and the user can claim the request on one of those devices. (iii) A QR or PIN code can be created by the mediator, which is shown on the requesting device and scanned/entered on the providing device to indirectly bind the service. With respect to privacy, options (i) and (ii) are limited to devices of the same owner but option (iii) can be used to in situation where both the providing and requesting device have different owners, e.g., integrate an app running on a private smartphone into an application running on a public internet terminal. The requestor and the provider can communicate directly with each other or indirectly via the mediator. The latter has the advantage that the mediator can translate between different communication protocols or can buffer requests/responses.

Changes to the Requesting Application: External services created using our framework need to be integrated into a requesting application. If a requesting application already has an import interface, the interface of an external service can be directly defined in a way that it can be used by the requesting application. Alternatively, mismatches between the external service’s interface and the import interface can be resolved by using approaches to build adapters on the requestor’s side, i.e., Iyer et al. [1] developed such an approach for the Android platform. If the requesting application has no import interface, it has to be adapted by the application’s developer. For web applications, we provide a JavaScript library that can be used to integrate services running on Android devices.

Fig. 2.
figure 2

Example usage of the XDAI-A framework

Full size image

System in Use: Figure 2 shows an example of an application running on a tablet that uses our framework to integrate the camera app on a smartphone. The upper part of the figure shows what is happening in the background and the lower part shows what is visible to the user. The application on the tablet retrieves a list of devices able to provide the service to take a picture from the mediator. The user selects a device and the request is sent via the mediator to this device. There, the request is received by the interface app and translated into the intermediate format. Thereafter, the corresponding adaptation rules are applied by the adapter app. As a result of this adaptation, the camera app is opened and the user can take a picture. Subsequently, the adapter app receives the response and adapts it for the requestor. The interface app delegates the adapted response back to the requestor, which can further process it, e.g., by embedding the picture. Steps 1–3 look differently if options (ii) or (iii) are used to determine the providing device. Moreover, instead of sending the request/response via the mediator, it might be directly sent to the corresponding device.

3 Demonstration

The demonstration is twofold: In the first part, we demonstrate the user benefits by showing a demo web application that integrates services of different existing Android apps across devices using the XDAI-A frameworkFootnote 1. In addition to the example illustrated in Fig. 2, the demo application integrates various other services, e.g., sharing text and images using a messenger app, selecting an existing picture using the file explorer, adding events to the calendar, and retrieving contact information from the phonebook. The demonstration shows that the adaptation of requests and responses is only noticeable in form of a delay if files have to be up-/downloaded. The different techniques to determine the providing device are demonstrated and we discuss the implications of those techniques with respect to privacy. The second part of our demonstration focuses on the internals of our approach: We explain the specification of adaptation rules using our DSL, provide various specifications for the demonstrated integrations, and discuss how multiple services can be aggregated into a single external service.