Apple iOS

Apple iOS (originally iPhone OS) is a mobile operating system created and developed by Apple Inc. and distributed exclusively for Apple hardware. It is the operating system that presently powers many of the company's mobile devices, including the iPhone, iPad, and iPod touch. It is the second most popular mobile operating system platform in the world by sales, after Android.

Originally unveiled in 2007 for the iPhone, it has been extended to support other Apple devices such as the iPod touch (September 2007), iPad (January 2010), iPad mini (November 2012) and second-generation Apple TV onward (September 2010). Apple's App Store is the second largest app store. As of January 2017, the store had 2.2 million mobile apps available for download.¹ Games are by far the most popular category on Apple's App Store, accounting for about a quarter of all apps available on the platform. Business, education, lifestyle, and entertainment are also popular categories in terms of availability of apps. In late 2016, Apple announced that 140 billion apps had been downloaded from its App Store.

The iOS user interface is based on the concept of direct manipulation, using multitouch gestures. Interface control elements consist of sliders, switches, and buttons. Interaction with the OS includes gestures such as swipe, tap, pinch, and reverse pinch, all of which have specific definitions within the context of the iOS operating system and its multitouch interface. Internal accelerometers are used by some applications to respond to shaking the device (one common result is the undo command) or rotating it in three dimensions (one common result is switching from portrait to landscape mode).

iOS shares with OS X (used by Apple laptops and desktops) some frameworks such as Core Foundation and Foundation Kit; however, its UI toolkit is Cocoa Touch rather than OS X's Cocoa, so that it provides the UIKit framework rather than the AppKit framework. It is therefore not compatible with OS X for applications. In addition, while iOS also shares the Darwin foundation with OS X, Unix-like shell access is not available for users and restricted for applications, making iOS not fully Unix-compatible either.

Major versions of iOS are released annually. The current version, iOS 10, was released on September 13, 2016. It is available for the iPhone 5 and later iPhone models, the fourth-generation iPad, the iPad Air and iPad Air 2, the iPad Pro, the iPad mini 2 and later iPad mini models, and the sixth-generation iPod touch.

Native apps must be written in Swift or Objective-C (with some elements optionally in C or C++) and compiled specifically for iOS and the 64-bit ARM architecture or previous 32-bit one (typically using Xcode). Swift is a new language for programming iOS and OS X apps that was first introduced in June 2014. Prior to Swift, most iOS apps were developed with Objective-C. Many existing apps in the App Store are built with it, and it's still possible to build apps with just Objective-C. In iOS, there are four abstraction layers: Core OS, Core Services, Media, and Cocoa Touch. The SDK contents is broken down into the four sets corresponding to the four abstraction layers.

Android

Android (from its former owner Android, Inc.) is a mobile operating system (OS) currently developed by Google, based on the Linux kernel and designed primarily for touchscreen mobile devices such as smartphones and tablets. Android's user interface is mainly based on direct manipulation, using touch gestures that loosely correspond to real-world actions, such as swiping, tapping, and pinching, to manipulate on-screen objects, along with a virtual keyboard for text input. In addition to touchscreen devices, Google has further developed Android TV for televisions, Android Auto for cars, and Android Wear for wrist watches, each with a specialized user interface. Variants of Android are also used on notebooks, game consoles, digital cameras, and other electronics.

Initially developed by Android, Inc., which Google bought in 2005, Android was unveiled in 2007, along with the founding of the Open Handset Alliance – a consortium of hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices. Android applications (“apps”) can be downloaded from the Google Play store, which features over 2.8 million apps as of April 2017, among which 2.6 million apps are free apps.²

Android's source code is released by Google under open source licenses, although most Android devices ultimately ship with a combination of open source and proprietary software, including proprietary software required for accessing Google services. Android is popular with technology companies that require a ready-made, low-cost and customizable operating system for high-tech devices. Its open nature has encouraged a large community of developers and enthusiasts to use the open-source code as a foundation for community-driven projects, which add new features for advanced users or bring Android to devices originally shipped with other operating systems. The success of Android has made it a target for patent litigation as part of the so-called “smartphone wars” between technology companies.

Android apps are written in Java programming language. The Android SDK tools compile your code along with any data and resource files into an APK, an Android package, which is an archive file with an .apk suffix. One APK file contains all the contents of an Android app and is the file that Android-powered devices use to install the app. App components are the essential building blocks of an Android app. Each component is an entry point through which the system or a user can enter your app. There are four different types of app components:

•  Activities. An activity is the entry point for interacting with the user. It represents a single screen with a user interface.

•  Services. A service is a general-purpose entry point for keeping an app running in the background for all kinds of reasons. It is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface.

•  Content providers. A content provider manages a shared set of app data that you can store in the file system, in an SQLite database, on the web, or on any other persistent storage location that your app can access. Through the content provider, other apps can query or modify the data if the content provider allows it.

•  Broadcast receivers. A broadcast receiver is a component that enables the system to deliver events to the app outside of a regular user flow, allowing the app to respond to system-wide broadcast announcements.

A comparison of Android and iOS features is shown in Table 1.1.

Google Services

• Maps is a Google satellite, which gives an in-depth accurate map of almost every city in the world. Google maps gives directions from how to get from one point to the other, figures out the quickest route possible, and gives an Earth/Satellite/Street view. Maps is available on browsers as well as mobile phones, allowing custom maps as well as saved directions to be saved on Google Accounts and later be accessed from all devices.

The map itself is downloaded from the cloud server when the user browses it. If user would like to know the route to some destination, the cloud server calculates the best route and sends it to users' devices.

• Google Translate is an online translating tool, which translates text from one language to the other instantly for a user.

The phone does not store all the language mappings. Words or statements are sent to the cloud server to be calculated to the target language, in which processes, the machine learning and natural language processing techniques, are used to enhance the translation accuracy, which cannot be achieved using the limited resources on smartphones.

• Google Docs are online applications, which allow people to create, edit, or view different types of documents. In addition to word documents, Google Docs also support PowerPoint slides and Excel spreadsheets. Google Docs can be synchronized across all devices through a user's Google account. This allows the user to access his/her documents on any device as long as he/she can access Google Docs' server using a browser, and edit and share them without time and location restrictions.

The users collaborate on the same document, which requires the cloud to maintain the global document state and synchronize the document state to mobile devices.

Dropbox, cloud storage

Dropbox is a popular cloud-based storage service which supports mobile devices. It can help users store photos, docs, videos, and other files in clouds. Files in Dropbox are tracked with a version control system, each version is backed up, and users can access them using their mobile devices. It provides an easy approach to share a large file by sharing their Dropbox' URL even if a user does not have a Dropbox account. A Drobox client is required to be installed on mobile devices in order to manage files in the cloud. Compared to the desktop Dropbox client, the mobile version only downloads the files to mobile devices as the user instructs it to do so. When some files are added, deleted, or updated, new versions of files are synchronized to the cloud storage and all devices having the same Drobox account will perform an update. In this way, the new version is pushed to every device controlled by the same user and his/her file sharing peers.

The Dropbox API v2³ is a set of HTTP endpoints that help your app integrate with Dropbox. The officially supported SDKs, which are programming language wrappers of the HTTP API, include .NET, Java, JavaScript, Python, Swift, and Object-C. The Dropbox HTTP API allows developers to work with files in Dropbox, including advanced functionality like full-text search, thumbnails, and sharing. Dropbox also provides Business API that allows apps to manage the user lifecycle for a Dropbox Business account and perform API actions on all members of a team.

Office365, cloud based collaboration

Microsoft Office365 is made for company employees to work together, sharing similar features with Drobox and Google Docs. Users can share docs with their working partners right from a phone and tablet. Mobile version Office365 along with Microsoft Azure provides:

•  Easily sharing documents with the cloud-connected applications;

•  Tracking changes, comment and mark-up docs so that everyone knows documents' change history;

•  Sharing documents with others by simply e-mailing an URL.

Yelp, cloud based virtual augment

Yelp application has a feature called Monocle, which is an applicationlication of cloud-based virtual augmentation. When the user points the phone camera to one direction, the shops and restaurants are displayed as an additional layer in front of the background photo. The Monocle applicationlication captures the location and direction, fetches the data from the cloud, and organizes shop information on the photo, such as the notes to the real environment.

Internet of things, cloud mirroring

The Internet of Things (IoT) is the network of physical objects—devices, vehicles, buildings, and other items which are embedded with electronics, software, sensors, and network connectivity, which enables these objects collect and exchange data. The Internet of Things allows objects to be sensed and controlled remotely across existing network infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy, and economic benefit; when IoT is augmented with sensors and actuators, the technology becomes an instance of the more general class of cyber-physical systems, which also encompasses technologies such as smart grids, smart homes, intelligent transportation, and smart cities. Each thing is uniquely identifiable through its embedded computing system but is able to interoperate within the existing Internet infrastructure. Experts estimate that the IoT will consist of almost 50 billion objects by 2020.

The IoT objects cumulatively build the main sensing capability for mobile cloud computing and they have to be managed well for MCC applications. However, due to the large amount of objects, small systems cannot handle huge data collected through IoT devices. To address this issue, cloud-based storage services come into the picture. IoT objects can be continuously mirrored by using cloud-based monitoring and storage services; while individual or group of IoT device(s) can be virtualized and manipulated in the cloud for MCC applications, and then control or data operation functions can be executed on physical devices.

Comparison of different service models

From the above definitions, we can see that composition is a special case of offloading that does not require software code transfer, while migration can be considered a change of surrogates, i.e., from surrogate $y_j$ to surrogate $y_k$.

In Fig. 1.6, an offloading can be represented by a mapping from a set of application components $X={\{x_i\}}_{i=1,\dots ,n}$ to a set of surrogates $Y={\{y_j\}}_{j=1,\dots ,m}$. A subset of $S\subseteq X$ comprises a software application (or a service, and here we do not differentiate between an application and a service). Fig. 1.6 shows that there is no offloading present. The application components are processed on their corresponding computation hosts.

Fig. 1.7 shows offloading scenarios, where some of application components are processed on other computation hosts (i.e., surrogates). Thus, we can present offloading as a mapping between application components X to surrogates Y, which can be further classified into three scenarios: one-to-one offloading, one-to-many offloading, and many-to-many offloading.

One-to-one offloading – the offloading mapping $e:x_i⟹y_j$, where $|X|=1$ and $|Y|=1$.

One-to-many offloading – the offloading mapping $e:x_i⟹y_j$, where $|X|=1$, $|Y|=m$, and $m>1$.

Many-to-many offloading – the offloading mapping $e:x_i⟹y_j$, where $|X|=n$, $|Y|=m$, $n>1$, and $m>1$.

Partitioning and execution of data stream applications

Yang et al. [285] studied how to optimize the computation partitioning of a data stream application between mobile and cloud to achieve maximum speed/throughput in processing the streaming data. The authors claimed that it was the first work to study the partitioning problem for mobile data stream applications, where the optimization is placed on achieving high throughput of processing the streaming data rather than minimizing the makespan.⁴ They proposed a framework to provide runtime support for the dynamic computation partitioning and execution of the application. Different from existing works, the framework not only allows the dynamic partitioning for a single user but also supports the sharing of computation instances among multiple users in the cloud to achieve efficient utilization of the underlying cloud resources.

Distributed abstract class graphs in mobile environments

Abebe et al. [48] presented a distributed approach to application representation in which each device maintains a graph consisting only of components in its memory space, while maintaining abstraction elements for components in remote devices. An extension to an existing application graph partitioning heuristic is proposed to utilize this representation approach.

Dynamic software deployment

Giurgiu et al. [116] developed a system that dynamically adapts the application partition decisions. The system works by continuously profiling an application's performance and dynamically updating its distributed deployment to accommodate changes in the network bandwidth, devices CPU utilization, and data loads.

Fine-grained, multisite computation offloading

Sinha et al. [249] described algorithmic approaches for performing fine-grained, multisite offloading. This allows portions of an application to be offloaded in a data-centric manner, even if that data exists at multiple sites.

Mobile Augmentation Cloud Services (MACS)

Kovachev et al. [171] presented Mobile Augmentation Cloud Services (MACS) middleware which enables adaptive extension of Android application execution from a mobile client into the cloud. MACS uses a dynamic partitioning scheme, and lightweight as extra profiling. Resource monitoring is performed for adaptive partitioning decision during runtime.

Partitioning applications for hybrid and federated clouds

Smit et al. [250] described an approach to partitioning a software application into components that can be run in the public cloud and components that should remain in the private data center. Static code analysis is used to automatically establish a partitioning based on low-effort input from the developer. Public and private versions of the application are created and deployed; at runtime, user navigation proceeds seamlessly with requests routed to the public or private data center as appropriate.

CloneCloud

CloneCloud [80] is a system that automatically transforms mobile applications to benefit from the cloud. The system is a flexible application partitioner and execution runtime that enables unmodified mobile applications running in an application-level virtual machine to seamlessly offload part of their execution from mobile devices onto device clones operating in a computational cloud. CloneCloud uses a combination of static analysis and dynamic profiling to partition applications automatically at a fine granularity while optimizing execution time and energy use for a target computation and communication environment. At runtime, the application partitioning is effected by migrating a thread from the mobile device at a chosen point to the clone in the cloud, executing there for the remainder of the partition, and reintegrating the migrated thread back to the mobile device.

The advantage of this model is that when a smartphone is lost or destroyed, the clone can be used as a backup for the recovery of data and applications [162]. Moreover, CloneCloud augments execution of the smartphone applications on the cloud by performing a code analysis for application partitioning, taking into consideration the offloading cost and constraints.

CloneCloud also supports fine-grained thread-level migration that is more beneficial compared to the traditional suspend–migrate–resume mechanisms. Considering the shortcomings, the model is only capable of migrating at points in the execution where no native heap state is collected. Moreover, CloneCloud requires the development of cost model for every application under different partitions, where each partition is executed separately on the mobile device and the cloud. Therefore, the execution of partitions on mobile device for the development of cost model may consume extra energy. Furthermore, to fit all of the proposed augmentation types, basic and fine-grained synchronization is required between the smartphone and the clone that may be resource intensive in terms of bandwidth utilization and energy consumption. Nevertheless, the authors assume that the cloud environment is secure, which is not always the case.

In CloneCloud, the privacy of data and piracy of applications is of high concern from the clones' perspective. For example, if an adversary gets a clone of the smartphone from the cloud, then the clone can be easily installed on the same model of the smartphone. Therefore, the adversary may use the clones' data and installed applications that may lead to data privacy and application piracy issues.

ThinkAir

ThinkAir [169] is a framework that makes it simple for developers to migrate their smartphone applications to the cloud. ThinkAir exploits the concept of smartphone virtualization in the cloud and provides method-level computation offloading. Advancing on previous work, it focuses on the elasticity and scalability of the cloud and enhances the power of mobile cloud computing by parallelizing method execution using multiple VM images.

The main advantage of ThinkAir is that it takes into account the energy consumption when making the offloading decisions, and supports on-demand resource allocation and parallelism to reduce execution delays [162]. The model offloading decisions are based on the profilers, and it uses an energy model to estimate energy consumption. ThinkAir's energy model is inspired by PowerTutor [236] that accounts for all parameters of the supported profilers. Nevertheless, it does not require separate application servers for the distribution of the applications. Considering the shortcomings, ThinkAir does not support unmodified applications and requires programmer support for the demarcation of offloadable methods. Therefore, if any offloadable methods are left unmarked, then ThinkAir will not be able to offload those methods, which may affect the performance of the applications. Nevertheless, the profiling process of the model incurs an overhead on the smartphone because it consumes computation power, memory, and energy.

MAUI

MAUI [89] is a system that enables fine-grained energy-aware offload of mobile code to the infrastructure. Previous approaches to these problems either relied heavily on programmer support to partition an application, or they were coarse-grained requiring full process (or full VM) migration. MAUI uses the benefits of a managed code environment to offer the best of both worlds: it supports fine-grained code offload to maximize energy savings with minimal burden on the programmer. MAUI decides at runtime which methods should be remotely executed, driven by an optimization engine that achieves the best energy savings possible under the mobile device's current connectivity constrains.

Considering the advantages, MAUI provides a programming environment where independent methods can be marked for remote execution [162]. It uses dynamic partitioning of the applications to reduce burden on the programmers. Moreover, MAUI does not only focus on memory constrains of the smartphone but also considers the energy consumption involved in the offloading procedure. Furthermore, MAUI supports fine-grained method level offloading that can offload even single methods instead of offloading the whole software blocks. However, single method offloading is less beneficial compared to combined methods (multiple methods) offloading. Another weakness of MAUI is that if the programmer forgets to mark methods (for remote execution), MAUI will not be able to offload those methods. Also, MAUI saves information about the offloaded methods (for future decisions) and uses online profiling to create an energy consumption model. When new offloading requests are received, MAUI uses history data to predict the execution time of the task. However, the execution time of the task is input size dependent that is not considered by the MAUI. Therefore, the predictions of MAUI might be wrong, resulting in wrong offloading decisions. Nevertheless, the MAUI profilers consume processing power, memory and energy, which is an overhead on the smartphones.

Cuckoo

The Cuckoo [160] framework simplifies the development of smartphone applications that benefit from computation offloading and provides a dynamic runtime system. Cuckoo can, at runtime, decide whether a part of an application will be executed locally or remotely.

The main advantage of Cuckoo is that it supports partial offloading of the applications to the cloud and uses well known tools for application development [162]. Considering the shortcomings, Cuckoo does not support asynchronous callbacks and state transferring from remote resources. Moreover, no states are saved while transferring from local to remote execution or vice versa for which Representational State Transfer (REST) [226] may be required. Another shortcoming of Cuckoo is that it requires programmer support for the modification of applications. Furthermore, it lacks security features to restrict users from installing malfunctioned codes on the server and control illegal access to the resources. Nevertheless, the offloading decisions of Cuckoo are static and context unaware.

Weblet

Zhang et al. proposed an elastic application model that enables seamless and transparent use of cloud resources to augment the capability of resource constrained mobile devices. The salient features of this model include the partition of a single application into multiple components called weblets [292], and a dynamic adaptation of weblet execution configuration. While a weblet can be platform independent (e.g., Java or .Net bytecode or Python script) or platform dependent (native code), its execution location is transparent—it can be run on a mobile device or migrated to the cloud, i.e., run on one or more nodes offered by an IaaS provider. Thus, an elastic application can augment the capabilities of a mobile device including computation power, storage, and network bandwidth, with the light of dynamic execution configuration according to device's status including CPU load, memory, battery level, network connection quality, and user preferences.

Among the advantages of Zhang et al.'s model is a wide range of elasticity patterns to optimize the execution of applications according to the users' desired objectives [162]. Consequently, the offloading decisions of the weblets are based on a cost model that accounts for various parameters, such as energy consumption, application performance, and data privacy. Considering the pitfalls, the proposed prototype uses a simple weblet launch scheduling that does not truly reflect the effectiveness of the proposed cost model. The sharing of data and states between the weblets that execute on distributed locations are prone to security issues. Therefore, Zhang et al. [291] critically analyzed elastic applications for various security threats, such as authentication, trustworthiness (of the weblet containers), authorization, communication, and auditing. Nevertheless, the proposed model is also affected by data sharing delays (smartphone–weblet, weblet–weblet) for which data replication solutions may be required. However, the data replication may give rise to data synchronization and integrity issues.

Cloudlet

In this architecture [237], a mobile user exploits VM technology to rapidly instantiate customized service software on a nearby cloudlet and then uses that service over a wireless LAN; the mobile device typically functions as a thin client with respect to the service. A cloudlet is a trusted, resource-rich computer or cluster of computers that's well-connected to the Internet and available for use by nearby mobile devices.

Rather than relying on a distant “cloud”, we might be able to address a mobile device's resource poverty via a nearby resource-rich cloudlet. In this way, we could meet the need for real-time interactive response by low latency, one-hop, high-bandwidth wireless access to the cloudlet. The mobile device functions as a thin client, with all significant computation occurring in the nearby cloudlet. This cloudlet's physical proximity is essential: the end-to-end response time of applications executing within it must be fast (a few milliseconds) and predictable. If no cloudlet is available nearby, the mobile device can gracefully degrade to a fallback mode that involves a distant cloud or, in the worst case, solely its own resources. Full functionality and performance can return later, when the device discovers a nearby cloudlet.

The main advantage of Satyanarayanan et al.'s model is that the VM based approach is less fragile compared to the process migration and software virtualization [162]. This approach is also less restrictive in terms of language-based virtualization, where systems are bound to support specific programming languages. Consequently, if the cloudlet is a cluster, then VM parallelism can be achieved by using multiple cores. Among the pitfalls of the model is that the VM synthesis process requires 60 to 90 seconds, which makes the technique unsuitable for real-time tasks. Moreover, the overlay extraction and compression that are performed on the smartphone require computation and consume battery power. Furthermore, if the smartphone VM overlay is from an old version base VM, then the overlay may not find a compatible cloudlet. Therefore, update patches are required for the old operating systems to make the overlays compatible with all cloudlets. Although the patches may resolve the compatibility issue, the patches increase the size of the overlay. Alternatively, new replacement overlays may be required using update patches. The model also requires trust establishment schemes to keep the users secure from malicious VMs. Lastly, the cloudlets are not available everywhere, which makes the proposed model less scalable.