Mobile App Development COM594: Mobile Technology Lecture – Week 11 Mobile App Development

Concurrency & Concurrent Programing

Concurrency Concurrency means multiple computations are happening at the same time. Concurrency is everywhere in modern programming, whether we like it or not: Multiple computers in a network Multiple applications running on one computer Multiple processors in a computer (today, often multiple processor cores on a single chip)

Concurrency In fact, concurrency is essential in modern programming: Web sites must handle multiple simultaneous users. Mobile apps need to do some of their processing on servers (“in the cloud”). Graphical user interfaces almost always require background work that does not interrupt the user. Processor clock speeds are no longer increasing – instead we’re getting more cores on each new generation of chips. So in the future, we’ll have to split up a computation into concurrent pieces in order to get it to run faster.

Parallel vs. Concurrent Parallel: Using multiple processing resources (CPUs, cores) at once to solve a problem faster. Concurrent: Multiple execution flows accessing a shared resource at the same time. CPUs/cores work CPUs/cores resource

Concurrent Programming There are two common models for concurrent programming:  shared memory message passing

Shared memory In the shared memory model of concurrency, concurrent modules interact by reading and writing shared objects in memory. Example of the shared-memory model: A and B might be two processors (or processor cores) in the same computer, sharing the same physical memory. A and B might be two programs running on the same computer, sharing a common filesystem with files they can read and write. A and B might be two threads in the same Java program (we’ll explain what a thread is below), sharing the same Java objects.

Message passing In the message-passing model, concurrent modules interact by sending messages to each other through a communication channel. Modules send off messages, and incoming messages to each module are queued up for handling. Examples include: A and B might be two computers in a network, communicating by network connections. A and B might be a web browser and a web server – A opens a connection to B and asks for a web page, and B sends the web page data back to A. A and B might be an instant messaging client and server.

Process, Threads The message-passing and shared-memory models are about how concurrent modules communicate. The concurrent modules themselves come in two different kinds: process threads

Process, Threads A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time. threads are so called lightweight processes which have their own call stack but an access shared data. Every thread has its own memory cache. If a thread reads shared data it stores this data in its own memory cache.

Concurrency and Mobile Apps The essence of a touch screen device is that the user input (the touch) is fundamentally asynchronous. It can happen any time. As such, there must be a thread of control ready and waiting for the touch to happen so that it can be reacted to instantly (or very nearly instantly). If this is to happen, then any work to be done as a result of touch, must be delegated to a new thread of control, so that the original thread can remain awaiting the next touch. Main thread (also referred to as the UI thread). Background thread. ANR (Application Not Running)

Concurrency and Mobile Apps Long applications must be handled on a background thread. For example: Network communication; File I/O operations; Database handling and I/O Image processing Web calls Text processing

Concurrency and Mobile Apps Multi-threading is essential to ensure a good user experience but it introduces many problems which do not happen in simpler sequential programming. For example, an asynchronous activity may never complete. The programmer must ensure that this kind of circumstance is handled gracefully. The deadlock situation is well documented but care must be taken to avoid it or, at worst to detect it, and again handle it without crashing the app. It is essential that any given platform, the developer becomes familiar with the programming support tools that exist to enable concurrency and multithreading, and becomes experienced in the challenges of the creating and testing efficient and robust multithread code.

Approaches to Mobile App Development

Approaches to Mobile App Development Native Mobile App Development Cross Platform Mobile App Development Hybrid mobile app development

NATIVE APPS Binary executable files on the device. Can access all API’s made available by OS vendor. SDK’s are platform-specific. Each mobile OS comes with its own unique tools and GUI toolkit. Different tools, languages and distribution channels associated with leading mobile operating systems * IBM, Native, web or hybrid mobile app development, 2012. IBM Software Thought Leadership White Paper

NATIVE APPS Code Reusability : Low PROS Easy low-level hardware access services. Easy access to high level services important to personal mobile experience. Full use of all functionalities that modern mobile devices have to offer. High usability. CONS Code Reusability : Low Development & maintenance: Time-consuming & expensive. Designers are required to be familiar with different UI components of each OS. Upgrade flexibility: Low. Once the app is installed, it interacts with the underlying operating system through proprietary API calls that the OS exposes. These are divided into 2 categories – Low-level API’s & high level API’s. Through low-level API calls, the app can interact directly with the touchscreen or keyboard, render graphics, connect to networks, process audio received from the microphone, receive images & video from the camera, access the GPS etc. Higher level services include processes like browsing the web, managing calendar, contacts, photo album, the ability to send and receive phone calls etc.

CROSS PLATFORM APPS Separates build environment from target environment. Platform-independent API using a mainstream programming language like JavaScript, Ruby or Java. The cross-compiler then transforms the code into platform-specific native apps. The software artifact generated can be deployed and executed natively on the device. Developers can use this API to build the application including UI, data persistence & business logic. The code is then processed by the compiler and transformed into platform-specific native apps. High performance as the app is running natively on the device & improved user experience as the app has full native access to all device-specific capabilities such as integrated camera, sensors etc.

CROSS PLATFORM APPS ADVANTAGES: Improved performance and User Experience. Full access to functionalities of underlying mobile OS and device specific capabilities. DISADVANTAGES: Highly complex as cross-compilers are difficult to program. Need to be kept consistent with fragmented mobile platforms and operating systems available.

CROSS PLATFORM FRAMEWORKS * http://setandbma.files.wordpress.com/2011/12/wora-platforms.png

HYBRID APPS Combines native development with web technology. The web app runs inside a thin wrapper native app. The wrapper native app uses the OS API’s to create an embedded HTML rendering engine which provides a bridge between the browser and device API’s. The communication between web app and native app normally happens over JavaScript via custom built API’s. The bridge enables the hybrid app to take full advantage of all the features that modern devices have to offer. App developers can choose to code their own bridge or use ones provided by many of the cross-platform development frameworks such as PhoneGap.

ADVANTAGES: Flexibility of web apps combined with feature richness of native apps. Simplified deployment and immediate availability. Leverage existing knowledge. DISADVANTAGES: Poorer user experience as compared to native apps. Access to advanced device capabilities normally restricted.