CMSE419 Mobile Application Development Asst.Prof.Dr.Ahmet
50 Slides3.49 MB
CMSE419 Mobile Application Development Asst.Prof.Dr.Ahmet Ünveren 2019-2020 SPRING Computer Engineering Department CMSE419 AU
Topics in This Section Motivation – Web Apps vs. Mobile Apps – iPhone Apps vs. Android Apps Books and references Android Architecture CMSE419 AU
Web Apps vs. Android Apps
Advantages of Web Apps Universal access – Browsers are everywhere – Any device on the network can access content PCs, Macs, Linux, Android, iPhone, Blackberry, etc. Automatic “updates” – Content comes from server, so is never out of date Well-established tools and methodologies – In multiple languages Java, PHP, .NET, Ruby/Rails, CGI, etc.
Disadvantages of Web Apps Few and weak GUI controls – Textfield, text area, button, checkbox, radio, list box, combo box. That’s it! No direct drawing (except for HTML5 Canvas) Cannot interact with local resources – Cannot read files, call programs, or access devices on the user’s machine Inefficient communication – HTTP is weak protocol Hard to write – Requires knowledge of many technologies Java, HTML, HTTP, CSS, JavaScript, jQuery, XML Designed for large displays with mouse – So harder to use on small phone displays with touch screen
Advantages of Mobile Apps Many GUI controls – Textfield, text area, button, checkbox, radio, list box, combo box, clock, calendar, date picker, dialog box, image gallery, etc. Comparable to options in desktop programming – Supports direct drawing So animated games ala Angry Birds possible Can interact with local resources – Can read files (e.g., contacts list), have local database, access GPS, initiate phone calls, get input from microphone, create voice output, read screen orientation, etc.
Advantages of Mobile Apps (Continued) Efficient communication – Can use any networking protocols you want Easier (?) to write – Requires knowledge of one language only Java for Android Objective C for iPhone Designed for small displays with touch screen – So, many apps and GUI controls are optimized for this environment
Disadvantages of Mobile Apps No universal access – Apps must be installed one at a time on each phone – An Android app cannot run on iPhone, Blackberry, PC, Mac, or Linux box Difficult to manage updates – User must intervene to get latest versions Newer (esp. Android) – So, fewer established tools and methodologies On the other hand, Android programming is similar to desktop Java programming, and there are plenty of established approaches there
Android Apps vs. iPhone Apps
Installing Apps General apps – iPhone has larger selection – Android trying to catch up In-house-developed corporate apps – iPhone apps can only be installed via the App Store iPhone requires you to submit app to the Apple App Store and get approval, even for apps from your own company – Unless you jailbreak your phone – Android apps can be installed through Google App Store Amazon App Store USB connection from PC Email Corporate Web site
Languages for Apps iPhone – Objective-C Similar to, but not exactly the same as, C Virtually no corporate presence for Objective-C, other than for mobile apps Android – Java The single most widely used language inside corporations – C/C The real reason Android runs Java Can call native apps (with some difficulty) via an approach similar to JNI for desktop Java From Randall Munroe and xkcd.com
Operating Systems for Developing Apps iPhone – Macs Android – Anything with Java and Eclipse Macs PCs Linux Solaris Issue – Not so much which is cooler and which you personally prefer, but rather which is already installed in corporate environments.
Bottom Line: iPhone vs. Android Which to use personally – iPhone has large market share, bigger app store, cooler interface (?), and more loyal users – Android more open and growing more rapidly – Bottom line: no clear winner, personal preferences prevail, but iPhone has edge Which to use for in-house corporate apps – iPhone apps very hard to install, Android simple – iPhone uses Objective C, Android uses Java – Bottom line: Android is clear winner
References Books (in rough order of preference) – Professional Android 4 Application Development (Meier) – Busy Coder’s Guide to Android Development (Murphy) Online only: http://commonsware.com/Android/ – Android Cookbook (Darwin) – Pro Android 3 (Komateni et al) – Android Developer’s Cookbook (Steele & To) – Android in Action, 2nd Edition (Ableson, Sen, & King) – Android Application Development for Dummies (Felker) Online references – http://developer.android.com/ By far the most important single reference. – Android forum on StackOverflow http://stackoverflow.com/questions/tagged/android – Android widget gallery http://www.droiddraw.org/widgetguide.html
Summary Web apps vs. Android apps – Web apps can run on Android, iPhone, Blackberry and regular computers. But, they have weaker GUIs, cannot use local resources (files, databases, GPS, camera), and are often ill-suited to small screens – Android apps can local resources, are optimized for small screens, have richer GUIs, but cannot be accessed on other phone types or on regular computers iPhone vs. Android – For personal use, situation is unclear, but edge to iPhone – For building corporate apps, Android is clear winner
What is Android? » Android is a software stack for mobile devices that includes an operating system, middleware and key applications. Android is an open source operating system, created by Google specifically for use on mobile devices (cell phones and tablets)
Platform Versions Code name No codename Cupcake Donut Eclair Froyo Gingerbread Honeycomb Ice Cream Sandwich Jelly Bean KitKat Lollipop Marshmallow Nougat Oreo Pie Android 10 Version number(s) 1.0 1.1 1.5 1.6 2.0 – 2.1 2.2 – 2.2.3 2.3 – 2.3.7 3.0 – 3.2.6 4.0 – 4.0.4 4.1 – 4.3.1 4.4 – 4.4.4 5.0 – 5.1.1 6.0 – 6.0.1 7.0 – 7.1.2 8.0 – 8.1 9.0 10.0 Initial release date September 23, 2008 February 9, 2009 April 27, 2009 September 15, 2009 October 26, 2009 May 20, 2010 December 6, 2010 February 22, 2011 October 18, 2011 July 9, 2012 October 31, 2013 November 12, 2014 October 5, 2015 August 22, 2016 August 21, 2017 August 6, 2018 September 3, 2019 API level 1 2 3 4 5–7 8 9 – 10 11 – 13 14 – 15 16 – 18 19 – 20 21 – 22 23 24 – 25 26 – 27 28 29
Architecture } Stack Architecture
Android S/W Stack - Application Applications Android provides a set of core applications: Email Client SMS Program Calendar Maps Browser Contacts Etc (Written in Java code) Android Play Store Entertainment Productivity Personalization Education All applications are written using the Java language. Geo-communication .
Android S/W Stack –App Framework Enabling and simplifying the reuse of components Developers have full access to the same framework APIs (Application programming interface: set of Feature rouitnes, protocols and tools Role for building software View Used to build an application, including lists, grids, text application ) used by the core applications. System boxes, buttons, and embedded web browser Users are Content Enabling applications to access data from other allowed to replace components. Provider applications or to share their own data Resource Manager Providing access to non-code resources (localized strings, graphics, and layout files) Notification Manager Enabling all applications to display customer alerts in the status bar Activity Manager Managing the lifecycle of applications and providing a common navigation backstack
Android S/W Stack - Libraries Native Libraries (C/C code) Graphics (Surface Manager) Multimedia (Media Framework) Including a set of C/C libraries used by Database DBMS components of the Android system Font Management Exposed to developers through the Android WebKit application framework (SQLite) (FreeType) C libraries (Bionic) .
Android S/W Stack - Runtime Dalvik Virtual Machine (VM) Core Libraries Novel Java Virtual Machine implementation (not using the Oracle JVM) Providing most of the functionality available in the core libraries of the Open License (Oracle JVM is Java language not open!) APIs Data Structures Utilities File Access Network Access Graphics Etc Optimized for memoryconstrained devices Faster than Oracle JVM .
Dalvik Virtual Machine Providing environment on which every Android application runs Each Android application runs in its own process, with its own instance of the Dalvik VM. Dalvik has been written such that a device can run multiple VMs efficiently. Register-based virtual machine Executing the Dalvik Executable (.dex) format .dex format is optimized for minimal memory footprint. Compilation Relying on the Linux Kernel for: Threading Low-level memory management
Dalvik Java Virtual Machine (JVM) Java Source Code Java Standard Edition Java Source Code Java Compiler Java Compiler Java Byte Code Java Byte Code Dex Compiler Stack-based byte-code Dalvik Byte Code Register-based byte-code Java Virtual Machine (JVM) Dalvik Virtual Machine (VM)
Android S/W Stack – Linux Kernel Built on top of Linux Relying on Linux Kernel 2.6 for core system services kernel (v. 2.6-3.0) Memory and Process Management Network Stack Driver Model Security Advantages: Portability (i.e. easy to compile on different harwdare architectures) Security (e.g. secure multiProviding an abstraction layer between the H/W and the rest of the S/W stack process environment) Power Management
Android Studio https://developer.android.com/studio/index.html
Android Application Development Eclipse IDE Android SDK Android Emulator Android Mobile Device
Android development Android Manifest Resource XML Java Source Generated Class Android Libraries Java Compiler .dex File Dalvik VM
Android Applications Design APPLICATION COMPONENTS Activities Intents Services Content Providers Broadcast Receivers
Android Components: Activities An Activity corresponds to a single screen of the Application. Android HelloWorld Button1 Hello World! An Application can be composed of multiples screens (Activities). The Home Activity is shown when the user launches an application. Different activities can exhange information one with each other.
Android Components: Activities Each activity is composed by a list of graphics components. Some of these components (also called Views) can interact with the user by handling events (e.g. Buttons). Two ways to build the graphic interface: PROGRAMMATIC APPROACH MainActivity.java Example: Button button new Button (this); TextView text new TextView(); text.setText(“Hello world”);
Android Components: Activities Each activity is composed by a list of graphics components. Some of these components (also called Views) can interact with the user by handling events (e.g. Buttons). Two ways to build the graphic interface: DECLARATIVE APPROACH activity main.xml Example: TextView android.text @string/hello” android:textcolor @color/blue android:layout width “fill parent” android:layout height “wrap content” / Button android.id “@ id/Button01” android:textcolor “@color/blue” android:layout width “fill parent” android:layout height “wrap content” /
Android Components: Activities EXAMPLE - Build the application layout through XML files (like HTML) - Define two different XML layouts for two different devices Device 1 Device 2 HIGH screen pixel density LOW screen pixel density- At runtime, Android detects the current device configuration and loads the appropriate Java App Code resources for the application - No need to recompile! - Just add a new XML file if you need to support a new device XML Layout File XML Layout File Device 1 Device 2
Android Components: Activities Android applications typically use both the approaches! DECLARATIVE APPROACH XML Code Define the Application layouts and resources used by the Application (e.g. labels). PROGRAMMATIC APPROACH Java Code Manages the events, and handles the interaction with the user.
Android Components: Activities Example public void onClick(View arg0) { if (arg0 Button) { // Manage Button events } } TextEdit Button Views can generate events (caused by human interactions) that must be managed by the Android-developer.
Android Components: Activities The Activity Manager is responsible for creating, destroying, managing activities. Activities can be on different states: starting, running, stopped, destroyed, paused. Only one activity can be on the running state at a time. Activities are organized on a stack, and have an event-driven life cycle (details later )
Android Components: Activities Main difference between Android-programming and Java (Oracle) -programming: Mobile devices have constrained resource capabilities! Activity lifetime depends on users’ choice (i.e. change of visibility) as well as on system constraints (i.e. memory shortage). Developer must implement lifecycle methods to account for state changes of each Activity
Android Components: Activities public class MyApp extends Activity { public public public public . } void void void void onCreate() { onPause() { onStop() { onDestroy(){ Called when the Activity is created the first time. . . . . } } } } Called when the Activity is partially visible. Called when the Activity is no longer visible. Called when the Activity is dismissed.
Android Components: Intents Intents: asynchronous messages to activate core Android components (e.g. Activities). Explicit Intent The component (e.g. Activity1) specifies the destination of the intent (e.g. Activity 2). LOGIN Welcome Unveren! Activity2 Activity1 unveren PASSWORD ********** Login Intent Login
Android Components: Intents Activity2 Multiple choices might be available to the user! View Implicit Intent Activity2 Activity1 Intents: asynchronous messages to activate core Android components (e.g. Activities). Implicit Intent The component (e.g. Activity1) specifies the type of the intent (e.g. “View a video”). } IntentFilters
Android Components: Services Services: like Activities, but run in background and do not provide an user interface. Used for non-interactive tasks (e.g. networking). Service life-time composed of 3 states: Starting Destroyed onCreate() onStart() onDestroy() Running (on background)
Android Components: Content Providers Each Android application has its own private set of data (managed through files or through SQLite database). Content Providers: Standard interface to access and share data among different applications. insert() APP update() Content delete() Provider query() DB e.g. Photo Gallery
Android Components: Broadcast Receivers Publish/Subscribe paradigm Broadcast Receivers: An application can be signaled of external events. Notification types: Call incoming, SMS delivery, Wifi network detected, etc
Android Components: Broadcast Receivers BROADCAST RECEIVER example class WifiReceiver extends BroadcastReceiver { public void onReceive(Context c, Intent intent) { String s new StringBuilder(); wifiList mainWifi.getScanResults(); for(int i 0; i wifiList.size(); i ){ s.append(new Integer(i 1).toString() "."); s.append((wifiList.get(i)).toString()); s.append("\\n"); } mainText.setText(sb); } }
Android Components: Broadcast Receivers BROADCAST RECEIVER example public class WifiTester extends Activity { WifiManager mainWifi; WifiReceiver receiverWifi; List ScanResult wifiList; public void onCreate(Bundle savedInstanceState) { mainWifi (WifiManager) getSystemService(Context.WIFI SERVICE); receiverWifi new WifiReceiver(); registerReceiver(receiverWifi, new IntentFilter(WifiManager.SCAN RESULTS AVAILABLE ACTION)); mainWifi.startScan(); }
Android Components: System API Using the components described so far, Android applications can then leverage the system API SOME EXAMPLEs Telephon Manager data access (call, SMS, etc) Sensor management (GPS, accelerometer, etc) Network connectivity (Wifi, bluetooth, NFC, etc) Web surfing (HTTP client, WebView, etc) Storage management (files, SQLite db, etc) .
Android Components: Google API or easily interface with other Google services:
Android Application Distribution Each Android application is contained on a single APK file. APK FILE Java Byte-code (compiled for Dalvik JVM) Resources (e.g. images. videos, XML layout files) XML Files C Libraries (optimal native C/C code) CMPE419 AU
Android Application Distribution Each application must be signed through a key before being distributed. Applications can be distributed via Web or via Stores. Android Play Store: application store run by Google but several other application stores are available (they are just normal applications).
Android Application Security Android applications run with a distinct system identity (Linux user ID and group ID), in an isolated way. Applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities. Applications statically declare the permissions they require. User must give his/her consensus during the installation. ANDROIDMANIFEST.XML ses-permission android:name “android.permission.IACCESS FINE LOCATI ses-permission android:name “android.permission.INTERNET" /