Download Week 2 Power Point Slides

2016 Android Version Market Share
Mobile Device Hardware
• RISC Processors
– Low power; ideal for mobile devices
– Simple processors (35000 transistors per chip is typical)
• ARM
– Dominates the mobile technology market
– No microcode, Most instructions are single cycle
– Conditional execution and switched register banks
• MIPS
–
–
–
–
All instructions are single cycle
Loads data/instruction in one cycle
Eliminates multiply/divide to allow very high clock rates
Register windows speed up subroutine calls, but limits the
number of nested calls
Developing Android Applications
• Java using the Android Software Development Kit (SDK)
o Most Android applications are developed with the ADK
o Code in Java, then compile into Dalvik executables, which run in a
specialized virtual machine optimized for mobile devices
• C and C++ using the Native Development Kit (NDK)
o Does not significantly improve performance in most cases
o Useful for CPU-intensive operations such as signal processing
o The Android framework provides two ways to access C/C++ code
 The Java Native Interface (JNI)
 The NativeActivity class to interact with Services & Content Providers
• Google App Inventor
o For Novice programmers, who want to create Android applications
o Created by Google, maintained by MIT
o Apps created by drag-and-dropping visual objects
Application Security
Applications can store data persistently with the
following limitations
– They can only write to their own data folders
– They must request user permission for access to services
such as: internet access, audio recording, and near field
device interaction, SD card
– Inherits low level Linux securities
– Applications can create content managers to expose their
data to selected other applications
– Applications can access data made available by various
content providers that are installed (ex: contact list)
Mobile Development
Considerations
• User Priorities: 1. Phone, 2. Text messaging, 3. Camera, 4. MP3 Player, 5.
Other useful things like Google Maps, Browsing, Facebook, and applications.
– Never interrupt a user activity, instead use the led notification light,
vibration, message bar, or ringtones
– Always be polite
– Applications should be intuitive, easy to use, and conform to standards
• Limited battery life: Detect when the battery is not charging and
avoid compute-bound operations if this is the case.
• Life cycle: Applications do not control when they start or end.
Seamlessly respond to applications being paused and restarted
Considerations (cont.)
• Messaging costs
– Let users choose between high accuracy/fast/high cost
transmission and low accuracy/slow/low cost messaging
– Consider frequency and times of updates and minimize the
amount of data transferred
– Transfer at off-peak periods
– Always respect user preferences
• Limited processing power
– Code should be as efficient as possible
– Make use of background services and worker threads to
maximize responsiveness
– Save and restore processing states
Considerations (cont.)
• Limited onboard persistent storage
– Applications should cache data when possible
– Manage data stores to remove unneeded data faithfully
• Limited memory sizes (less so than in the past)
– Minimize application size
– Obfuscate code to minimization footprint and reduce
reverse engineering (Pro Guard Java class Shrinker)
• Intermittent or unreliable connections
– Graceful degradation for seamless operation
– Revert to limited operation or previously cached data
Considerations (cont.)
• Consider the users that might use applications
– Android devices are sold in hundreds of countries having different
languages spoken and different cultures
– Options to accommodate the disabled: font or audio interfaces
– Be liberal with user preferences
• Consider state-of-the-art device features
– Utilize device features when they exist
• Varied screens
–
–
–
–
Different user interfaces other than buttons and text boxes
Detect orientation changes
Accommodate various display resolutions
Internationalize text and color resources
Model- View-Controller (MVC)
• Model: Code to manage the data
– Standard Java classes using Java IO and/or interfaces to
Android preferences, on-board SQL, and content providers
• View: User interface
– Android: XML text files in a layout directory and View
classes
– New projects offer standard views used by many
applications
• Controller: Wire together the model and view
– Android: the Activity class serves this function
MVC Benefits
• Provides a top-level conceptualization of an
application
• Keeps the overall structure of an application
simple as it increases in features and
complexity
• It is a best-practice standard for application
development
• Maximizes the reusability of model and view
modules
Terminology
•
•
•
•
•
•
•
•
•
•
Widget: A user-interface object (Button, TextView, etc.)
Layout: Visual arrangement of widets in containers and views
View: A single user screen; base class for most layout widgets
Activity: A launchable task usually controlling a view.
Stack: Activity stack controlled by back/forward operations
Toast: An output popup that shows for a fixed period of time
Inflate: Operation to parse XML into an object for further use
Resource: Various entities declared separate from the code
Style: Look and feel specification applied to a resource
Theme: Collection of styles
An Android package
• AndroidManifest.xml
–
–
–
–
•
•
•
•
Lists application activities (user tasks) and services
Lists permissions, and features required by the application
List permissions granted for access by other applications
Lists features used by this application
src: Source Java classes
bin: Compiled Java and Android classes
assets: Arbitrary collection of files and folders
res
– Various resource folders to separate data from application code
– Multimedia, user interface layouts, xml files, data values
abstracted from the application, and raw data
• gen: Java files automatically generated during a build
The Build Process
Android Build Process
R.java
Automatically created
by the build process.
Converts all resource
ids in the res folders
to integer values used
by the application.
Do NOT edit.
Android Applications
Note: Activities originate within APKs
A single APK can spawn multiple processes
Creating an Application
• Define the layouts for an application
– Housed in res/layout
– Use the layout file automatically created when possible
– Edit the xml; the right panel of Studio shows how it looks
• Define the strings, colors, themes, and styles
– These are xml files in res/values
– File name conventions: colors, dimens, strings, and styles
• Wire the layout components to anonymous listeners
using ids declared in layouts
– Layout ids: android:id="@+id/true_button"
– String ids: android:text="@string/hello_world"
Application Design
• Layout: Design the various screens that users see, where each
screen corresponds to single Activity
• Transitions: Design the transitions between views (animations)
• External applications: Determine exposure to other activities
• Security permissions: Decide needed security permissions
• Activities: Design the interface between users and the data model
• Background services: Design mechanisms to exchange data,
listen for connections, and periodically download information from
a server
• Content providers: Design application long-term data storage
requirements, mechanisms for storage, and content providers
providing data access wrappers
• Connections: Determine how activities and services tie together
Activities
• Definitions
– Process: An executing android (Linux) application with a unique PID
running its own Dalvik JVM, having one or more threads
– Task: A stack of bundled Activities, which can span processes
– Activity: A self-contained manifest launchable component whose life
cycle is controlled by the Android OS
– Fragment: An activity launchable module controlling a portion of the
activity’s view whose life cycle is controlled by the activity
• Activities
– Application building block
– In Java, we create an activity by extending the Activity class
– Activities can sometimes be
• Faceless (without a visible UI: Speech Recognition for example)
• Present themselves in a floating window
• Return values to other activities (startActivityForResult)
Activity Life
Cycle
• The Activity class contains
predefined listener
functions that handle
system events
• System events occur when
the activity changes life
cycle states
• Developers override these
methods if they need to
customize event handling
• Event handlers release and
allocate resources, stop
network connections, etc.
Activity Life Cycle
Activity Life
Cycle
Loads into
memory
Note: The Dalvik VM controls the Life cycle, not the application
Activity Rules
• Time consuming tasks MUST be run in separate threads.
The Android OS will terminate the application if heavy
processing is done at the user interface level
• All interactions are asynchronous. In other words the are
initiated, and a listener responds when they are done. An
activity never waits until an interaction is complete
• The Android operating system decides when activities are
stopped, paused, and destroyed. It is up to the activity to
preserve its state when notified of an impending change
• Operations like a rotates cause a relaunch of an activity
Steps to developing an Activity
• Create the Studio Android project
• Define the package name for you
application (ex: com.acorns)
• Edit the manifest file, that
declares activities, intents,
services, content providers, and
and defines required permissions
• Define resources as subfolders of
the res directory.
• Store multimedia components and
other files as assets, raw data, or
drawables
• Edit the class in the project that
extend Activity; create any other
helper classes needed
• Override the onCreate() method to
o Specify a default View for the
Activity.
o Code and register/attach the
handlers that respond to user events
• Override the other predefined methods
as needed
– Release resources on state changes
– Interact with other classes
– Utilize Android system resources
• Determine external activity interactions
– Create content provider interfaces
– Create alternative menus
– Launch activities using intent objects
Activities versus Tasks
Activities
• A class in the Android API
• An encapsulation of a
particular user operation
• Defined within a single APK
• Normally associated with a
single user interface view
• An self-contained execution
context
Tasks
• A bundled stack of activities
• Can span multiple processes
• History stack:
– Stack of activities launched by
the users
– Multiple tasks exist and moved
from foreground to background
(long press on home button)
Android Activity Framework
Activities can interact with
• Content Providers: An activity that provides a uniform
access to data resources. Provides level of abstraction for
stored data, which is accessible by multiple applications
• Alternative Menus: Menu items inserted into an activities
user interface from remote activities
• Services: Background processes not associated with a view.
They run independent of any activity.
• Notifications: The User notification framework enables
signaling users without interrupting their current activity. For
instance flashing lights can indicate an incoming call.
Activity Execution
• An Activity
– Is loaded by the Android OS
– Consists of various callback methods to facilitate Android’s
asynchronous design
• On start up
– A default view (empty screen) is presented to the activity
– The overridden onCreate() method
• Set the top level GUI screen
• Attach listeners to react to user events
• User events can
– trigger changes to the screen view
– interact with application data
– Lunch other activities with intent objects
Intents
• Intents (Android's mechanism for handling inter-process communication)
– Describe what should be done; commonly to launch an activity
– Target specific activities or services or can be a system wide broadcast
– Inform applications of events and alarms
– Initiated either from the system or from user activities
• Activities & Broadcast Receivers
– Define the intents that they can service
– Provide the logic to respond to intents when received
• System: Match an intent with a receiver that can best satisfy the request
• Examples
– Activity events ( launch app possibly with data to process)
– Hardware state changes (acceleration change, screen off, etc.)
– Incoming data (Receiving call)
– Communication between activities (launch with reply expected)
– Initiate Android services: Dialing a number; Sending a text
– Broadcast that an event occurred (network down)
XML Declarations and References
• Layout id declaration and reference
– Declare: android:id="@+id/true_button"
– Reference:
mTrueButton = (Button)findViewById(R.id.true_button);
• String
– Declare: <string name="true_button">true</string>
– Reference in XML: android:text="@string/hello_world"
– Reference in Java: R.string.true_button