1. BASICS
Smartphone Programming (CPE 490/590)
Michael T. Shrove

2. ANDROID

3. Fundamentals
• Android application are written in Java
• Android SDK tools compile the code in an .apk
file
• Resources
• Data
• Code
• APK file are what android powered device use

4. Android App Security
• Once installed all apps live in their own “sandbox”
• The Android operating system is a multi-user Linux
system in which each app is a different user.
• By default, the system assigns each app a unique Linux
user ID. The system sets permissions for all the files in an
app so that only the user ID assigned to that app can
access them.
• Each process has its own virtual machine (VM), so an
app's code runs in isolation from other apps.
• By default, every app runs in its own Linux process.

5. Android App Security++
• In this way, the Android system implements the principle
of least privilege. That is, each app, by default, has
access only to the components that it requires to do its
work and no more.
• However, there are ways for an app to share data with other apps
and for an app to access system services:
• An app can request permission to access device data
such as the user's contacts, SMS messages, the
mountable storage (SD card), camera, Bluetooth, and
more.
• All app permissions must be granted by the user at install
time.

6. App Components
App
Activities
Content
Providers
Services
Broadcast
Receivers
• App components are the
essential building blocks of
an Android app.
• Each component is a
different point through which
the system can enter your
app.
• Not all components are
actual entry points for the
user and some depend on
each other, but each one
exists as its own entity and
plays a specific role
• Each one is a unique building
block that helps define your
app's overall behavior.

7. Activities
• An activity represents a single
screen with a user interface.
• For example, an email app might have
one activity that shows a list of new
emails, another activity to compose an
email, and another activity for reading
emails.
• Although the activities work together
to form a cohesive user experience
in the email app, each one is
independent of the others.
• As such, a different app can start
any one of these activities (if the
email app allows it).
• For example, a camera app can start
the activity in the email app that
composes new mail, in order for the
user to share a picture.
• An activity is implemented as a
subclass of Activity
App
Activities
Content
Providers
Services
Broadcast
Receivers

8. Services
• A service 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.
• For example, a service might play
music in the background while the
user is in a different app, or it might
fetch data over the network without
blocking user interaction with an
activity.
• Another component, such as an activity,
can start the service and let it run or
bind to it in order to interact with it.
• A service is implemented as a subclass
of Service
App
Activities
Content
Providers
Services
Broadcast
Receivers

9. Content Providers
• A content provider manages a shared
set of app data.
• SQLite database, Web, Persistent storage
location your app can access.
• Through the content provider, other
apps can query or even modify the data.
• For example, the Android system provides a
content provider that manages the user's contact
information.
• Content providers are also
useful for reading and writing
data that is private to your app
and not shared.
• For example, the Note Pad sample app uses a
content provider to save notes.
• A content provider is implemented as a
subclass of ContentProvider and must
implement a standard set of APIs that
enable other apps to perform
transactions.
App
Activities
Content
Providers
Services
Broadcast
Receivers

10. Broadcast Receivers
• A broadcast receiver is a component that
responds to system-wide broadcast
announcements.
• Many broadcasts originate from the
system.
• For example, a broadcast announcing that the screen
has turned off, the battery is low, or a picture was
captured.
• Apps can also initiate broadcasts.
• For example, to let other apps know that some data
has been downloaded to the device and is available
for them to use.
• Although broadcast receivers don't display
a user interface, they may create a status
bar notification to alert the user when a
broadcast event occurs.
• More commonly, though, a broadcast
receiver is just a "gateway" to other
components and is intended to do a very
minimal amount of work.
• For instance, it might initiate a service to perform some
work based on the event.
• A broadcast receiver is implemented as a
subclass of BroadcastReceiver and each
broadcast is delivered as an Intent object.
App
Activities
Content
Providers
Services
Broadcast
Receivers

11. Intents
• Three of the four component types—activities, services,
and broadcast receivers—are activated by an
asynchronous message called an intent.
• An intent is created with an Intent object, which defines a
message to activate either a specific component or a
specific type of component—an intent can be either
explicit or implicit, respectively.
• The other component type, content provider, is not
activated by intents. Rather, it is activated when targeted
by a request from a ContentResolver.

12. Methods for Starting Components
• There are separate methods for activating each type of
component:
• You can start an activity (or give it something new to do) by passing
an Intent to startActivity() or startActivityForResult() (when you
want the activity to return a result).
• You can start a service (or give new instructions to an ongoing
service) by passing an Intent to startService(). Or you can bind to
the service by passing an Intent to bindService().
• You can initiate a broadcast by passing an Intent to methods like
sendBroadcast(), sendOrderedBroadcast(), or
sendStickyBroadcast().
• You can perform a query to a content provider by calling query() on
a ContentResolver.

13. Manifest File
• Before the Android system can start an app component,
the system must know that the component exists by
reading the app's AndroidManifest.xml file (the "manifest"
file).
• Your app must declare all its components in this file,
which must be at the root of the app project directory.
• The manifest does a number of things in addition to
declaring the app's components, such as:
• User Permissions
• Minimum API Level required by the app
• Declare hardware and software features used or required by the
app
• API libraries the app needs to be linked against

14. Intent Filters
• Specifies the types of intents that an activity, service, or
broadcast receiver can respond to. An intent filter
declares the capabilities of its parent component — what
an activity or service can do and what types of broadcasts
a receiver can handle. It opens the component to
receiving intents of the advertised type, while filtering out
those that are not meaningful for the component.

15. App Requirements
• There are a variety of devices powered by Android and
not all of them provide the same features and capabilities.
• In order to prevent your app from being installed on
devices that lack features needed by your app, it's
important that you clearly define a profile for the types of
devices your app supports by declaring device and
software requirements in your manifest file.

16. App Resources
• An Android app is composed of more than just code
• It requires resources that are separate from the source
code.
• images,
• audio files
• anything relating to the visual presentation of the app.
• For every resource that you include in your Android
project, the SDK build tools define a unique integer ID,
which you can use to reference the resource from your
app code or from other resources defined in XML.
• res/layout/activity2.xml ------> R.id.Activity2

17. Activities

18. What is an Activity?
• An Activity is an application component that provides a
screen with which users can interact in order to do
something, such as dial the phone, take a photo, send an
email, or view a map.
• Each activity is given a window in which to draw its user
interface. The window typically fills the screen, but may be
smaller than the screen and float on top of other windows.
• Apps usual consist of multiple Activities

19. Activity Lifecycle

21. Managing the Activity Lifecycle
App
Resumed
PausedStopped
• Managing the lifecycle of
your activities by
implementing callback
methods is crucial to
developing a strong and
flexible application.
• An activity can exist in
essentially three states:
• Resumed, Paused,
Stopped

22. Lifecycle States
• Resumed
• The activity is in the foreground of the screen and has user focus.
(This state is also sometimes referred to as "running".)
• Paused
• Another activity is in the foreground and has focus, but this one is
still visible. That is, another activity is visible on top of this one and
that activity is partially transparent or doesn't cover the entire
screen.
• Stopped
• The activity is completely obscured by another activity (the activity
is now in the "background"). A stopped activity is also still alive (the
Activity object is retained in memory, it maintains all state and
member information, but is not attached to the window manager).
However, it is no longer visible to the user and it can be killed by
the system when memory is needed elsewhere.

23. Implementing the lifecycle callbacks
• When an activity transitions into and out of the different
states described above, it is notified through various
callback methods.
• All of the callback methods are hooks that you can
override to do appropriate work when the state of your
activity changes.
• Activity must have onCreate() callback by default.

24. Lifecycle Callback

25. States
Name Description
onCreate Called when the activity is first created.
onRestart Called after the activity has been stopped, just prior to it being
started again. Always followed by onStart()
onStart Called just before the activity becomes visible to the user. Followed
by onResume() if the activity comes to the foreground, or onStop()
if it becomes hidden.
onResume Called just before the activity starts interacting with the user. At this
point the activity is at the top of the activity stack, with user input
going to it. Always followed by onPause().
onPause Called when the system is about to start resuming another activity.
Followed either by onResume() if the activity returns back to the
front, or by onStop() if it becomes invisible to the user.
onStop Called when the activity is no longer visible to the user. Followed
either by onRestart() if the activity is coming back to interact with
the user, or by onDestroy() if this activity is going away.
onDestroy Called before the activity is destroyed. This is the final call that the
activity will receive.

26. Activity and the UI
• The Activity class takes care of creating a window for you
in which you can place your UI with setContentView().
• In code, an activity is a Java class, that extends the
Activity base class.
• The activity class loads its UI components using the XML
file defined in your res/layout folder.
• Every activity you have in your app, must be declared in
your AndroidManifest.xml file.

27. Starting Activities
• The startActivity( ) method invokes another activity but
does not return a result to the current activity.
Activity #1 Activity #2
Intent

28. Starting Activities
• Sometimes, you might want to receive a result from the
activity that you start. In that case, start the activity by
calling startActivityForResult() (instead of startActivity())
Activity #1 Activity #2
Intent
Data

29. Sending Results back
• In your SecondActivity set the data which you want to
return back to FirstActivity. If you don't want to return
back, don't set any.
• If you don't want to return data:

30. Receiving the results
• If you want to receive the results after Activity2 sends it
back using an Intent, you implement the
onActivityResult() method.

31. Activity Example
• Creating a new activity
• Adding Lifecycle Callbacks
• Starting an Activity
• Starting an Activity for Results

32. IOS

33. App Architecture
App
Model
ViewController

34. Model-View-Controller (MVC)
• The Model-View-Controller
(MVC) design pattern assigns
objects in an application one of
three roles: model, view, or
controller.
• The pattern defines not only the
roles objects play in the
application, it defines the way
objects communicate with each
other.
• Each of the three types of
objects is separated from the
others by abstract boundaries
and communicates with objects
of the other types across those
boundaries.

35. MVC
• MVC is central to a good design for a Cocoa application.
• The benefits of adopting this pattern are numerous.
• Many objects in these applications tend to be more reusable, and
their interfaces tend to be better defined.
• Applications having an MVC design are also more easily extensible
than other applications.
• Moreover, many Cocoa technologies and architectures
are based on MVC and require that your custom objects
play one of the MVC roles.

36. Model Objects
• Model objects encapsulate the data specific to an
application and define the logic and computation that
manipulate and process that data.
• For example, a model object might represent a character in a game
or a contact in an address book.
• A model object can have to-one and to-many relationships
with other model objects, and so sometimes the model
layer of an application effectively is one or more object
graphs.
• Much of the data that is part of the persistent state of the
application (whether that persistent state is stored in files
or databases) should reside in the model objects after the
data is loaded into the application.

37. Model Objects
• Ideally, a model object should have no explicit connection
to the view objects that present its data and allow users to
edit that data—it should not be concerned with user-
interface and presentation issues.
• Communication: User actions in the view layer that
create or modify data are communicated through a
controller object and result in the creation or updating of a
model object.
• When a model object changes (for example, new data is
received over a network connection), it notifies a
controller object, which updates the appropriate view
objects.

38. MVC

39. View Objects
• A view object is an object in an application that users can see.
• A view object knows how to draw itself and can respond to user
actions.
• A major purpose of view objects is to display data from the
application’s model objects and to enable the editing of that
data.
• Despite this, view objects are typically decoupled from model
objects in an MVC application.
• Both the UIKit and AppKit frameworks provide collections of
view classes, and Interface Builder offers dozens of view
objects in its Library.
• Communication: View objects learn about changes in model
data through the application’s controller objects and
communicate user-initiated changes
• For example: text entered in a text field—through controller objects to
an application’s model objects.

40. MVC

41. Controller Objects
• A controller object acts as an intermediary between one or
more of an application’s view objects and one or more of its
model objects.
• Controller objects are thus a conduit through which view
objects learn about changes in model objects and vice versa.
• Controller objects can also perform setup and coordinating
tasks for an application and manage the life cycles of other
objects.
• Communication: A controller object interprets user actions
made in view objects and communicates new or changed data
to the model layer.
• When model objects change, a controller object communicates
that new model data to the view objects so that they can
display it.

42. MVC

43. Application Lifecycle

44. Execution States for Apps
• At any given moment, your app is in one of the states
listed in the next table.
• The system moves your app from state to state in
response to actions happening throughout the system.
• For example, when the user presses the Home button, a
phone call comes in, or any of several other interruptions
occurs, the currently running apps change state in
response.

45. App States
State Description
Not Running The app has not been launched or was running but was terminated by the
system.
Inactive The app is running in the foreground but is currently not receiving events. (It
may be executing other code though.) An app usually stays in this state only
briefly as it transitions to a different state.
Active The app is running in the foreground and is receiving events. This is the
normal mode for foreground apps.
Background The app is in the background and executing code. Most apps enter this state
briefly on their way to being suspended. However, an app that requests extra
execution time may remain in this state for a period of time. In addition, an
app being launched directly into the background enters this state instead of
the inactive state.
Suspended The app is in the background but is not executing code. The system moves
apps to this state automatically and does not notify them before doing so.
While suspended, an app remains in memory but does not execute any
code.
When a low-memory condition occurs, the system may purge suspended
apps without notice to make more space for the foreground app.

46. State Delegates
• Most state transitions are accompanied by a
corresponding call to the methods of your app delegate
object.
• These methods are your chance to respond to state
changes in an appropriate way.
• These methods are listed below, along with a summary of
how you might use them.

47. State Delegates Table
Delegate Description
application:willFinishLaunchingWithOptio
ns
This method is your app’s first chance to execute code at
launch time.
application:didFinishLaunchingWithOptio
ns
This method allows you to perform any final initialization
before your app is displayed to the user.
applicationDidBecomeActive Lets your app know that it is about to become the
foreground app. Use this method for any last minute
preparation.
applicationWillResignActive Lets you know that your app is transitioning away from
being the foreground app. Use this method to put your app
into a quiescent state.
applicationDidEnterBackground Lets you know that your app is now running in the
background and may be suspended at any time.
applicationWillEnterForeground Lets you know that your app is moving out of the
background and back into the foreground, but that it is not
yet active.
applicationWillTerminate Lets you know that your app is being terminated. This
method is not called if your app is suspended.

48. App Termination
• Apps must be prepared for termination to happen at any
time and should not wait to save user data or perform
other critical tasks.
• System-initiated termination is a normal part of an app’s
life cycle.
• The system usually terminates apps so that it can reclaim
memory and make room for other apps being launched by
the user, but the system may also terminate apps that are
misbehaving or not responding to events in a timely
manner.

49. App Termination
• Suspended apps receive no notification when they are
terminated; the system kills the process and reclaims the
corresponding memory.
• If an app is currently running in the background and not
suspended, the system calls the applicationWillTerminate: of
its app delegate prior to termination.
• The system does not call this method when the device reboots.
• In addition to the system terminating your app, the user can
terminate your app explicitly using the multitasking UI.
• User-initiated termination has the same effect as terminating a
suspended app.
• The app’s process is killed and no notification is sent to the
app.

50. Starting ViewController
• 2 methods for starting a viewcontroller from another
viewcontroller.
• Method #1: Use built in Storyboard connection (example
will be shown in class)
• Method #2: By Code (shown in Figure 1)
Figure 1

51. Passing Data between ViewControllers
• Since there are two methods for starting a viewcontroller,
there is likewise two methods for passing data from VC to
VC.
• Method #1: Pass data from VC to VC using method #2 of
“Starting ViewController” and use the VC’s properties.
• Method #2: Pass data from VC to VC using method #1 of
“Starting ViewController” slide but add prepareForSegue
method.

52. iOS Examples
• Storyboard
• Adding ViewControllers and Views
• Presenting ViewControllers
• Passing Data

53. References
• https://developer.android.com/guide
• https://developer.apple.com