Android Tutorial:

Part 2
Creating a TCP/IP Client App
Using the TCP Client Developed in this
Course:

Android OS Development Issues

1
 Outline
1. Permissions

2. UI Thread

3. UI Widget Access by External Thread

4. Android Studio Virtual Network for Development

of Network Based Programs

2
 Outline
1. Permissions

2. UI Thread

3. UI Widget Access by External Thread

4. Android Studio Virtual Network for Development

of Network Based Programs

3
 Our IoT App Needs to Use the
Internet
• Our IoT app needs to use the Internet for TCP/IP
communications.

• Other IoT apps may need to use other resources,

such as Bluetooth, camera, and phone.

• Android policy is that any app that requires using

such resources must obtain permission to do so.

4
Working With System Permissions
• To protect the system’s integrity and the user’s privacy,
Android runs each app in a limited access sandbox.

• If the app wants to use resources or information outside of its

sandbox, the app has to explicitly request permission.

• Depending on the type of permission the app requests, the

system may grant the permission automatically (normal
permissions), or the system may ask the user to grant the
permission (potentially dangerous permissions).

5
• ACCESS_LOCATION_EXTRA_COMMANDS • MODIFY_AUDIO_SETTINGS
• ACCESS_NETWORK_STATE • NFC
• ACCESS_NOTIFICATION_POLICY • READ_SYNC_SETTINGS
• ACCESS_WIFI_STATE • READ_SYNC_STATS
• BLUETOOTH • RECEIVE_BOOT_COMPLETED
•ACCESS_LOCATION_EXTRA_COMMANDS
• BLUETOOTH_ADMIN
•ACCESS_NETWORK_STATE • REORDER_TASKS
•ACCESS_NOTIFICATION_POLICY
••ACCESS_WIFI_STATE
BROADCAST_STICKY • REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
••BLUETOOTH_ADMIN
•BLUETOOTH
CHANGE_NETWORK_STATE • REQUEST_INSTALL_PACKAGES
••CHANGE_NETWORK_STATE
•BROADCAST_STICKY
CHANGE_WIFI_MULTICAST_STATE • SET_ALARM
••CHANGE_WIFI_STATE
CHANGE_WIFI_STATE
•CHANGE_WIFI_MULTICAST_STATE
• SET_TIME_ZONE
••EXPAND_STATUS_BAR
DISABLE_KEYGUARD
•DISABLE_KEYGUARD • SET_WALLPAPER
• EXPAND_STATUS_BAR
•GET_PACKAGE_SIZE • SET_WALLPAPER_HINTS
•INSTALL_SHORTCUT
• GET_PACKAGE_SIZE
•INTERNET • TRANSMIT_IR
•KILL_BACKGROUND_PROCESSES
• INSTALL_SHORTCUT • UNINSTALL_SHORTCUT
• INTERNET • USE_FINGERPRINT
• KILL_BACKGROUND_PROCESSES • VIBRATE
• WAKE_LOCK
• WRITE_SYNC_SETTINGS
6
• READ_CALENDAR • ANSWER_PHONE_CALLS
• WRITE_CALENDAR (must request at runtime)
• CAMERA • READ_CALL_LOG
• CAMERA • WRITE_CALL_LOG
• CONTACTS • ADD_VOICEMAIL
• READ_CONTACTS • USE_SIP
• WRITE_CONTACTS • PROCESS_OUTGOING_CALLS
• GET_ACCOUNTS • BODY_SENSORS
• LOCATION • SEND_SMS
• ACCESS_FINE_LOCATION • RECEIVE_SMS
• ACCESS_COARSE_LOCATION • READ_SMS
• MICROPHONE • RECEIVE_WAP_PUSH
• RECORD_AUDIO • RECEIVE_MMS
• READ_PHONE_STATE • READ_EXTERNAL_STORAGE
• READ_PHONE_NUMBERS • WRITE_EXTERNAL_STORAGE
• CALL_PHONE
7
 Permissions Procedure
• Declaring Permissions

• Requesting Permissions at Run Time

8
 Declaring Permissions
• If an app needs to use resources or information
outside of its own sandbox, the app has to request
the appropriate permission.

• You declare that your app needs a permission by

listing the permission in the App Manifest.

9
 Our IoT App Needs to Use the
Internet
• Our IoT app needs permission to use the Internet (i.e., TCP/IP
communications).

• Permission is obtained by including the following in the

AndroidManifest.xml file of the project.

<uses-permission android:name="android.permission.INTERNET" />

• Since the Internet is a normal permission, the system will grant the
permission automatically.

10
11
12
13
 Outline
1. Permissions

2. UI Thread

3. UI Widget Access by External Thread

4. Android Studio Virtual Network for Development

of Network Based Programs

14
 Android Main Thread Policy
• The main thread of an Android app is the user interface thread.

• The user interface thread runs as a concurrent thread

• The Android OS captures any user action, such as clicks or entering text, and send this information to the
UI concurrent thread.

• When a user selects to do some action, the OS calls the handler for the action, and your software will
perform that action.

• Your software runs in the UI concurrent thread.

• While your code is performing the requested action, any new action a user may request will not be able
to be processed, because your software is still performing the previous action.

• For example, if your app is preforming complex logic method in the main thread, and at the same time
the user presses a button, the Android OS will not be able to call the appropriate button pressed
method until you complete your complex task.

• To prevent this problem, it’s good practice to perform all the tasks that might take a long time in a
separate background thread rather than in the main thread. 15
 The Problem: User Command Concurrent
Thread
<<Command>>
Getting Input From The User
userInput = AndroidOSGetInput
<<startServerSocket>>

User myCommandHandler.handleUserCommand()

• Currently, the time taken to process a server-user command may be Integer.parseInt(theCommand)

relatively a long time: the user might notice and complain that the
interface “seems sluggish”.
myServer.startServer()
• For example, consider a server user selecting the “Start Server”
command on the StandardIO interface.
myClient.clientSocket = new Socket()

• In response the software will temporarily stop interacting with the

user and execute the command, through a “sequence of method
invocations”, called a method trace. myUI.update()

Getting Input From The User

userInput = AndroidOSGetInput

User 16
 the Solution:
Introduce a User Command Handler Concurrent Thread
<<Command>>
Interacting With The User
<<startServerSocket>>
myCommandHandler.handleUserCommand()
User “Start User Command Handler Thread(Command)”

Resume Interacting With The User

User Start Thread

• A solution is to process the Integer.parseInt(theCommand)

command in a different
concurrent thread. User Command myServer.startServer()
Handler Thread:
• In this way, the user interaction Example – start myClient.clientSocket = new Socket()
thread returns to interacting with server socket
the user sooner. myUI.update()

Exit Thread

17
 Outline
1. Permissions

2. UI Thread

3. UI Widget Access by External Thread

4. Android Studio Virtual Network for Development

of Network Based Programs

18
 Android Main Thread Policy
• Problem: Android UI thread policy:

“Only the methods running on the UI thread have access to objects on that thread.”

• Any thread that is not the UI thread will not have access to UI objects.

• For example, when the server sends a message to the client, such as “Hello Client
…”, this message is received by a background thread in the Client class.

• This thread then calls the execute method of the ServerCommandHandler class,
which then calls the update method in the MainActivity class, and, finally, the
update method attempts to gain access to a widget in the UI.

• But, when the update method tries to access the serverMessageTextBox widget,
the app throws an exception, because the update method is part of an external
thread that is not the UI thread: violates the policy.
19
 Solution: Using the Handler Class
• To move data from a background thread to the UI thread, use a Handler that’s running on
the UI thread.

– Place the data (e.g., text message for a text box) in a message queue of the UI thread.

– Create an instance of the Handler object, and override the handleMessage method of
the Handler object to access the widget of interest.

– Now, when the UI thread runs, the thread calls the handleMessage method, and passes
it the next message from the message queue; handleMessage thus performs the action.

– The handleMessage method receives the next message in the message queue. The
handlMessage code should check the type of message passed to determine the widget
to access, but since there is only one destination, i.e., the server message window, there
is no need to determine where the message should go, and the method just sends the
message to the text box.

20
 Solution: Using the Handler Class
Method 1: Implied Widget
public void update(String theString) {

Message msg = new Message();

msg.obj = theString;
msg.setTarget(myServerMessageTextBoxHandler);
myServerMessageTextBoxHandler.sendMessage(msg);
}

@SuppressLint("HandlerLeak")
Handler myServerMessageTextBoxHandler=new Handler() {
@Override
public void handleMessage(Message msg) {
myServerMessageTextBox.append(msg.obj +"\n");
}
};

21
 Solution: Using the Handler Class
Method 2: Custom Widget ID
public void update(String theString) {

ServerMessageTextBoxString = theString;
myServerMessageTextBoxHandler.sendEmptyMessage(7777);
}

Handler myServerMessageTextBoxHandler=new Handler() {

@Override
public void handleMessage(Message msg) {
if(msg.what==7777)
myServerMessageTextBox.append(getServerMessageTextBoxString()+"\n");
}
};

22
 Outline
1. Permissions

2. UI Thread

3. UI Widget Access by External Thread

4. Android Studio Virtual Network for Development

of Network Based Programs

23
• Use NetBeans or command line to start a TCP server on the Development Machine.

• The emulator runs behind a router/firewall that isolates it from your development machine’s
network interfaces.
Android Studio Created Network

10.0.2.* Development
Router/ Internet
Network Machine:
Firewall
TCP Server

Firewall Alias
IP Address: IP Address:
10.0.2.1 10.0.2.2
Emulator:
IP Address: 10.0.2.15
Loopback Address: 127.0.0.1
24
• To contact the server running on the Development Machine, the emulator Client should use
IP Address 10.0.2.2.

• Note that if the emulator Client were to use 127.0.0.1, then it would be trying to contact
itself.

10.0.2.* Development
Router/ Internet
Network Machine:
Firewall
TCP Server

Firewall Alias
IP Address: IP Address:
10.0.2.1 10.0.2.2
Emulator:
IP Address: 10.0.2.15
Loopback Address: 127.0.0.1
25