1
M.Sc C.S - I
SEM II
Journal
Roll No.
022
Name
Prajapati Yash Vausdeo
Subject
Advance Operating System
Subject Code
TPGCSP201
2
CERTIFICATE
This is here to certify that Mr. Prajapati Yash Vasudeo Seat
Number 022 of M.Sc. I Computer Science, has satisfactorily
completed the required number of experiments
prescribed by the THAKUR COLLEGE OF SCIENCE &
COMMERCE AUTONOMOUS COLLEGE, PERMANENTLY
AFFILIATED TO UNIVERSITY OF MUMBAI during the
academic year 2021 – 2022.
Date: 18-04-2022
Place: Mumbai
Teacher In-Charge
External Examiner
Head of Department
3
INDEX
Sr.
No.
Experiments
Page
No
1
Write a Program to send and receive message
from a client and server.
4
2
Write a Program to Demonstrate working of
threads.
8
3
Port 17 is known as the ‘Quote of the day service’. When a client
connects to port 17 on a server, the server responds with a quote
for that day. Write a server program so that it delivers a quote of
the day. Write the client code used to read the quotes returned by
the server.
12
4
Write a client–server application using Java sockets that allows a
client to write a message (as a String) to a socket. The client can
obtain the String message that it is to pass to the server either from
the command line or by using a prompt to the user.
15
5
Write a Java program that simulates the following
disk-scheduling algorithms. Design separate
classes that implement the following scheduling
algorithms:
a. FCFS b. SSTF c. SCAN d. C-SCAN d. LOOK
6
7
Write a Program in java to demonstrate Paging.
Write a program that implements the FIFO and
LRU page-replacement algorithms
19
28
34
8
Using Worker thread write Android code for a click
listener that downloads an image from a separate
thread and displays it in an ImageView.
41
9
Write Android activity that includes each of the
fundamental lifecycle methods.
47
10
Write Android application to demonstrate data
storage.
52
Date
Sign
4
Practical No. 1
Aim:
Write a Program to send and receive message from a client and server.
Theory:
The Client/Server Model
The term "client/server" describes a type of distributed processing in which an application is
divided into two parts, each possibly residing on separate operating systems, but working
together to provide a service to the end user. As shown in Figure 1, one part of the application,
the client, typically resides on a workstation and requests a service for the end-user. The other
part of the application, the server, usually resides on a larger machine, such as a mainframe
computer. The server program uses the resources of the mainframe computer to perform
services requested by each client.
Figure 1. The Client/Server Computing Environment
Depending on how it is designed, a server can process requests from multiple clients
concurrently. Generally, there is one server for many clients.
The client is usually the part of the application that is "seen" by the end-user. Therefore, the
client half of a client/server application most often resides on a workstation, where the end-user
can interact with the application through the workstation operating system's graphical user
interface.
5
Servers, on the other hand, are usually transparent to the end-user. That is, the person who sits
at the workstation only perceives the client half of the application, the part that displays the
information (though it was actually retrieved by a remote server). Because there is only one
server for a given set of clients, servers provide an ideal way of managing shared access to
system resources, such as data sets. For this reason, servers are likely to reside on larger
machines such as z/OS mainframe computers.
Usually, the same person writes both the client and server parts of a client/server application.
Code:
Client.java
import java.io.*;
import java.net.*;
class Client
{
public static void main(String[] args) throws Exception
{
InputStreamReader isr= new InputStreamReader(System.in);
BufferedReader keyboard= new BufferedReader(isr);
Socket s= new Socket("localhost",2222);
BufferedReader br1= new BufferedReader(new
InputStreamReader(s.getInputStream()));
PrintWriter pw=new PrintWriter((s.getOutputStream()));
while(true){
System.out.println("Enter Send/Quit/Receive");
String k=keyboard.readLine();
switch(k.charAt(0))
{
case 'S':
case 's': String sendmsg =keyboard.readLine();
pw.println(sendmsg);pw.flush();break;
case 'R':
case 'r': String recvmsg =br1.readLine();
System.out.println(recvmsg);break;
case 'Q':
case 'q': System.exit(0);
}
}
}
}
6
Servers.java
import java.io.*;
import java.net.*;
class Server
{
public static void main(String[] args) throws Exception
{
ServerSocket ss= new ServerSocket(2222);
Socket s= ss.accept();
InputStreamReader isr= new InputStreamReader(System.in);
BufferedReader keyboard= new BufferedReader(isr);
BufferedReader br1= new BufferedReader(new
InputStreamReader(s.getInputStream()));
PrintWriter pw=new PrintWriter((s.getOutputStream()));
while(true){
System.out.println("Enter Send/Quit/Receive");
String k=keyboard.readLine();
switch(k.charAt(0))
{
case 'S':
case 's': String sendmsg =keyboard.readLine();
pw.println(sendmsg);pw.flush();break;
case 'R':
case 'r': String recvmsg =br1.readLine();
System.out.println(recvmsg);break;
case 'Q':
case 'q': System.exit(0);
}
}
}
}
Output:
7
Conclusion:
Successfully demonstrated a client server program to send and receive a message.
8
Practical No. 2
Aim:
Write a Program to Demonstrate working of threads.
Theory:
What is a Thread in Java?
A thread in Java is the direction or path that is taken while a program is being executed.
Generally, all the programs have at least one thread, known as the main thread, that is provided
by the JVM or Java Virtual Machine at the starting of the program’s execution. At this point,
when the main thread is provided, the main() method is invoked by the main thread.
A thread is critical in the program because it enables multiple operations to take place within a
single method. Each thread in the program often has its own program counter, stack, and local
variable.
Creating a Thread in Java
A thread in Java can be created in the following two ways:
•
Extending java.lang.Thread class
In this case, a thread is created by a new class that extends the Thread class, creating an instance
of that class. The run() method includes the functionality that is supposed to be implemented by
the Thread.
Below is an example to create a thread by extending java.lang.Thread class.
9
Here, start() is used to create a new thread and to make it runnable. The new thread begins
inside the void run() method.
•
Implementing Runnable interface
This is the easy method to create a thread among the two. In this case, a class is created to
implement the runnable interface and then the run() method.
The code for executing the Thread should always be written inside the run() method.
Here's a code to make you understand it.
10
The start() method is used to call the void run() method. When start() is called, a new stack is
given to the thread, and run() is invoked to introduce a new thread in the program.
Code:
class
{
ABC
synchronized void print()
{
int a=0;
System.out.println("hi");
System.out.println("I");
System.out.println("am");
++a;
try{
Thread.sleep(500);
}
catch(Exception e)
{
}
System.out.println("Learning"+a);
System.out.println("Java");
}
}
class myprog extends Thread
{ ABC ob1;
myprog(ABC ob)
{
11
ob1=ob;
}
public void run()
{
ob1.print();
}
}
class mainprog
{
public static void main(String args[])
{
ABC ob = new ABC();
myprog t1=new myprog(ob);
myprog t2=new myprog(ob);
t1.start();
t2.start();
}
}
Output:
Conclusion:
Successfully demonstrated threads in java.
12
Practical No. 3
Aim:
Port 17 is known as the ‘Quote of the day service’. When a client connects to port 17 on a
server, the server responds with a quote for that day. Write a server program so that it delivers a
quote of the day. The quotes should be printable ASCII characters and should contain fewer than
512 characters, although multiple lines are allowed. Since port 17 is considered well known and
therefore unavailable, have your server listen to port 6017. Write the client code used to read the
quotes returned by the server.
Theory:
The term "client/server" describes a type of distributed processing in which an application is
divided into two parts, each possibly residing on separate operating systems, but working
together to provide a service to the end user. As shown in Figure 1, one part of the application,
the client, typically resides on a workstation and requests a service for the end-user. The other
part of the application, the server, usually resides on a larger machine, such as a mainframe
computer. The server program uses the resources of the mainframe computer to perform
services requested by each client.
The client is usually the part of the application that is "seen" by the end-user. Therefore, the
client half of a client/server application most often resides on a workstation, where the end-user
can interact with the application through the workstation operating system's graphical user
interface.
Servers, on the other hand, are usually transparent to the end-user. That is, the person who sits
at the workstation only perceives the client half of the application, the part that displays the
information (though it was actually retrieved by a remote server). Because there is only one
server for a given set of clients, servers provide an ideal way of managing shared access to
system resources, such as data sets. For this reason, servers are likely to reside on larger
machines such as z/OS mainframe computers.
Usually, the same person writes both the client and server parts of a client/server application.
Code:
Server1.java
package server1;
import java.net.*;
import java.io.*;
import java.util.*;
13
public class Server1 {
public static void main(String[] args) {
try {
String Quote = null;
Calendar c = Calendar.getInstance();
Date date = new Date();
c.setTime(date);
int dayOfWeek = c.get(Calendar.DAY_OF_WEEK);
switch (dayOfWeek) {
//sunday
case 1:
Quote = "ITS SUNDAY";
break;
//monday
case 2:
Quote = "ITS MONDAY";
break;
//tuesday
case 3:
Quote = "ITS TUESDAY";
break;
//wednesday
case 4:
Quote = "ITS WEDNESDAY";
break;
//thursday
case 5:
Quote = "ITS THURSDAY";
break;
//friday
case 6:
Quote = "ITS FRIDAY";
break;
//saturday
case 7:
Quote = "ITS SATURDAY";
break;
default:
Quote = "NO WEEK DAY";
break;
}
ServerSocket sock = new ServerSocket(6017);
// now listen for connections
while (true) {
Socket client = sock.accept();
// we have a connection
PrintWriter pout = new PrintWriter(client.getOutputStream(), true);
pout.println("Quote of the day service");
pout.println("Yash Prajapati - 022");
// write the Quote to the socket
if (Quote.length() <= 512) {
pout.println(Quote);
} else {
pout.println("More than 512 characters");
}
client.close();
}
14
} catch (IOException ioe) {
System.err.println(ioe);
}
}
}
Client1.java
package client1;
import java.net.*;
import java.io.*;
public class Client1 {
public static void main(String[] args) throws IOException {
InputStream in = null;
BufferedReader bin = null;
Socket sock = null;
try {
sock = new Socket("127.0.0.1", 6017);
in = sock.getInputStream();
bin = new BufferedReader(new InputStreamReader(in));
String line;
while ((line = bin.readLine()) != null) {
System.out.println(line);
}
} catch (IOException ioe) {
System.err.println(ioe);
} finally {
try {
sock.close();
} catch (Exception e) {
System.out.println(e.getMessage());
}
}
}
}
Output:
15
Conclusion:
Successfully demonstrated a client server program for quote of the day service.
Practical No. 4
Aim:
Write a client–server application using Java sockets that allows a client to write a message (as
a String) to a socket. A server will read this message, count the number of characters and digits
in the message, and send these two counts back to the client. The server will listen to port 6100.
The client can obtain the String message that it is to pass to the server either from the command
line or by using a prompt to the user. One strategy for sending the two counts back to the client
is for the server to construct an object containing:
1. The message it receives from the client
2. A count of the number of characters in the message
3. A count of the number of digits in the message.
Theory:
The term "client/server" describes a type of distributed processing in which an application is
divided into two parts, each possibly residing on separate operating systems, but working
together to provide a service to the end user. As shown in Figure 1, one part of the application,
the client, typically resides on a workstation and requests a service for the end-user. The other
part of the application, the server, usually resides on a larger machine, such as a mainframe
computer. The server program uses the resources of the mainframe computer to perform
services requested by each client.
Depending on how it is designed, a server can process requests from multiple clients
concurrently. Generally, there is one server for many clients.
The client is usually the part of the application that is "seen" by the end-user. Therefore, the
client half of a client/server application most often resides on a workstation, where the end-user
can interact with the application through the workstation operating system's graphical user
interface.
Servers, on the other hand, are usually transparent to the end-user. That is, the person who sits
at the workstation only perceives the client half of the application, the part that displays the
information (though it was actually retrieved by a remote server). Because there is only one
server for a given set of clients, servers provide an ideal way of managing shared access to
system resources, such as data sets. For this reason, servers are likely to reside on larger
machines such as z/OS mainframe computers.
16
Usually, the same person writes both the client and server parts of a client/server application.
Code:
Server2.java
package server2;
import java.net.*;
import java.io.*;
public class Server2 {
private static Socket socket;
public static void main(String[] args) {
try {
int port = 6102;
ServerSocket serverSocket = new ServerSocket(port);
System.out.println("Server Started and listening to the port 6102");
//Server is running always. This is done using this while(true) loop
while (true) {
//Reading the message from the client
socket = serverSocket.accept();
InputStream is = socket.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String msg = br.readLine();
System.out.println("Message received from Yash Prajapati - 022 Client is " + msg);
String returnMessage = "";
try {
int d = 0;
int v = 0;
for (int i = 0; i < msg.length(); ++i) {
char k = msg.charAt(i);
if (k >= '0' && k <= '9') {
d++;
} else if (k == 'a' || k == 'e' || k == 'i' || k == 'o' || k == 'u') {
v++;
}
}
String ans = "No.of characters = " + msg.length() + "; No. of vovels = " + v +
"; No.of digits= " + d;
returnMessage = String.valueOf(ans) + "\n";
} catch (Exception e) {
}
//Sending the response back to the client.
OutputStream os = socket.getOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(os);
BufferedWriter bw = new BufferedWriter(osw);
bw.write(returnMessage);
System.out.println("Message sent to the client is " + returnMessage);
bw.flush();
17
}
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
socket.close();
} catch (Exception e) {
}
}
}
}
Client2.java
package client2;
import java.net.*;
import java.io.*;
public class Client2
{
private static Socket socket;
public static void main(String args[])
{
try
{
String host = "localhost";
int port = 6102;
InetAddress address = InetAddress.getByName(host);
socket = new Socket(address, port);
//Send the message to the server
OutputStream os = socket.getOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(os);
BufferedWriter bw = new BufferedWriter(osw);
String msg = "Computer Science 2022";
String sendMessage = msg + "\n";
bw.write(sendMessage);
bw.flush();
System.out.println("Message sent to the server : "+sendMessage);
//Get the return message from the server
InputStream is = socket.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String message = br.readLine();
System.out.println("Message received from Yash Prajapati - 022 the server : " +message);
}
catch (Exception exception)
{
exception.printStackTrace();
}
finally
{
//Closing the socket
try
18
{
socket.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
}
Output:
Conclusion:
Successfully demonstrated a client server program to send and receive message.
19
Practical No. 5
Aim:
Write a Java program that simulates the following disk-scheduling algorithms. Design
separate classes that implement the following scheduling algorithms:
a. FCFS
b. SSTF
c. SCAN
d. C-SCAN
e. LOOK
Theory:
Disk scheduling is done by operating systems to schedule I/O requests arriving for the disk.
Disk scheduling is also known as I/O scheduling.
Disk scheduling is important because:
•
Multiple I/O requests may arrive by different processes and only one I/O request
can be served at a time by the disk controller. Thus other I/O requests need to wait
in the waiting queue and need to be scheduled.
• Two or more request may be far from each other so can result in greater disk arm
movement.
• Hard drives are one of the slowest parts of the computer system and thus need to
be accessed in an efficient manner.
There are many Disk Scheduling Algorithms but before discussing them let’s have a quick look
at some of the important terms:
•
•
•
•
Seek Time: Seek time is the time taken to locate the disk arm to a specified track
where the data is to be read or write. So the disk scheduling algorithm that gives
minimum average seek time is better.
Rotational Latency: Rotational Latency is the time taken by the desired sector of
disk to rotate into a position so that it can access the read/write heads. So the disk
scheduling algorithm that gives minimum rotational latency is better.
Transfer Time: Transfer time is the time to transfer the data. It depends on the
rotating speed of the disk and number of bytes to be transferred.
Disk Access Time: Disk Access Time is:
20
Disk Access Time = Seek Time +
Rotational Latency +
Transfer Time
Disk Response Time: Response Time is the average of time spent by a request
waiting to perform its I/O operation. Average Response time is the response time of
the all requests. Variance Response Time is measure of how individual request are
serviced with respect to average response time. So the disk scheduling algorithm
that gives minimum variance response time is better.
Disk Scheduling Algorithms
1.
FCFS: FCFS is the simplest of all the Disk Scheduling Algorithms. In FCFS, the requests are addressed in
the order they arrive in the disk queue.Let us understand this with the help of an example.
Example:
1. Suppose the order of request is- (82,170,43,140,24,16,190)
And current position of Read/Write head is : 50
21
So, total seek time:
=(82-50)+(170-82)+(170-43)+(140-43)+(140-24)+(24-16)+(190-16)
=642
Advantages:
•
•
Every request gets a fair chance
No indefinite postponement
Disadvantages:
•
•
Does not try to optimize seek time
May not provide the best possible service
SSTF: In SSTF (Shortest Seek Time First), requests having shortest seek time are executed first. So, the
seek time of every request is calculated in advance in the queue and then they are scheduled according
to their calculated seek time. As a result, the request near the disk arm will get executed first. SSTF is
certainly an improvement over FCFS as it decreases the average response time and increases the
throughput of system. Let us understand this with the help of an example.
Example:
1. Suppose the order of request is- (82,170,43,140,24,16,190)
And current position of Read/Write head is : 50
22
So, total seek time:
=(50-43)+(43-24)+(24-16)+(82-16)+(140-82)+(170-140)+(190-170)
=208
Advantages:
•
•
Average Response Time decreases
Throughput increases
Disadvantages:
•
•
•
Overhead to calculate seek time in advance
Can cause Starvation for a request if it has higher seek time as compared to
incoming requests
High variance of response time as SSTF favours only some requests
SCAN: In SCAN algorithm the disk arm moves into a particular direction and services the
requests coming in its path and after reaching the end of disk, it reverses its direction and
again services the request arriving in its path. So, this algorithm works as an elevator and
hence also known as elevator algorithm. As a result, the requests at the midrange are serviced
more and those arriving behind the disk arm will have to wait.
Example:
1. Suppose the requests to be addressed are-82,170,43,140,24,16,190. And the
Read/Write arm is at 50, and it is also given that the disk arm should move “towards
the larger value”.
23
Therefore, the seek time is calculated as:
=(199-50)+(199-16) =332
Advantages:
•
•
•
High throughput
Low variance of response time
Average response time
Disadvantages:
•
Long waiting time for requests for locations just visited by disk arm
CSCAN: In SCAN algorithm, the disk arm again scans the path that has been scanned, after
reversing its direction. So, it may be possible that too many requests are waiting at the other
end or there may be zero or few requests pending at the scanned area.
These situations are avoided in CSCAN algorithm in which the disk arm instead of reversing its
direction goes to the other end of the disk and starts servicing the requests from there. So, the
disk arm moves in a circular fashion and this algorithm is also similar to SCAN algorithm and
hence it is known as C-SCAN (Circular SCAN).
Example:
Suppose the requests to be addressed are-82,170,43,140,24,16,190. And the Read/Write arm
is at 50, and it is also given that the disk arm should move “towards the larger value”.
24
Seek time is calculated as:
=(199-50)+(199-0)+(43-0)
=391
Advantages:
•
Provides more uniform wait time compared to SCAN
LOOK: It is similar to the SCAN disk scheduling algorithm except for the difference that the disk
arm in spite of going to the end of the disk goes only to the last request to be serviced in front
of the head and then reverses its direction from there only. Thus it prevents the extra delay
which occurred due to unnecessary traversal to the end of the disk.
CLOOK: As LOOK is similar to SCAN algorithm, in similar way, CLOOK is similar to CSCAN disk
scheduling algorithm. In CLOOK, the disk arm in spite of going to the end goes only to the last
request to be serviced in front of the head and then from there goes to the other end’s last
request. Thus, it also prevents the extra delay which occurred due to unnecessary traversal to
the end of the disk.
RSS– It stands for random scheduling and just like its name it is nature. It is used in situations
where scheduling involves random attributes such as random processing time, random due
25
dates, random weights, and stochastic machine breakdowns this algorithm sits perfect. Which
is why it is usually used for and analysis and simulation.
LIFO– In LIFO (Last In, First Out) algorithm, newest jobs are serviced before the existing ones
i.e. in order of requests that get serviced the job that is newest or last entered is serviced first
and then the rest in the same order.
Advantages
• Maximizes locality and resource utilization
• Can seem a little unfair to other requests and if new requests keep
coming in, it cause starvation to the old and existing ones.
N-STEP SCAN – It is also known as N-STEP LOOK algorithm. In this a buffer is created for N
requests. All requests belonging to a buffer will be serviced in one go. Also once the buffer is
full no new requests are kept in this buffer and are sent to another one. Now, when these N
requests are serviced, the time comes for another top N requests and this way all get requests
get a guaranteed service
Advantages
• It eliminates starvation of requests completely
FSCAN– This algorithm uses two sub-queues. During the scan all requests in the first queue are
serviced and the new incoming requests are added to the second queue. All new requests are
kept on halt until the existing requests in the first queue are serviced.
Advantages
• FSCAN along with N-Step-SCAN prevents “arm stickiness” (phenomena in
I/O scheduling where the scheduling algorithm continues to service
requests at or near the current sector and thus prevents any seeking)
Code:
package prac5;
import java.util.*;
public class Prac5 {
double avgst, totst;
void fcfs(int a[], int p) {
totst = Math.abs(p - a[0]);
for (int i = 0; i < a.length - 1; i++) {
totst += Math.abs(a[i] - a[i + 1]);
}
avgst = totst / a.length;
System.out.println("Total seek time: " + totst);
System.out.println("Average seek time: " + avgst);
}
void sstf(int a[], int p) {
boolean done[] = new boolean[a.length];
int strtpt = p;
while (!allSelected(done)) {
int m = 0;
26
int mindiff = 1000;
for (int i = 0; i < a.length; i++) {
if (!done[i]) {
int diff = Math.abs(strtpt - a[i]);
if (diff < mindiff) {
m = i;
mindiff = diff;
}
}
}
totst += mindiff;
strtpt = a[m];
done[m] = true;
}
avgst = totst / a.length;
System.out.println("Total seek time: " + totst);
System.out.println("Average seek time: " + avgst);
}
boolean allSelected(boolean[] a) {
for (int i = 0; i < a.length; i++) {
if (!a[i]) {
return false;
}
}
return true;
}
public static void main(String arg[]) {
Scanner sc = new Scanner(System.in);
int c;
do {
System.out.println("Yash Prajapati - 022");
System.out.println("Enter no. of elements:");
int n = sc.nextInt();
System.out.println("Enter value of track nos. in the array:");
int a[] = new int[n];
for (int i = 0; i < n; i++) {
a[i] = sc.nextInt();
}
System.out.println("Enter starting point:");
int p = sc.nextInt();
System.out.println("\nEnter your choice:\n1. FCFS\n2. SSTF");
int ch = sc.nextInt();
Prac5 ds = new Prac5();
if (ch == 1) {
ds.fcfs(a, p);
} else {
ds.sstf(a, p);
}
System.out.println("do u wanna continue(1/0)");
c = sc.nextInt();
} while (c == 1);
}
}
Output:
27
Conclusion:
Successfully demonstrated following disk-scheduling algorithms.
28
Practical No. 6
Aim:
Write a Program in java to demonstrate Paging.
Theory:
In Operating Systems, Paging is a storage mechanism used to retrieve processes from the
secondary storage into the main memory in the form of pages.
The main idea behind the paging is to divide each process in the form of pages. The main memory
will also be divided in the form of frames.
One page of the process is to be stored in one of the frames of the memory. The pages can be
stored at the different locations of the memory but the priority is always to find the contiguous
frames or holes.
Pages of the process are brought into the main memory only when they are required otherwise
they reside in the secondary storage.
Different operating system defines different frame sizes. The sizes of each frame must be equal.
Considering the fact that the pages are mapped to the frames in Paging, page size needs to be as
same as frame size.
29
Example
Let us consider the main memory size 16 Kb and Frame size is 1 KB therefore the main memory
will be divided into the collection of 16 frames of 1 KB each.
There are 4 processes in the system that is P1, P2, P3 and P4 of 4 KB each. Each process is divided
into pages of 1 KB each so that one page can be stored in one frame.
Initially, all the frames are empty therefore pages of the processes will get stored in the contiguous
way.
Frames, pages and the mapping between the two is shown in the image below.
30
Let us consider that, P2 and P4 are moved to waiting state after some time. Now, 8 frames become
empty and therefore other pages can be loaded in that empty place. The process P5 of size 8 KB
(8 pages) is waiting inside the ready queue.
Given the fact that, we have 8 non contiguous frames available in the memory and paging provides
the flexibility of storing the process at the different places. Therefore, we can load the pages of
process P5 in the place of P2 and P4.
31
Memory Management Unit
The purpose of Memory Management Unit (MMU) is to convert the logical address into the
physical address. The logical address is the address generated by the CPU for every page while the
physical address is the actual address of the frame where each page will be stored.
When a page is to be accessed by the CPU by using the logical address, the operating system needs
to obtain the physical address to access that page physically.
The logical address has two parts.
32
1. Page Number
2. Offset
Memory management unit of OS needs to convert the page number to the frame number.
Example
Considering the above image, let's say that the CPU demands 10th word of 4th page of process
P3. Since the page number 4 of process P1 gets stored at frame number 9 therefore the 10th word
of 9th frame will be returned as the physical address.
Code:
package prac6;
import java.io.*;
public class Prac6 {
public static final int ADDRESS_SIZE = 32;
public static void main(String[] args) {
System.out.println("Yash Prajapati - 022");
try {
if (args.length != 2) {
System.out.println("Usage: java Address <page size> <address>");
// System.exit(0);
}
System.out.println("Please enter the parameters <pagesize> <address>");
BufferedReader bt = new BufferedReader(new InputStreamReader(System.in));
int pageSize = Integer.parseInt(bt.readLine().trim());
int address = Integer.parseInt(bt.readLine().trim());
int pageBits = 0;
int pageMask = 0;
int offsetMask = 0;
switch (pageSize) {
case 1024:
pageBits = 10;
offsetMask = 0x000003ff;
pageMask = 0xfffffc00;
break;
case 2048:
pageBits = 11;
offsetMask = 0x000007ff;
33
pageMask =
break;
case 4096:
pageBits =
offsetMask
pageMask =
break;
case 8192:
pageBits =
offsetMask
pageMask =
break;
case 16384:
pageBits =
offsetMask
pageMask =
break;
0xfffff800;
12;
= 0x00000fff;
0xfffff000;
13;
= 0x00001fff;
0xffffe000;
14;
= 0x00003fff;
0xffffcfff;
}
int pageNumber = (address & pageMask) >> pageBits;
int offset = (address & offsetMask);
//System.out.println("We will translate address " + address);
//System.out.println("page bits " + pageBits);
System.out.println("For address " + address + ": page number = " + pageNumber + " offset
= " + offset);
} catch (Exception e) {
}
}
}
Output:
Conclusion:
Successfully demonstrated concept of Paging in OS.
34
Practical No. 7
Aim:
Write a program that implements the FIFO and LRU page-replacement algorithms. First, generate
a random page reference string where page numbers range from 0 to 9. Apply the random pagereference string to each algorithm, and record the number of page faults incurred by each algorithm.
Implement the replacement algorithms so that the number of page frames can vary as well. Assume that
demand paging is used. Design and implement two classes—LRU and FIFO—that extend Replacement
Algorithm. Each of these classes will implement the insert () method, one class using the LRU pagereplacement algorithm and the other using the FIFO algorithm. Test your algorithm with suitable Java
programs.
Theory:
In an operating system that uses paging for memory management, a page
replacement algorithm is needed to decide which page needs to be replaced when a
new page comes in.
Page Fault – A page fault happens when a running program accesses a memory page
that is mapped into the virtual address space but not loaded in physical memory.
Since actual physical memory is much smaller than virtual memory, page faults happen.
In case of a page fault, Operating System might have to replace one of the existing
pages with the newly needed page. Different page replacement algorithms suggest
different ways to decide which page to replace. The target for all algorithms is to
reduce the number of page faults.
Page Replacement Algorithms :
1. First In First Out (FIFO) –
This is the simplest page replacement algorithm. In this algorithm, the operating system
keeps track of all pages in the memory in a queue, the oldest page is in the front of the
queue. When a page needs to be replaced page in the front of the queue is selected for
removal.
Example-1Consider page reference string 1, 3, 0, 3, 5, 6, 3 with 3 page frames.Find the
number of page faults.
35
Initially, all slots are empty, so when 1, 3, 0 came they are allocated to the empty slots
—> 3 Page Faults.
when 3 comes, it is already in memory so —> 0 Page Faults.
Then 5 comes, it is not available in memory so it replaces the oldest page slot i.e 1. —>1
Page Fault.
6 comes, it is also not available in memory so it replaces the oldest page slot i.e 3 —>1
Page Fault.
Finally, when 3 come it is not available so it replaces 0 1 page fault
Belady’s anomaly – Belady’s anomaly proves that it is possible to have more page faults
when increasing the number of page frames while using the First in First Out (FIFO)
page replacement algorithm. For example, if we consider reference string 3, 2, 1, 0, 3,
2, 4, 3, 2, 1, 0, 4 and 3 slots, we get 9 total page faults, but if we increase slots to 4, we
get 10-page faults.
2. Optimal Page replacement –
In this algorithm, pages are replaced which would not be used for the longest duration
of time in the future.
Example-2:Consider the page references 7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, with 4 page
frame. Find number of page fault.
36
Initially, all slots are empty, so when 7 0 1 2 are allocated to the empty slots —> 4 Page
faults
0 is already there so —> 0 Page fault.
when 3 came it will take the place of 7 because it is not used for the longest duration of
time in the future.—>1 Page fault.
0 is already there so —> 0 Page fault..
4 will takes place of 1 —> 1 Page Fault.
Now for the further page reference string —> 0 Page fault because they are already
available in the memory.
Optimal page replacement is perfect, but not possible in practice as the operating
system cannot know future requests. The use of Optimal Page replacement is to set up
a benchmark so that other replacement algorithms can be analyzed against it.
3. Least Recently Used –
In this algorithm, page will be replaced which is least recently used.
Example-3Consider the page reference string 7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2 with 4
page frames.Find number of page faults.
37
Initially, all slots are empty, so when 7 0 1 2 are allocated to the empty slots —> 4 Page
faults
0 is already their so —> 0 Page fault.
when 3 came it will take the place of 7 because it is least recently used —>1 Page fault
0 is already in memory so —> 0 Page fault.
4 will takes place of 1 —> 1 Page Fault
Now for the further page reference string —> 0 Page fault because they are already
available in the memory.
Code:
FIFO.java
package prac7;
import java.io.*;
public class FIFO {
public static void main(String[] args) throws IOException {
{
System.out.println("Yash Prajapati - 022 ");
int n = 0;
int fifo[] = new int[5];
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
System.out.println("Enter no of inputs : ");
n = Integer.parseInt(br.readLine());
38
int inp[] = new int[5];
System.out.println("Enter the inputs : ");
for (int i = 0; i < 5; i++) {
inp[i] = Integer.parseInt(br.readLine());
}
for (int i = 0; i < 5; i++) {
fifo[i] = -1;
}
int hit = 0;
int fault = 0;
int j = 0;
boolean check;
for (int i = 0; i < 5; i++) {
check = false;
for (int k = 0; k < 5; k++) {
if (fifo[k] == inp[i]) {
check = true;
hit = hit + 1;
}
}
if (check == false) {
fifo[j] = inp[i];
j++;
if (j >= 4) {
j = 0;
}
fault = fault + 1;
}
}
System.out.println("hits are : " + hit + "\nfaults are :" + fault);
}
}
}
Output:
39
LRU.java
package prac7;
import java.io.*;
public class LRU {
public static int sort(int c[]) {
int max = -1;
int temp = -1;
for (int k = 0; k < 3; k++) {
if (c[k] > max) {
max = c[k];
temp = k;
}
}
return temp;
}
public static void main(String[] args) throws IOException {
System.out.println("Yash Prajapati - 022 ");
int z, m = 0, hit = 0, fault = 0;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
System.out.println("enter the size of the array");
int n = Integer.parseInt(br.readLine());
int a[] = new int[n];
int flag[] = new int[n];
System.out.println("enter the elements :");
for (int i = 0; i < n; i++) {
a[i] = Integer.parseInt(br.readLine());
flag[i] = 0;
}
int b[] = new int[3];
int c[] = new int[3];
for (int i = 0; i < 3; i++) {
b[i] = -1;
c[i] = 0;
}
for (int i = 0; i < n; i++) {
z = a[i];
for (int j = 0; j < 3; j++) {
if (z == b[j]) {
flag[i] = 1;
hit = hit + 1;
break;
}
}
if (flag[i] == 0 && b[2] == -1) {
for (int j = 0; j < 3; j++) {
if (b[j] == -1) {
b[j] = z;
fault = fault + 1;
flag[i] = 1;
break;
}
}
40
}
if (flag[i] == 0) {
m = sort(c);
b[m] = z;
fault = fault + 1;
flag[i] = 1;
for (int k = 0; k < 3; k++) {
c[k] = c[k] + 1;
}
c[m] = 0;
}
}
System.out.println(" no of hits : " + hit);
System.out.println(" no of faults : " + fault);
System.out.println(" hit ratio : " + (hit * 100) / (hit + fault));
}
}
Output:
Conclusion:
Successfully demonstrated page replacement algorithm FIFO and LRU.
41
Practical No. 8
Aim:
Using Worker thread write Android code for a click listener that downloads an image from a
separate thread and displays it in an ImageView.
Theory:
Processes and Threads
When an application component starts and the application does not have any other components running,
the Android system starts a new Linux process for the application with a single thread of execution. By
default, all components of the same application run in the same process and thread (called the "main"
thread). If an application component starts and there already exists a process for that application
(because another component from the application exists), then the component is started within that
process and uses the same thread of execution. However, you can arrange for different components in
your application to run in separate processes, and you can create additional threads for any process.
This document discusses how processes and threads work in an Android application.
Processes
By default, all components of the same application run in the same process and most applications should not change this.
However, if you find that you need to control which process a certain component belongs to, you can do so in the
manifest file.
The manifest entry for each type of component element—<activity>, <service>, <receiver>, and<provider>—supports
an android:process attribute that can specify a process in which that component should run. You can set this attribute so
that each component runs in its own process or so that some components share a process while others do not. You can
also set android:process so that components of different applications run in the same process—provided that the
applications share the same Linux user ID and are signed with the same certificates.
The <application> element also supports an android:process attribute, to set a default value that applies to all components.
Android might decide to shut down a process at some point, when memory is low and required by other processes that
are more immediately serving the user. Application components running in the process that's killed are consequently
destroyed. A process is started again for those components when there's again work for them to do.
When deciding which processes to kill, the Android system weighs their relative importance to the user. For example, it
more readily shuts down a process hosting activities that are no longer visible on screen, compared to a process hosting
visible activities. The decision whether to terminate a process, therefore, depends on the state of the components running
in that process. The rules used to decide which processes to terminate is discussed below.
42
Process lifecycle
The Android system tries to maintain an application process for as long as possible, but eventually needs to remove old
processes to reclaim memory for new or more important processes. To determine which processes to keep and which to
kill, the system places each process into an "importance hierarchy" based on the components running in the process and
the state of those components. Processes with the lowest importance are eliminated first, then those with the next lowest
importance, and so on, as necessary to recover system resources.
There are five levels in the importance hierarchy. The following list presents the different types of processes in order of
importance (the first process is most important and is killed last):
1.
Foreground process
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of
the following conditions are true:
o
It hosts an Activity that the user is interacting with (the Activity's onResume() method has been called).
o
It hosts a Service that's bound to the activity that the user is interacting with.
o
It hosts a Service that's running "in the foreground"—the service has called startForeground().
o
It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), oronDestroy()).
o
It hosts a BroadcastReceiver that's executing its onReceive() method.
Generally, only a few foreground processes exist at any given time. They are killed only as a last resort—if memory is
so low that they cannot all continue to run. Generally, at that point, the device has reached a memory paging state, so
killing some foreground processes is required to keep the user interface responsive.
2.
Visible process
A process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is
considered to be visible if either of the following conditions are true:
o
It hosts an Activity that is not in the foreground, but is still visible to the user (its onPause() method has been called).
This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be
seen behind it.
o
It hosts a Service that's bound to a visible (or foreground) activity.
A visible process is considered extremely important and will not be killed unless doing so is required to keep all
foreground processes running.
3.
Service process
A process that is running a service that has been started with the startService() method and does not fall into either of
the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally
43
doing things that the user cares about (such as playing music in the background or downloading data on the network),
so the system keeps them running unless there's not enough memory to retain them along with all foreground and
visible processes.
4.
Background process
A process holding an activity that's not currently visible to the user (the activity's onStop() method has been called).
These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim
memory for a foreground, visible, or service process. Usually there are many background processes running, so they
are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by
the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state,
killing its process will not have a visible effect on the user experience, because when the user navigates back to the
activity, the activity restores all of its visible state. See the Activities document for information about saving and
restoring state.
5.
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for
caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these
processes in order to balance overall system resources between process caches and the underlying kernel caches.
Android ranks a process at the highest level it can, based upon the importance of the components currently active in the
process. For example, if a process hosts a service and a visible activity, the process is ranked as a visible process, not a
service process.
In addition, a process's ranking might be increased because other processes are dependent on it—a process that is serving
another process can never be ranked lower than the process it is serving. For example, if a content provider in process A is
serving a client in process B, or if a service in process A is bound to a component in process B, process A is always
considered at least as important as process B.
Because a process running a service is ranked higher than a process with background activities, an activity that initiates a
long-running operation might do well to start a service for that operation, rather than simply create a worker thread—
particularly if the operation will likely outlast the activity. For example, an activity that's uploading a picture to a web site
should start a service to perform the upload so that the upload can continue in the background even if the user leaves the
activity. Using a service guarantees that the operation will have at least "service process" priority, regardless of what
happens to the activity. This is the same reason that broadcast receivers should employ services rather than simply put
time-consuming operations in a thread.
Threads
When an application is launched, the system creates a thread of execution for the application, called "main." This thread is
very important because it is in charge of dispatching events to the appropriate user interface widgets, including drawing
44
events. It is also the thread in which your application interacts with components from the Android UI toolkit (components
from the android.widget and android.view packages). As such, the main thread is also sometimes called the UI thread.
The system does not create a separate thread for each instance of a component. All components that run in the same
process are instantiated in the UI thread, and system calls to each component are dispatched from that thread.
Consequently, methods that respond to system callbacks (such as onKeyDown() to report user actions or a lifecycle
callback method) always run in the UI thread of the process.
For instance, when the user touches a button on the screen, your app's UI thread dispatches the touch event to the
widget, which in turn sets its pressed state and posts an invalidate request to the event queue. The UI thread dequeues
the request and notifies the widget that it should redraw itself.
When your app performs intensive work in response to user interaction, this single thread model can yield poor
performance unless you implement your application properly. Specifically, if everything is happening in the UI thread,
performing long operations such as network access or database queries will block the whole UI. When the thread is
blocked, no events can be dispatched, including drawing events. From the user's perspective, the application appears to
hang. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user is
presented with the infamous "application not responding" (ANR) dialog. The user might then decide to quit your
application and uninstall it if they are unhappy.
Additionally, the Andoid UI toolkit is not thread-safe. So, you must not manipulate your UI from a worker thread—you
must do all manipulation to your user interface from the UI thread. Thus, there are simply two rules to Android's single
thread model:
1.
Do not block the UI thread
2.
Do not access the Android UI toolkit from outside the UI thread
Worker threads
Because of the single thread model described above, it's vital to the responsiveness of your application's UI that you do
not block the UI thread. If you have operations to perform that are not instantaneous, you should make sure to do them in
separate threads ("background" or "worker" threads).
For example, below is some code for a click listener that downloads an image from a separate thread and displays it in
an ImageView:
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork("http://example.com/image.png");
mImageView.setImageBitmap(b);
}
45
}).start();
}
At first, this seems to work fine, because it creates a new thread to handle the network operation. However, it violates the
second rule of the single-threaded model: do not access the Android UI toolkit from outside the UI thread—this sample
modifies the ImageView from the worker thread instead of the UI thread. This can result in undefined and unexpected
behavior, which can be difficult and time-consuming to track down.
To fix this problem, Android offers several ways to access the UI thread from other threads. Here is a list of methods that
can help:
•
Activity.runOnUiThread(Runnable)
•
View.post(Runnable)
•
View.postDelayed(Runnable, long)
For example, you can fix the above code by using the View.post(Runnable) method:
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap bitmap =
loadImageFromNetwork("http://example.com/image.png");
mImageView.post(new Runnable() {
public void run() {
mImageView.setImageBitmap(bitmap);
}
});
}
}).start();
}
Now this implementation is thread-safe: the network operation is done from a separate thread while the ImageView is
manipulated from the UI thread.
However, as the complexity of the operation grows, this kind of code can get complicated and difficult to maintain. To
handle more complex interactions with a worker thread, you might consider using a Handler in your worker thread, to
process messages delivered from the UI thread. Perhaps the best solution, though, is to extend the AsyncTask class, which
simplifies the execution of worker thread tasks that need to interact with the UI.
Using AsyncTask
46
AsyncTask allows you to perform asynchronous work on your user interface. It performs the blocking operations in a
worker thread and then publishes the results on the UI thread, without requiring you to handle threads and/or handlers
yourself.
To use it, you must subclass AsyncTask and implement the doInBackground() callback method, which runs in a pool of
background threads. To update your UI, you should implement onPostExecute(), which delivers the result
from doInBackground() and runs in the UI thread, so you can safely update your UI. You can then run the task by
calling execute() from the UI thread.
For example, you can implement the previous example using AsyncTask this way:
public void onClick(View v) {
new DownloadImageTask().execute("http://example.com/image.png");
}
private class DownloadImageTask extends AsyncTask<String, Void, Bitmap> {
/** The system calls this to perform work in a worker thread and
* delivers it the parameters given to AsyncTask.execute() */
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);
}
/** The system calls this to perform work in the UI thread and delivers
* the result from doInBackground() */
protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
}
}
Now the UI is safe and the code is simpler, because it separates the work into the part that should be done on a worker
thread and the part that should be done on the UI thread.
Ouput:
47
Conclusion:
Successfully demonstrated use of worker threads in android.
48
Practical No. 9
Aim:
Write Android activity that includes each of the fundamental lifecycle methods.
Theory:
z
49
Managing the Activity Lifecycle
As a user navigates through, out of, and back to your app, the Activity instances in your app transition
between different states in their lifecycle. For instance, when your activity starts for the first time, it
comes to the foreground of the system and receives user focus. During this process, the Android system
calls a series of lifecycle methods on the activity in which you set up the user interface and other
components. If the user performs an action that starts another activity or switches to another app, the
system calls another set of lifecycle methods on your activity as it moves into the background (where the
activity is no longer visible, but the instance and its state remains intact).
Within the lifecycle callback methods, you can declare how your activity behaves when the user
leaves and re-enters the activity. For example, if you're building a streaming video player, you
might pause the video and terminate the network connection when the user switches to another
app. When the user returns, you can reconnect to the network and allow the user to resume the
video from the same spot.
This class explains important lifecycle callback methods that each Activity instance receives and
how you can use them so your activity does what the user expects and does not consume
system resources when your activity doesn't need them.
Starting an Activity
Learn the basics about the activity lifecycle, how the user can launch your app, and how
to perform basic activity creation.
Pausing and Resuming an Activity
Learn what happens when your activity is paused (partially obscured) and resumed and
what you should do during these state changes.
Stopping and Restarting an Activity
Learn what happens when the user completely leaves your activity and returns to it.
Recreating an Activity
Learn what happens when your activity is destroyed and how you can rebuild the activity
state when necessary.
Code:
50
package com.example.lifecycleex;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.d("lifecycle","onCreate invoked");
}
@Override
protected void onStart() {
super.onStart();
Log.d("lifecycle","onStart invoked");
}
@Override
protected void onResume() {
super.onResume();
Log.d("lifecycle","onResume invoked");
}
@Override
protected void onPause() {
super.onPause();
Log.d("lifecycle","onPause invoked");
}
@Override
protected void onStop() {
super.onStop();
Log.d("lifecycle","onStop invoked");
}
@Override
protected void onRestart() {
super.onRestart();
Log.d("lifecycle","onRestart invoked");
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.d("lifecycle","onDestroy invoked");
}
}
Output:
51
Conclusion:
Successfully demonstrated Life cycle of an android app.
52
Practical No. 10
Aim:
Write Android application to demonstrate data storage with following options
a.
b.
c.
d.
e.
Shared Preferences (Store private primitive data in key-value pairs)
Internal Storage (Store private data on the device memory)
External Storage (Store public data on the shared external storage)
SQLite Databases (Store structured data in a private database)
Network Connection (Store data on the web with your own network server)
Storage Options
Android provides several options for you to save persistent application data. The solution you choose depends
on your specific needs, such as whether the data should be private to your application or accessible to other
applications (and the user) and how much space your data requires.
Data storage options are the following:
Shared Preferences
Store private primitive data in key-value pairs.
Internal Storage
Store private data on the device memory.
External Storage
Store public data on the shared external storage.
SQLite Databases
Store structured data in a private database.
Network Connection
Store data on the web with your own network server.
Android provides a way for you to expose even your private data to other applications — with a content provider. A
content provider is an optional component that exposes read/write access to your application data, subject to
53
whatever restrictions you want to impose. For more information about using content providers, see the Content
Providers documentation.
Code:
Main Activity.java
package com.karansoi.tcsc.storageex;
import
import
import
import
import
import
import
import
import
import
import
import
import
android.content.Context;
android.content.SharedPreferences;
android.database.Cursor;
android.database.sqlite.SQLiteDatabase;
android.os.Bundle;
android.os.Environment;
android.support.v7.app.AppCompatActivity;
android.util.Log;
android.view.View;
android.widget.EditText;
android.widget.RelativeLayout;
android.widget.TextView;
android.widget.Toast;
import
import
import
import
import
import
java.io.BufferedReader;
java.io.File;
java.io.FileInputStream;
java.io.FileOutputStream;
java.io.IOException;
java.io.InputStreamReader;
public class MainActivity extends AppCompatActivity {
private String TAG = "MainActivity";
SharedPreferences tcscpref;
SharedPreferences.Editor tcsceditor;
private SQLiteDatabase mydb;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// Initialise the db for the shared preferences.
tcscpref = getSharedPreferences("tcsc", MODE_PRIVATE);
tcsceditor = tcscpref.edit();
// Making Object and initializing database.
mydb = openOrCreateDatabase("TCSCSQLDB", MODE_PRIVATE, null);
54
viewFile();
}
public void sharedButtonClick(View v) {
// This is the piece of code to handle storage of data using
sharedpreferences
EditText sharedPrefET = (EditText) findViewById(R.id.shared_pref_edit);
String textToStore = sharedPrefET.getText().toString();
tcsceditor.putString("user_text", textToStore);
tcsceditor.commit();
Toast.makeText(getApplicationContext(), "Saved", Toast.LENGTH_SHORT).show();
}
public void internalButtonClick(View v) {
// This is used to initialise the internal db
EditText internalStoreET = (EditText)
findViewById(R.id.internal_storage_edit);
String textToStore = internalStoreET.getText().toString();
try {
FileOutputStream fos = openFileOutput("user_txtfile.txt",
Context.MODE_PRIVATE);
fos.write(textToStore.getBytes());
fos.flush();
fos.close();
viewFile();
Toast.makeText(getApplicationContext(), "Saved in Internal Dir",
Toast.LENGTH_SHORT).show();
} catch (IOException ioe) {
Log.e(TAG, "IOE Err : " + ioe.getLocalizedMessage());
}
}
public void externalButtonClick(View v) {
if (isExternalStorageReadable() && isExternalStorageWritable()) {
EditText externalStoreET = (EditText)
findViewById(R.id.external_storage_edit);
String textToStore = externalStoreET.getText().toString();
try {
String externalDir =
Environment.getExternalStorageDirectory().toString();
File myDir = new File(externalDir + File.separator +
"tcsc_ks_files");
myDir.mkdirs();
55
String fname = "user_txtfile.txt";
File nfile = new File(myDir, fname);
if (nfile.exists()) nfile.delete();
FileOutputStream fos = new FileOutputStream(nfile);
fos.write(textToStore.getBytes());
fos.flush();
fos.close();
viewFile();
Toast.makeText(getApplicationContext(), "Saved in External Dir",
Toast.LENGTH_LONG).show();
} catch (IOException ioe) {
Log.e(TAG, "IOE Err : " + ioe.getLocalizedMessage());
}
} else {
Toast.makeText(getApplicationContext(), "Sorry no External Storage
Detected", Toast.LENGTH_LONG).show();
}
}
public void sqlDBButtonClick(View v) {
EditText externalStoreET = (EditText) findViewById(R.id.sql_storage_edit);
String textToStore = externalStoreET.getText().toString();
mydb.execSQL("drop table USERTEXTTABLE");
// Create table if doesnt exist and insert values.
mydb.execSQL("create table if not exists USERTEXTTABLE(USERTEXT VARCHAR);");
// Insert the text into the table
String query = "insert into USERTEXTTABLE values('" + textToStore + "');";
mydb.execSQL(query);
Toast.makeText(getApplicationContext(), "Saved in SQL DB",
Toast.LENGTH_LONG).show();
viewFile();
}
private void viewFile() {
try {
RelativeLayout rel = (RelativeLayout) findViewById(R.id.out_rel);
rel.setVisibility(View.VISIBLE);
///////////// INTERNAL DB ////////////////////////////
FileInputStream infis = openFileInput("user_txtfile.txt");
56
BufferedReader inbufferedReader = new BufferedReader(new
InputStreamReader(infis, "UTF-8"));
StringBuilder insb = new StringBuilder();
String inline;
while ((inline = inbufferedReader.readLine()) != null) {
insb.append(inline);
}
//////////////////////////////////////////////////////
///////////// EXTERNAL DB ////////////////////////////
String fname = "user_txtfile.txt";
File exfile = new File(Environment.getExternalStorageDirectory()
.getAbsolutePath() + File.separator + "tcsc_ks_files" +
File.separator + fname);
FileInputStream exfis = new FileInputStream(exfile);
BufferedReader exbufferedReader = new BufferedReader(new
InputStreamReader(exfis, "UTF-8"));
StringBuilder exsb = new StringBuilder();
String exline;
while ((exline = exbufferedReader.readLine()) != null) {
exsb.append(exline);
}
/////////////////////////////////////////////////////
///////////// SQLLITE DB ////////////////////////////
// Get data from SQL DB
String note = "";
try {
String query = "select USERTEXT from USERTEXTTABLE";
Cursor resultSet = mydb.rawQuery(query, null);
//
resultSet.moveToPosition(0);
Log.e(TAG, "" + resultSet.getColumnName(0));
Log.e(TAG, "" + resultSet.getColumnCount());
Log.e(TAG, "" + resultSet.getCount());
Log.e(TAG, "done : " + resultSet.getString(0));
note = resultSet.getString(0);
resultSet.close();
} catch (Exception e) {
Log.e(TAG, "SQL View Err : " + e.getLocalizedMessage());
}
/////////////////////////////////////////////////////
TextView outputTV = (TextView) findViewById(R.id.output_test);
outputTV.setText("Shared : " + tcscpref.getString("user_text", "Can't
Find") + "\nInternal : " + insb.toString()
57
+ "\nExternal : " + exsb.toString() + "\nSQLLITE : " + note);
} catch (IOException e) {
Log.e(TAG, "" + e.getLocalizedMessage());
}
}
/* Checks if external storage is available for read and write */
public boolean isExternalStorageWritable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state)) {
return true;
}
return false;
}
/* Checks if external storage is available to at least read */
public boolean isExternalStorageReadable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state) ||
Environment.MEDIA_MOUNTED_READ_ONLY.equals(state)) {
return true;
}
return false;
}
}
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.karansoi.tcsc.storageex">
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
58
</application>
</manifest>
Output:
Shared Preference
Internal Storage:
59
60
61
Conclusion:
Successfully demonstrated data storage in android.