TAMZ I. (Design of Applications for Mobile Devices I) Lecture 1. Introducing Mobile Platforms.

Transcription

1 TAMZ I (Design of Applications for Mobile Devices I) Lecture 1 Introducing Mobile Platforms

2 Contact Information Office: EA-409 Address: Dept. of Computer Science, FEECS VSB-TU Ostrava 17. listopadu Ostrava-Poruba Phone: Web: 2

3 Course Requirements During the semester: Implementation (10 points) programming of certain assignments in labs, one point for each completed assignment Presentation (5 to 10 points) presentation of pre-selected topic from subject area in labs, minutes. Project (10 to 25 points) implementation of chosen project for a mobile device + its defense. Required to complete the course! Total sum (15 to 45 points) After the end of the semester: Final exam (20 to 55 points) 3

4 References jquery Mobile API Documentation Apache Cordova API Documentation W3 Schools: A. Kosmaczewski: Mobile JavaScript Application Development, O'Reilly Media, 2012 J. Reid: JQuery Mobile, O'Reilly Media, Inc., 2011 P. Retting: Professional HTML5 Mobile Game Development, John Wiley & Sons (14 Sep 2012) J. M. Wargo: PhoneGap Essentials: Building Cross-platform Mobile Apps, Addison-Wesley Professional, 2012 J. Munro: 20 Recipes for Programming PhoneGap, O'Reilly M. 4

5 What is a Mobile Device? A pocket-sized computing device, typically with: a small visual display screen for user output a miniature keyboard or touch screen for user input. Examples: Mobile phones Smartphones, Tablets Navigation devices Cameras, portable media players Handheld game consoles IoT devices, monitoring devices, smart devices... 5

6 Limitations of Mobile Devices Small (often lower-resolution) display (on some types of devices even grayscale/bw) on specialized devices Limited input options (phone/software touch keyboard) Lower operating memory & internal storage space (the latter partly solved by external memory cards) Limited CPU power + absent or limited GPU capabilities Limited instruction set (e.g. only software-emulated floating point arithmetics, no SSE, vector-processing instructions) Network connectivity issues Smaller library of system functions Power considerations... 6

7 Mobile Operating Systems Vendor-specific firmware, vendor SDKs for custom builds Real-time operating systems ios on Apple devices Linux-based: Android Ubuntu Mobile (?) Firefox OS, Tizen, Sailfish OS, Jolla Windows Windows Phone 8.x, Windows RT (8), Windows CE BlackBerry OS Samsung BADA Symbian OS 7

8 Mobile Frameworks HTML5-based frameworks AngularJS, jquery Mobile, Sencha Touch, Cordova, Ionic, ReactNative, PhoneGAP, Xamarin Flash Lite commercial CodeName One JavaME Java 2 Micro Edition, JavaFX 3rd party frameworks (of varying quality) Java-based Python-based QT-based LUA, 8

9 Programming languages HTML(5) + Javascript/TypeScript + CSS(3) Java (SE Android Development, ME, EE web) Objective C, Swift ios C/C++ native libraries, e.g. Android NDK, singlechip solutions, custom firmware development, RTOSes Processing language (Arduino) C# Windows 8,.NET compact framework, Xamarin Python Exotic choices: LUA, Lazarus (Pascal), Shell script, 9 PHP,

10 New platforms changed everything! Device fragmentation Platform fragmentation Vendors try to keep customer by vendor lock-in Applications sold by vendors directly through their Play Store/AppStore/Marketplace/Market/... 2 dominant platforms: Android ios (~15%) Windows (Windows Phone 8, Windows Mobile) Blackberry (US) / Symbian (EU) Feature phones may still offer Java ME 10

11 Why is platform fragmentation bad? Different environment Different APIs Different programming languages (Java, Objective C, Silverlight, C#, C/C++, ) Different SDKs, specific OS needed for SDK and development (Windows, MacOS) The code needs to be written several times We may use Native libraries (usually in C/C++) Platform-independent SDKs (e.g. CodeName One) Android/JavaME basic common parts in Java, GUI/API calls separately HTML 5 for simple applications PhoneGap 11

12 Source: Best description of current situation English legend: Operation Sustainable development Phase 1: Confusion of tongues Phase 2: ios Android Windows Mobile/Phone Firefox OS Chrome OS Ubuntu Mobile Sailfish OS 12...

13 Current multi-platform development Android ios Windows Phone User interface User interface User interface Application layer (using native API ) Application layer (using native API ) Application layer (using native API ) Java/NDK Objective C SilverLight/XNA Core library (C, C++, C#, HTML5+CSS+JS, ) Business Layer Access Layer (Data Access, Service Access) Data Layer 13

14 Mobile Platforms Common Features 14

15 Generic Mobile OS Architecture Application (e.g. Web Browser) Native Applications Application framework (platform APIs) Application management software (AMS) Basic libraries and services Virtual Machine* OS Runtime Host Operating System Kernel * Virtual machine is not used on some platforms, which run native code directly. Usually, we use platform APIs for development, but on most platforms we can also write native code using built-in or even user-supplied libraries, or a HTML+JS+CSS application run in the web browser or embedded web view. 15

16 Handling Security Any seriously considered mobile OS needs protection from malicious code that may access system information or resources. Advanced security model provided by desktop OS may be too memory-consuming (although frameworks like SELinux have already been included in latest Android versions). The classic security model, which is provided in most mobile devices, is the sandbox model, where the applications are run in a closed environment in which they can only access insensitive resources, the access outside of the sandbox must be granted by the user. Typically, all sensitive APIs have to be listed in application manifest (in some cases the application using these APIs may have to be signed) and are part of a permission model. 16

17 Java on Mobile Platforms 17

18 Why is Java so popular? Java was originally intended for embedded and mobile development. Many old-time mobile developers were used to program in JavaME, which was easy-to understand platform with well-defined standards (jcp.org) Still the main choice for dumb phones Per-app revenues were still better than Android (150% based on 08/2011 data, but ios has 200%). Source: Mobile Marketing Watch Android uses Java bytecode as a step in developing mobile applications. Java-base SDKs (Netbeans/Eclipse) are available for all 3 major platforms (Windows, MacOS, Linux) 18

19 Official Java Editions In 1995 the first version of Java, now known as Java Platform Standard Edition (JavaSE), was released. Since that time its landscape has changed significantly. Standard Edition (JavaSE) Designed to run on desktop and workstation computers. Enterprise Edition (JavaEE) This edition is aimed at server-based applications. Contains buit-in support for Servlets, JSP and XML. Micro Edition (JavaME) Designed for devices with limited memory, display and processing power. Java Card programming of Smart Cards (e.g. SIM, payment) 19

20 Android OS Architecture Source: 20

21 Example of a Mobile Platform Java ME 21

22 Configurations and Profiles Capabilities of devices within the JavaME may vary greatly. A PDA may have a much larger display than a pager. One Java platform will most definitely not fit all. In order to accommodate a broad range of consumer electronics and embedded devices JavaME introduces two new concepts: configurations and profiles. Optional Packages (APIs) Profile Libraries Configuration Java Virtual Machine 22

23 CDC versus CLDC CDC is a subset of JavaSE, plus some extra classes CLDC is a subset of CDC. JavaSE CDC CLDC 23

24 Connected Device Configuration This configuration is designed for devices with more memory, faster processors and greater network bandwidth It is appropriate, at least in the near term, for home automation and automotive navigation, entertainment and telemetry systems. A programming model closer to JavaSE simplifies porting existing desktop clients for enterprise systems to mobile devices that support CDC. CDC has never been used much outside of Multimedia Home Platform (MHP) and some handheld game consoles. 24

25 Connected Limited Device Configuration This configuration is intended for devices with intermittent network connections, small processors and limited memory. Expected targets included two-way pagers, mobile phones and entry-level PDAs. However, in practice, the functionality delivered by CLDC and the associated profiles and optional packages is very close to that of CDC. As a consequence it is used today on most high-end mobile phones, or smartphones, which are replacing PDAs in the marketplace. 25

26 Java Language Differences There are three main areas that distinguish the Java Language for CLDC to those defined in the Java Language Specification. Floating Point Math The CLDC 1.0 implementation of the Java language does not support floats. CLDC 1.1 specifies such support. But MIDP 2.0 only requires CLDC 1.0. Finalization The CLDC does not support the finalize() method because an overhead and processor requirements are too steep. Error Handling The JVM supports a limited set of error handling exceptions due a significant demand on the system's device-dependent. 26

27 JavaME Java Virtual Machines C virtual machine (CVM) classic Java virtual machine (not Dalvik!) used with CDC requires 32b microprocessor at least 2MB of RAM & 2.5 MB of ROM Kilobyte virtual machine (KVM) used with CLDC 16b/32b (slow) microprocessor limited math, string, and I/O functions lacks some features of classic JVM only a small subset of JavaSE core libraries at least 32kB of RAM & 128kB of ROM 27

28 Profile A profile supplements a configuration to provide capabilities for a specific family of devices or specific industry segment application need. For example, a configuration provides a generic Java API for battery powered, limited display and processing capability systems, while a profile provides a supplemental Java API specific to cellular telephones, which is a member of this larger group of devices. A profile must supplement a configuration. A profile will not work without the configuration and virtual machine providing the core classes/api and runtime environment. 28

29 Profiles CDC profiles CLDC profiles Foundation profile basic CDC profile Game Profile developing game applications Personal Profile complex UI components FP Personal Basis Profile simple UI components (single window) RMI Profile Remote Method Invocation support classes Mobile Information Device Profile local storage, UI, network PDA Profile better displays, larger memory compared to MIDP KJava Sun-specific API for Palm OS Information Module Profile subset of MIDP 1.0 without its display and input classes 29

30 Mobile Information Device Profile The Mobile Information Device Profile (MIDP) is a key element of the Java 2 Platform, Micro Edition (JavaME). When combined with the Connected Limited Device Configuration (CLDC), MIDP provides a standard Java runtime environment for today's most popular mobile information devices, such as cell phones and mainstream personal digital assistants. The profile can be characterized by the following features: rich user interface capabilities extensive connectivity multimedia and game functionality over-the-air-provisioning end-to-end security 30

31 MIDP Optional Packages Once again the basic library was insufficient for some applications (remember the JavaSE history), which resulted in the development of several new packages: PDA Optional Package more PDA-specific APIs, e.g. PIM, files Bluetooth API Bluetooth communication (SDK problem) Wireless Messaging API SMS (MMS) capabilities Location API location tracking Presence & IM API JavaME version of JAIN, IM & presence support based on SIP Mobile Media API audio/video controls, streaming media JavaME Web Services API Web Services-related XML classes Security and Trust API Interaction with security smart card Mobile 3D Graphics API 3D graphics, mainly for games... 31