1

DEBREMARKOS INSTITUTE OF TECHNOLOGY

MOBILE PROGRAMMING

LECTURE 5

PERMISSIONS AND UI DESIGN

Wednesday, March 17, 2021 Wobetu Shiferaw (wobetushiferaw@gmail.com)

 System Permissions
2

 To maintain security for the system and users, Android requires apps to
request permission before the apps can use certain system data and
features.
 Depending on how sensitive the area is, the system may grant the
permission automatically, or it may ask the user to approve the request.
 Note: These permissions are Android permissions; they grant access to
device features.
 Requesting Permissions
3

 Android is a privilege-separated operating system, in which each app runs

with a distinct system identity.
 Linux thereby isolates apps from each other and from the system.
 Apps must explicitly request access to resources and data outside their
sandbox. 
 They request this access by declaring the permissions they need for
additional capabilities not provided by the basic sandbox.
 Requesting Permissions
4

 Depending on how sensitive the area is, the system may grant the
permission automatically, or may prompt the user to approve or reject the
request.
 A basic Android app has no permissions associated with it by default.
 It cannot do anything that would adversely impact the user experience or
any data on the device.
 Requesting Permissions
5

 To make use of protected features of the device, we include one or more

<uses-permissions> tag in the App Manifest

Eg.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>
 Normal and Dangerous Permissions
6

 Permissions are classified as:

 Normal and Dangerous permissions

 Normal Permissions:
 Cover areas where your app needs to access data or resources outside the app's
sandbox,
 But where there's very little risk to the user's privacy or the operation of other
apps. 
 Normal and Dangerous Permissions
7

 Dangerous permissions
 Cover areas where the app wants data or resources that involve the user's
private information,
 Or could potentially affect the user's stored data or the operation of other
apps.
 Eg. Reading users contact information is a dangerous permission

 If your app lists dangerous permissions in its manifest, the system

asks the user to explicitly grant those permissions.
 Requesting Permissions
8

 A particular permission may be enforced at a number of places during your

program's operation:
 At the time of a call into the system, to prevent an app from executing
certain functions.
 When starting an activity, to prevent apps from launching activities of other
apps.
 Requesting Permissions
9

 Both sending and receiving broadcasts, to control who can receive your
broadcast or who can send a broadcast to you.
 When accessing and operating on a content provider.
 Binding to or starting a service.
 Permission Groups
10

 All dangerous Android system permissions belong to permission groups.

Some android Permission Groups
11

…
User Interface Design Overview
 UI Overview
12

 All user interface elements in an app are built using View &
ViewGroup objects
 View: object that draws something on the screen that the use
interacts with
 Buttons, text fields, Checkboxes, RadioButtons etc
 UI Overview
13

 ViewGroup: an invisible object that holds other View / ViewGroup

objects in order to define layout of the interface
 Android provides you a collection of both View and ViewGroup
subclasses and Layout models

 User Interface Layout
14

 The UI component of an app is defined using a hierarchy of view

and ViewGroup objects.
 Declaring or Instantiating a Layout
15

 Either of:
 Instantiate view object with java code
 Define layout in XML file (Recommended and easy way)
 Declaring or Instantiating a Layout
16

 The name of an XML element for a view is respective to the

Android class it represents. So:
 <TextView> creates a TextView widget
 <LinearLayout> creates a LinearLayout view group
 Likewise:
 <Button> for Button widget
 <EditText> for EditText
 Declaring or Instantiating a Layout
17

 <ImageView> for ImageView

 <ListView> for ListView
 <RelativeLayout> for RelativeLayout
 Example: Simple Vertical Layout
18

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:layout_width="fill_parent"
              android:layout_height="fill_parent"
              android:orientation="vertical" >
    <TextView android:id="@+id/text"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="I am a TextView" />
    <Button android:id="@+id/button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="I am a Button" />
</LinearLayout>
 Declaring or Instantiating a Layout
19

 When you load a layout resource in your app, Android initializes

each node of the layout into a runtime object that:
 You can use to define additional behaviors,
 Query the object state,
 Or modify the layout.
 User Interface Components
20

 You don’t have to built all your UI using View and ViewGroup
 Android provides several app components that offer a standard UI
layout
 Each have unique set of APIs
 Eg:
 App Bar
 Dialogs and Notifications etc
 Layouts
21

 Defines a visual structure for a UI

 Declared in two ways:
 Declare UI Elements in an XML
 Instantiate layout elements at runtime

 The android system gives you the flexibility to use either of this
 Layouts
22

 Defines a visual structure for a UI

 Declared in two ways:
 Declare UI Elements in an XML
 Instantiate layout elements at runtime
 The android system gives you the flexibility to use either of this
 Advantage of XML declaration
 Better separation of code and presentation
 Layouts
23

 Ur XMl presentations are external to ur code

 So u can modify ur layout file without affecting the source code
 You can create layout for different screen sizes
 You can create layout for different languages
 Write XML
24

 Using Android's XML vocabulary, you can quickly design UI

layouts and the screen elements they contain, in the same way
you create web pages in HTML.
 Each layout file must contain exactly one root element, which
must be a View or ViewGroup object.
 Once you've defined the root element, you can add additional
layout objects or widgets as child elements
 Write XML
25

<?xml version="1.0" encoding="utf-8"?>



<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:layout_width="match_parent"
              android:layout_height="match_parent"
              android:orientation="vertical" >
    <TextView android:id="@+id/text"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="Hello, I am a TextView" />
    <Button android:id="@+id/button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Hello, I am a Button" />
</LinearLayout>
 Loading XML Resource
26

 You should load the layout resource from your application code
 In your Activity.onCreate() callback implementation.
 Do so by calling setContentView(), passing in the reference to your
layout resource in the form of: R.layout.layout_file_name.
 Loading XML Resource
27

 Eg. if your XML layout is saved as main_layout.xml, you would

load it for your Activity like so:

public void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);
    setContentView(R.layout.main_layout);
}
 Loading XML Resource
28

 The onCreate() callback method in your Activity is called by the

Android framework when your Activity is launched
 Attributes
29

 Every View and ViewGroup object supports their own variety of

XML attributes.
 Some attributes are specific to a particular View object
 While others are common to all View objects, Coz they are
inherited from the parent View class (id attribute)
 Attributes
30

 Any View object may have an integer id associated with, to

uniquely identify the View within the tree
 When compiled, it referenced as integer, but the ID is assigned in
XML as a string in the id attribute
 This is an attribute common to all View objects
 Syntax: android:id="@+id/my_button"
 Attributes
31

 In order to create views and reference them from the application,

a common pattern is to:
1. Define a View / widget in the layout file and assign it a unique ID
<Button android:id="@+id/my_button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/my_button_text"/>
 Attributes
32

2. Then create an instance of the view object and capture it from

the layout (typically in the onCreate() method):
Button myButton = (Button) findViewById(R.id.my_button);
 Attributes
33

 Defining IDs for view objects is important when creating

a RelativeLayout.
 Sibling views can define their layout relative to another sibling view,
which is referenced by the unique ID.
 Attributes
34

 An ID need not be unique throughout the entire tree, but it should be

unique within the part of the tree you are searching
 Layout Parameters
35

 Layout attributes named layout_something define layout parameters

for the View that are appropriate for the ViewGroup in which it resides.
 Every ViewGroup class implements a nested class that
extends ViewGroup.LayoutParams.
 This subclass contains property types that define the size and position
for each child view
 Layout Parameters
36
 Layout Parameters
37

 Every LayoutParams subclass has its own syntax for setting

values.
 Each child element must define LayoutParams that are
appropriate for its parent
 Though it may also define different LayoutParams for its own
children.
 Layout Parameters
38

 All view groups include a width and height

(layout_width and layout_height), and each view is required to
define them.
 LayoutParams also include optional margins and borders.
 You can specify width and height with exact measurements,
though you probably won't want to do this often.
 Layout Parameters
39

 Or use relative measurement values (recommended):

 wrap_content tells your view to size itself to the dimensions required by its
content.
 match_parent tells your view to become as big as its parent view group
will allow
 Setting absolute value measurements such as pixels not
recommended.
 Instead we use dp, wrap_content, mathch_parent etc,
 Layout Parameters
40

 It helps for ur app to display different screen sizes

 Common Layouts
41

LinearLayout RelativeLayout WebView

 u !
42

Yo
n k
h a