Android - Brahm Bunga, Dodra

goatishspyMobile - Wireless

Dec 10, 2013 (3 years and 8 months ago)

97 views

Accident and Emergency
-

Patient Management System


1




COVENTRY UNIVERSITY




Project Title:

Accident and Emergency
-

Patient Management
System


Prepared by:


Student ID:


Supervisor Name:


Course:


Accident and Emergency
-

Patient Management System


2


I
NDIVIDUAL
P
ROJECT
D
ECLARATION


This is to
state

that, this

project and report

on “
Accident and
Eme
rgency
-

Patient Management System


which has been
present

as
part
of
completion

for the award of
<Specify Course>
.

The
report

and
website
project
ha
ve

been
written and implemented
by

myself
.
Also
a
ny

technical data and facts which are taken

from authentic

sources

are
fully referenced.


I understand that cheating and plagiarism constitute a breach of
University regulations and will be dealt with accordingly.



Signed: ...............................

Date: 2
4 / 08 / 2010












Accident and Emergency
-

Patient Management System


3


ACKNOWLEDGMENT

First and
foremost I am

thankful

to

Allah who has
in every way given
me strength to complete my project and report. Development of this report
and website could not have been achieved without Allah’s

support.


Next,
I find it essential

to express my
gratefulness

for

my project tutor
<Give Name of Tutor>
,

who has been very supportive and mentored me at
every stage of the project.

Last but not the least;

I am also thankful to my fellow pears and friends
who have always helped me whenever I needed it most. And to my par
ents
who have always given me the right advice and helped me to keep a positive
approach to every thing in life.





<Student Name>


Accident and Emergency
-

Patient Management System


4


A
BSTRACT


Accidents & Emergencies al
though are unforeseen and unfortunate
events, however they impact people worldwide. As per the Healthcare
Commission's 2008 survey on A&E, around 18 million people a year go
to accident and emergency (A&E) departments. [13]

Due to the unplanned nature of p
atient attendance, the department
must provide initial treatment for a broad spectrum of illnesses and
injuries, some of which may be life
-
threatening and require immediate
attention. In some countries, emergency departments have become
important entry poi
nts for those without other means of access to
medical care

It is usually seen that during such unforeseen events, Disaster
Management teams come into action and the effected patients are
admitted to the local hospitals. At this point it not only becomes v
ery
difficult for the hospital staff to manage the status of the patients but
also for the family members of the effected people to search their loved
ones and find out where they are and in what condition.

To answer all such issues, this project and the w
ebsite provided end to
end patient status management solution which not only provides
facilities for the hospital staff to manage patient status, but also to the
family members to search patients globally in all the hospitals around
the world.
Accident and Emergency
-

Patient Management System


5



INDEX

ABSTRACT

................................
................................
................................
................................
...........

4

CHAPTER 1


INTRODUCTION

................................
................................
................................
...

6

1.1

A
NDROI D

................................
................................
................................
................................
.

6

1.2

A
NDROI D
B
REAKTHROUGHS

................................
................................
................................
.

7

CHAPTER 2


LITERATURE REVIEW

................................
................................
......................

9

2.1

A
NDROI D
S
OFTWARE DEVEL
OPMENT
................................
................................
..................

9

2.2

A
NDROI D
A
PPLI CATI ON
F
UNDAMENTALS
:

................................
................................
.......

10

2.3

A
PPLI CATI ON
C
OMPONENTS

................................
................................
..............................

11

2.4

P
ROCESSES AND
T
HREADS
................................
................................
................................
..

14

2.5

C
OMPONENT
L
I FECYCLES

................................
................................
................................
...

18

2.6

P
ROCESSES AND LI FECYC
LES

................................
................................
..............................

22

2.7

U
SER
I
NTERFACE

................................
................................
................................
.................

24

2.8

U
SI NG THE
C
AMERA

................................
................................
................................
............

26

2.9

U
SI NG THE
B
LUETOOTH

................................
................................
................................
......

27

CHAPTER 3


APPLICATION DESIGN A
ND IMPLEMENTATION
................................

33

3.1

SUMMARY

................................
................................
................................
..............................

33

3.2

UNDER
STANDING THE CODE

................................
................................
.......................

33

3.2.1

SOFTWARE DESIGN
................................
................................
................................
.......

33

3.2.1.1

SAMPLE

................................
................................
................................
...........................

33

3.2.2

APPLICATION LAYOUT
................................
................................
................................

33

3.5

CONCLUSION

................................
................................
................................
........................

33

REFERENCES

................................
................................
................................
................................
....

33

APPE
NDIX

................................
................................
................................
................................
..........

34

SOURCE CODE

................................
................................
................................
................................
..

34



Index of Figures

Figure
No.

Figure Summary

Page
Number







Accident and Emergency
-

Patient Management System


6



C
HAPTER
1



I
NTRODUCTION

1.1

A
NDROID

Android delivers a complete set of s
oftware for mobile devices: an
operating system, middleware and key mobile applications.

Android is a mobile operating system initially developed by Android
Inc. Android was purchased by Google in 2005. Android is based upon
a modified version of the Linu
x kernel. Google and other members of
the Open Handset Alliance collaborated to develop and release
Android to the world. The Android Open Source Project (AOSP) is
tasked with the maintenance and further development of Android.
Unit sales for Android OS
sm
art phones

ranked first among all
smartphone OS handsets sold in the U.S. in the second and third
quarters of 2010, with a third quarter market share of 43.6%.

Android Features

Open

Android was built from the ground
-
up to enable developers to create
comp
elling mobile applications that take full advantage of all a handset
has to offer. It was built to be truly open. For example, an application
can call upon any of the phone's core functionality such as making
calls, sending text messages, or using the came
ra, allowing developers
to create richer and more cohesive experiences for users. Android is
built on the open Linux Kernel. Furthermore, it utilizes a custom
virtual machine that was designed to optimize memory and hardware
resources in a mobile environme
nt. Android is open source; it can be
liberally extended to incorporate new cutting edge technologies as they
emerge. The platform will continue to evolve as the developer
community works together to build innovative mobile applications.

All applications
are created equal

Android does not differentiate between the phone's core applications
and third
-
party applications. They can all be built to have equal access
to a phone's capabilities providing users with a broad spectrum of
applications and services. W
ith devices built on the Android Platform,
users are able to fully tailor the phone to their interests. They can swap
out the phone's
home screen
, the style of the dialer, or any of the
applications. They can even instruct their phones to use their favorit
e
photo viewing application to handle the viewing of all photos.

Accident and Emergency
-

Patient Management System


7


Breaking down application boundaries

Android breaks down the barriers to building new and innovative
applications. For example, a developer can combine information from
the web with data on

an individual's mobile phone


such as the
user's contacts, calendar, or geographic location


to provide a more
relevant user experience. With Android, a developer can build an
application that enables users to view the location of their friends and
be a
lerted when they are in the vicinity giving them a chance to
connect.

Fast & easy application development

Android provides access to a wide range of useful libraries and tools
that can be used to build rich applications. For example, Android
enables deve
lopers to obtain the location of the device, and allows
devices to communicate with one another enabling rich peer
-
to
-
peer
social applications. In addition, Android includes a full set of tools that
have been built from the ground up alongside the platform

providing
developers with high productivity and deep insight into their
applications.



1.2

A
NDROID
B
REAKTHROUGHS

Android has a large community of developers writing application
programs ("apps") that extend the functionality of the devices. There
are curr
ently over 100,000 apps available for Android. Android Market
is the online app store run by Google, though apps can be downloaded
from third party sites (except on AT&T, which disallows this).
Developers write in the Java language, controlling the device
via
Google
-
developed Java libraries.

The unveiling of the Android distribution on 5 November 2007 was
announced with the founding of the Open Handset Alliance, a
consortium of 79 hardware, software, and telecom companies devoted
to advancing open standard
s for mobile devices. Google released most
of the Android code under the Apache License, a free software and
open source license.

The Android operating system software stack consists of Java
applications running on a Java based object oriented application

framework on top of Java core libraries running on a Dalvik virtual
machine featuring JIT compilation. Libraries written in C include the
surface manager, OpenCore media framework, SQLite relational
Accident and Emergency
-

Patient Management System


8


database management system, OpenGL ES 2.0 3D graphics AP
I,
WebKit layout engine, SGL graphics engine, SSL, and Bionic libc. The
Android operating system consists of 12 million lines of code including
3 million lines of XML, 2.8 million lines of C, 2.1 million lines of Java,
and 1.75 million lines of C++.

Accident and Emergency
-

Patient Management System


9



C
HAP
TER
2



L
ITERATURE REVIEW

2.1

A
NDROID
S
OFTWARE DEVELOPMENT


The early feedback on developing applications for the Android
platform was mixed. Issues cited include bugs, lack of documentation,
inadequate QA infrastructure, and no public issue
-
tracking system.
(
Google announced an issue tracker on 18 January 2008.) In December
2007, MergeLab mobile startup founder Adam MacBeth stated,
"Functionality is not there, is poorly documented or just doesn't work...
It's clearly not ready for prime time." Despite this, A
ndroid
-
targeted
applications began to appear the week after the platform was
announced. The first publicly available application was the Snake
game. The Android Dev Phone is a SIM
-
unlocked and hardware
-
unlocked device that is designed for advanced develope
rs. While
developers can use regular consumer devices purchased at retail to test
and use their applications, some developers may choose not to use a
retail device, preferring an unlocked or no
-
contract device.

Software development kit

The Android software

development kit (SDK) includes a
comprehensive set of development tools. These include a debugger,
libraries, a handset emulator (based on QEMU), documentation,
sample code, and tutorials. Currently supported development
platforms include computers runnin
g Linux (any modern desktop
Linux distribution), Mac OS X 10.4.9 or later, Windows XP or later. The
officially supported integrated development environment (IDE) is
Eclipse (currently 3.4 or 3.5) using the Android Development Tools
(ADT) Plugin, though dev
elopers may use any text editor to edit Java
and XML files then use command line tools (Java Development Kit and
Apache Ant are required) to create, build and debug Android
applications as well as control attached Android devices (e.g.,
triggering a reboot
, installing software package(s) remotely).

A preview release of the Android SDK was released on 12 November
2007. On 15 July 2008, the Android Developer Challenge Team
accidentally sent an email to all entrants in the Android Developer
Challenge announci
ng that a new release of the SDK was available in a
"private" download area. The email was intended for winners of the
first round of the Android Developer Challenge. The revelation that
Google was supplying new SDK releases to some developers and not
othe
rs (and keeping this arrangement private) led to widely reported
frustration within the Android developer community at the time.

Accident and Emergency
-

Patient Management System


10


On 18 August 2008 the Android 0.9 SDK beta was released. This
release provided an updated and extended API, improved
developme
nt tools and an updated design for the home screen.
Detailed instructions for upgrading are available to those already
working with an earlier release. On 23 September 2008 the Android 1.0
SDK (Release 1) was released. According to the release notes, it
in
cluded "mainly bug fixes, although some smaller features were
added". It also included several API changes from the 0.9 version.
Multiple versions have been released since.

Enhancements to Android's SDK go hand in hand with the overall
Android platform de
velopment. The SDK also supports older versions
of the Android platform in case developers wish to target their
applications at older devices. Development tools are downloadable
components, so after one has downloaded the latest version and
platform, older

platforms and tools can also be downloaded for
compatibility testing.

Android applications are packaged in .apk format and stored under
/data/app

folder on the Android OS (the folder is accessible to root
user only for security reasons). APK package cont
ains .dex files
(compiled byte code files called Dalvik executable), resource files, etc.


2.2

A
NDROID
A
PPLICATION
F
UNDAMENTALS
:


Android applications are written in the Java programming language.
The compiled Java code


along with any data and resource files

required by the application


is bundled by the aapt tool into an
Android package, an archive file marked by an .apk suffix. This file is
the vehicle for distributing the application and installing it on mobile
devices; it's the file users download to the
ir devices. All the code in a
single .apk file is considered to be one application.

In many ways, each Android application lives in its own world:



By default, every application runs in its own Linux process.
Android starts the process when any of the app
lication's code
needs to be executed, and shuts down the process when it's no
longer needed and system resources are required by other
applications.



Each process has its own virtual machine (VM), so application
code runs in isolation from the code of all
other applications.



By default, each application is assigned a unique Linux user ID.
Permissions are set so that the application's files are visible only
Accident and Emergency
-

Patient Management System


11


to that user and only to the application itself


although there
are ways to export them to other app
lications as well.

It's possible to arrange for two applications to share the same user ID,
in which case they will be able to see each other's files. To conserve
system resources, applications with the same ID can also arrange to
run in the same Linux pr
ocess, sharing the same VM.


2.3

A
PPLICATION
C
OMPONENTS

A central feature of Android is that one application can make use of
elements of other applications (provided those applications permit it).
For example, if your application needs to display a scrolling l
ist of
images and another application has developed a suitable scroller and
made it available to others, you can call upon that scroller to do the
work, rather than develop your own. Your application doesn't
incorporate the code of the other application or

link to it. Rather, it
simply starts up that piece of the other application when the need
arises.

For this to work, the system must be able to start an application process
when any part of it is needed, and instantiate the Java objects for that
part. The
refore, unlike applications on most other systems, Android
applications don't have a single entry point for everything in the
application (no main() function, for example). Rather, they have
essential components that the system can instantiate and run as
n
eeded. There are four types of components:

Activities

An activity presents a visual user interface for one focused endeavor
the user can undertake. For example, an activity might present a list of
menu items users can choose from or it might display phot
ographs
along with their captions. A text messaging application might have one
activity that shows a list of contacts to send messages to, a second
activity to write the message to the chosen contact, and other activities
to review old messages or change s
ettings. Though they work together
to form a cohesive user interface, each activity is independent of the
others. Each one is implemented as a subclass of the Activity base class.

An application might consist of just one activity or, like the text
messagi
ng application just mentioned, it may contain several. What the
activities are, and how many there are depends, of course, on the
Accident and Emergency
-

Patient Management System


12


application and its design. Typically, one of the activities is marked as
the first one that should be presented to the user w
hen the application
is launched. Moving from one activity to another is accomplished by
having the current activity start the next one.

Each activity is given a default window to draw in. Typically, the
window fills the screen, but it might be smaller tha
n the screen and
float on top of other windows. An activity can also make use of
additional windows


for example, a pop
-
up dialog that calls for a
user response in the midst of the activity, or a window that presents
users with vital information when they

select a particular item on
-
screen.

The visual content of the window is provided by a hierarchy of views


objects derived from the base View class. Each view controls a
particular rectangular space within the window. Parent views contain
and organize th
e layout of their children. Leaf views (those at the
bottom of the hierarchy) draw in the rectangles they control and
respond to user actions directed at that space. Thus, views are where
the activity's interaction with the user takes place. For example, a

view
might display a small image and initiate an action when the user taps
that image. Android has a number of ready
-
made views that you can
use


including buttons, text fields, scroll bars, menu items, check
boxes, and more.

A view hierarchy is placed
within an activity's window by the
Activity.setContentView() method. The content view is the View object
at the root of the hierarchy. (See the separate User Interface document
for more information on views and the hierarchy.)

Services

A service doesn't
have a visual user interface, but rather runs in the
background for an indefinite period of time. For example, a service
might play background music as the user attends to other matters, or it
might fetch data over the network or calculate something and pr
ovide
the result to activities that need it. Each service extends the Service
base class.

A prime example is a media player playing songs from a play list. The
player application would probably have one or more activities that
allow the user to choose son
gs and start playing them. However, the
music playback itself would not be handled by an activity because
users will expect the music to keep playing even after they leave the
player and begin something different. To keep the music going, the
media player
activity could start a service to run in the background.
Accident and Emergency
-

Patient Management System


13


The system would then keep the music playback service running even
after the activity that started it leaves the screen.

It's possible to connect to (bind to) an ongoing service (and start the
servi
ce if it's not already running). While connected, you can
communicate with the service through an interface that the service
exposes. For the music service, this interface might allow users to
pause, rewind, stop, and restart the playback.

Like activities

and the other components, services run in the main
thread of the application process. So that they won't block other
components or the user interface, they often spawn another thread for
time
-
consuming tasks (like music playback). See Processes and
Thread
s, later.

Broadcast receivers

A broadcast receiver is a component that does nothing but receive and
react to

broadcast announcements. Many broadcasts originate in
system code


for example, announcements that the timezone has
changed, that the battery is

low, that a picture has been taken, or that
the user changed a language preference. Applications can also initiate
broadcasts


for example, to let other applications know that some
data has been downloaded to the device and is available for them to
use.

An application can have any number of broadcast receivers to respond
to any announcements it considers important. All receivers extend the
Broadcast Receiver

base class.

Broadcast receivers do not display a user interface. However, they may
start an acti
vity in response to the information they receive, or they
may use the
Notification Manager

to alert the user. Notifications can
get the user's attention in various ways


flashing the backlight,
vibrating the device, playing a sound, and so on. They typica
lly place a
persistent icon in the status bar, which users can open to get the
message.

Content providers

A content provider makes a specific set of the application's data
available to other applications. The data can be stored in the file
system, in an
SQLite database, or in any other manner that makes
sense. The content provider extends the
Content Provider

base class to
implement a standard set of methods that enable other applications to
retrieve and store data of the type it controls. However, applic
ations do
not call these methods directly. Rather they use a
Content Resolver

Accident and Emergency
-

Patient Management System


14


object and call its methods instead. A ContentResolver can talk to any
content provider; it cooperates with the provider to manage any
interprocess communication that's involved.


See the separate Content Providers document for more information on
using content providers.



2.4

P
ROCESSES AND
T
HREADS

When the first of an application's components needs to be run,
Android starts a Linux process for it with a single thread of execution.
By default, all components of the application run in that process and
thread.

However, you can arrange for components to run in other processes,
and you can spawn additional threads for any process.

Processes

The process where a component runs is control
led by the manifest file.
The component elements


<activity>, <service>, <receiver>, and
<provider>


each have a process attribute that can specify a process
where that component should run. These attributes can be set so that
each component runs in its
own process, or so that some components
share a process while others do not. They can also be set so that
components of different applications run in the same process


provided that the applications share the same Linux user ID and are
signed by the same
authorities. The <application> element also has a
process attribute, for setting a default value that applies to all
components.

All components are instantiated in the main thread of the specified
process, and system calls to the component are dispatched
from that
thread. Separate threads are not created for each instance.
Consequently, methods that respond to those calls


methods like
View.onKeyDown() that report user actions and the lifecycle
notifications discussed later in the Component Lifecycles sec
tion


always run in the main thread of the process. This means that no
component should perform long or blocking operations (such as
networking operations or computation loops) when called by the
system, since this will block any other components also in
the process.
You can spawn separate threads for long operations, as discussed
under Threads, next.

Accident and Emergency
-

Patient Management System


15


Android may 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. Appl
ication components running in the
process are consequently destroyed. A process is restarted for those
components when there's again work for them to do.

When deciding which processes to terminate, Android weighs their
relative importance to the user. For

example, it more readily shuts
down a process with activities that are no longer visible on screen than
a process with visible activities. The decision whether to terminate a
process, therefore, depends on the state of the components running in
that proce
ss. Those states are the subject of a later section, Component
Lifecycles.

Threads

Even though you may confine your application to a single process,
there will likely be times when you will need to spawn a thread to do
some background work. Since the user

interface must always be quick
to respond to user actions, the thread that hosts an activity should not
also host time
-
consuming operations like network downloads.
Anything that may not be completed quickly should be assigned to a
different thread.

Threa
ds are created in code using standard Java Thread objects.
Android provides a number of convenience classes for managing
threads


Looper for running a message loop within a thread, Handler
for processing messages, and HandlerThread for setting up a thread

with a message loop.

Remote procedure calls

Android has a lightweight mechanism for remote procedure calls
(RPCs)


where a method is called locally, but executed remotely (in
another process), with any result returned back to the caller. This
entails de
composing the method call and all its attendant data to a
level the operating system can understand, transmitting it from the
local process and address space to the remote process and address
space, and reassembling and reenacting the call there. Return va
lues
have to be transmitted in the opposite direction. Android provides all
the code to do that work, so that you can concentrate on defining and
implementing the RPC interface itself.

An RPC interface can include only methods. By default, all methods
are

executed synchronously (the local method blocks until the remote
method finishes), even if there is no return value.

Accident and Emergency
-

Patient Management System


16


In brief, the mechanism works as follows: You'd begin by declaring the
RPC interface you want to implement using a simple IDL (interface
definition language). From that declaration, the aidl tool generates a
Java interface definition that must be made available to both the local
and the remote process. It contains two inner class, as shown in the
following diagram:


The inner classes have all the code needed to administer remote
procedure calls for the interface you declared with the IDL. Both inner
classes implement the IBinder interface. One of the
m is used locally
and internally by the system; the code you write can ignore it. The
other, called Stub, extends the Binder class. In addition to internal code
for effectuating the IPC calls, it contains declarations for the methods in
the RPC interface y
ou declared. You would subclass Stub to implement
those methods, as indicated in the diagram.

Typically, the remote process would be managed by a service (because
a service can inform the system about the process and its connections
to other processes). I
t would have both the interface file generated by
the aidl tool and the Stub subclass implementing the RPC methods.
Clients of the service would have only the interface file generated by
the aidl tool.

Here's how a connection between a service and its cli
ents is set up:

Clients of the service (on the local side) would implement
onServiceConnected() and onServiceDisconnected() methods so they
Accident and Emergency
-

Patient Management System


17


can be notified when a successful connection to the remote service is
established, and when it goes away. They woul
d then call
bindService() to set up the connection.

The service's onBind() method would be implemented to either accept
or reject the connection, depending on the intent it receives (the intent
passed to bindService()). If the connection is accepted, it r
eturns an
instance of the Stub subclass.

If the service accepts the connection, Android calls the client's
onServiceConnected() method and passes it an IBinder object, a proxy
for the Stub subclass managed by the service. Through the proxy, the
client can

make calls on the remote service.

This brief description omits some details of the RPC mechanism. For
more information, see Designing a Remote Interface Using AIDL and
the IBinder class description.

Thread
-
safe methods

In a few contexts, the methods you

implement may be called from
more than one thread, and therefore must be written to be thread
-
safe.

This is primarily true for methods that can be called remotely


as in
the RPC mechanism discussed in the previous section. When a call on a
method implem
ented in an IBinder object originates in the same
process as the IBinder, the method is executed in the caller's thread.
However, when the call originates in another process, the method is
executed in a thread chosen from a pool of threads that Android
mai
ntains in the same process as the IBinder; it's not executed in the
main thread of the process. For example, whereas a service's onBind()
method would be called from the main thread of the service's process,
methods implemented in the object that onBind()
returns (for example,
a Stub subclass that implements RPC methods) would be called from
threads in the pool. Since services can have more than one client, more
than one pool thread can engage the same IBinder method at the same
time. IBinder methods must,
therefore, be implemented to be thread
-
safe.

Similarly, a content provider can receive data requests that originate in
other processes. Although the ContentResolver and ContentProvider
classes hide the details of how the interprocess communication is
mana
ged, ContentProvider methods that respond to those requests


the methods query(), insert(), delete(), update(), and getType()


are
called from a pool of threads in the content provider's process, not the
main thread of the process. Since these methods ma
y be called from
Accident and Emergency
-

Patient Management System


18


any number of threads at the same time, they too must be implemented
to be thread
-
safe.

2.5

C
OMPONENT
L
IFECYCLES

Application components have a lifecycle


a beginning when Android
instantiates them to respond to intents through to an end when

the
instances are destroyed. In between, they may sometimes be active or
inactive,or, in the case of activities, visible to the user or invisible. This
section discusses the lifecycles of activities, services, and broadcast
receivers


including the state
s that they can be in during their lifetimes,
the methods that notify you of transitions between states, and the effect of
those states on the possibility that the process hosting them might be
terminated and the instances destroyed.

Activity lifecycle

An

activity has essentially three states:

It is active or running when it is in the foreground of the screen (at the top
of the activity stack for the current task). This is the activity that is the
focus for the user's actions.

It is paused if it has lost
focus but is still visible to the user. That is, another
activity lies on top of it and that activity either is transparent or doesn't
cover the full screen, so some of the paused activity can show through. A
paused activity is completely alive (it maintai
ns all state and member
information and remains attached to the window manager), but can be
killed by the system in extreme low memory situations.

It is stopped if it is completely obscured by another activity. It still retains
all state and member informa
tion. However, it is no longer visible to the
user so its window is hidden and it will often be killed by the system
when memory is needed elsewhere.

If an activity is paused or stopped, the system can drop it from memory
either by asking it to finish (cal
ling its finish() method), or simply killing
its process. When it is displayed again to the user, it must be completely
restarted and restored to its previous state.

As an activity transitions from state to state, it is notified of the change by
calls to
the following protected methods:

void onCreate(Bundle savedInstanceState)

void onStart()

void onRestart()

Accident and Emergency
-

Patient Management System


19


void onResume()

void onPause()

void onStop()

void onDestroy()

All of these methods are hooks that you can override to do appropriate
work when
the state changes. All activities must implement onCreate() to
do the initial setup when the object is first instantiated. Many will also
implement onPause() to commit data changes and otherwise prepare to
stop interacting with the user.

Calling into the
superclass

An implementation of any activity lifecycle method should always first
call the superclass version. For example:

protected void onPause() {





super.onPause();





. . .

}

Taken together, these seven methods define the entire lifecycle of an
a
ctivity. There are three nested loops that you can monitor by
implementing them:



The entire lifetime of an activity happens between the first call to
onCreate() through to a single final call to onDestroy(). An activity does all
its initial setup of "glob
al" state in onCreate(), and releases all remaining
resources in onDestroy(). For example, if it has a thread running in the
background to download data from the network, it may create that thread
in onCreate() and then stop the thread in onDestroy().



The

visible lifetime of an activity happens between a call to
onStart() until a corresponding call to onStop(). During this time, the user
can see the activity on
-
screen, though it may not be in the foreground and
interacting with the user. Between these two
methods, you can maintain
resources that are needed to show the activity to the user. For example,
you can register a BroadcastReceiver in onStart() to monitor for changes
that impact your UI, and unregister it in onStop() when the user can no
longer see w
hat you are displaying. The onStart() and onStop() methods
can be called multiple times, as the activity alternates between being
visible and hidden to the user.



The foreground lifetime of an activity happens between a call to
onResume() until a correspond
ing call to onPause(). During this time, the
activity is in front of all other activities on screen and is interacting with
Accident and Emergency
-

Patient Management System


20


the user. An activity can frequently transition between the resumed and
paused states


for example, onPause() is called when the de
vice goes to
sleep or when a new activity is started, onResume() is called when an
activity result or a new intent is delivered. Therefore, the code in these two
methods should be fairly lightweight.

The following diagram illustrates these loops and the pa
ths an activity
may take between states. The colored ovals are major states the activity
can be in. The square rectangles represent the callback methods you can
implement to perform operations when the activity transitions between
states.

Accident and Emergency
-

Patient Management System


21




Whenever there's a request that should be handled by a particular
component, Android makes sure that the application process of the
component is running, starting it if n
ecessary, and that an appropriate
instance of the component is available, creating the instance if necessary.



Accident and Emergency
-

Patient Management System


22


2.6

P
ROCESSES AND LIFECYC
LES

The Android system tries to maintain an application process for as long as
possible, but eventually it will need to rem
ove old processes when
memory runs low. To determine which processes to keep and which to
kill, Android places each process into an "importance hierarchy" based on
the components running in it and the state of those components. Processes
with the lowest im
portance are eliminated first, then those with the next
lowest, and so on. There are five levels in the hierarchy. The following list
presents them in order of importance:

1.

A foreground process is one 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 hold:



It is running an activity that the user is interacting with (the
Activity object's
onResume()

method has been called).



It hosts a service that's bound to the activit
y that the user is
interacting with.



It has a
Service

object that's executing one of its lifecycle callbacks
(
onCreate()
,
onStart()
, or
onDestroy()
).



It has a
BroadcastReceiver

object that's executing its
onReceive()

method.

Only a few foreground processes

will 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 kee
p the
user interface responsive.

2.

A visible process is one 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 holds:



It hosts an activi
ty that is not in the foreground, but is still visible to
the user (its
onPause()

method has been called). This may occur, for
example, if the foreground activity is a dialog that allows the
previous activity to be seen behind it.



It hosts a service that'
s bound to a visible activity.

A visible process is considered extremely important and will not be killed
unless doing so is required to keep all foreground processes running.

Accident and Emergency
-

Patient Management System


23


3.

A service process is one that is running a service that has been
started with t
he
startService()

method and that 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 doing things that the user cares
about (such as playing an mp3 in the b
ackground 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.

A background process is one holding an activity that's not currently
visible t
o the user (the Activity object's
onStop()

method has been called).
These processes have no direct impact on the user experience, and can be
killed at any time to reclaim memory for a foreground, visible, or service
process. Usually there are many backgrou
nd 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 captur
es its
current state, killing its process will not have a deleterious effect on the
user experience.

5.

An empty process is one that doesn't hold any active application
components. The only reason to keep such a process around is as a cache
to improve startu
p 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 upo
n the
importance of the components currently active in the process. For
example, if a process hosts a service and a visible activity, the process will
be ranked as a visible process, not a service process.

In addition, a process's ranking may 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 will always be
considered at least as important as process B.

Because a process running a service is ranked higher than one with
background activities, an activity that initiates a long
-
running operation
mi
ght do well to start a service for that operation, rather than simply
spawn a thread


particularly if the operation will likely outlast the
activity. Examples of this are playing music in the background and
uploading a picture taken by the camera to a web

site. Using a service
guarantees that the operation will have at least "service process" priority,
regardless of what happens to the activity. As noted in the Broadcast
receiver lifecycle section earlier, this is the same reason that broadcast
Accident and Emergency
-

Patient Management System


24


receivers s
hould employ services rather than simply put time
-
consuming
operations in a thread.


2.7

U
SER
I
NTERFACE

In an Android application, the user interface is built using View and
ViewGroup objects. There are many types of views and view groups,
each of which is a d
escendant of the View class.

View objects are the basic units of user interface expression on the
Android platform. The View class serves as the base for subclasses
called "widgets," which offer fully implemented UI objects, like text
fields and buttons. T
he ViewGroup class serves as the base for
subclasses called "layouts," which offer different kinds of layout
architecture, like linear, tabular and relative.

A View object is a data structure whose properties store the layout
parameters and content for a s
pecific rectangular area of the screen. A
View object handles its own measurement, layout, drawing, focus
change, scrolling, and key/gesture interactions for the rectangular area
of the screen in which it resides. As an object in the user interface, a
View

is also a point of interaction for the user and the receiver of the
interaction events

View Hierarchy

On the Android platform, you define an Activity's UI using a hierarchy
of View and ViewGroup nodes, as shown in the diagram below. This
hierarchy tree ca
n be as simple or complex as you need it to be, and
you can build it up using Android's set of predefined widgets and
layouts, or with custom Views that you create yourself.


Accident and Emergency
-

Patient Management System


25


In order to attach the view hierarchy tree to the screen for rendering,
your Activity must call the setContentView() method and pass a
reference to the root node object. The Android system receives this
reference and uses it to invalidate, measur
e, and draw the tree. The
root node of the hierarchy requests that its child nodes draw
themselves


in turn, each view group node is responsible for calling
upon each of its own child views to draw themselves. The children
may request a size and location
within the parent, but the parent object
has the final decision on where how big each child can be. Android
parses the elements of your layout in
-
order (from the top of the
hierarchy tree), instantiating the Views and adding them to their
parent(s). Becaus
e these are drawn in
-
order, if there are elements that
overlap positions, the last one to be drawn will lie on top of others
previously drawn to that space.

Layout

The most common way to define your layout and express the view
hierarchy is with an XML layo
ut file. XML offers a human
-
readable
structure for the layout, much like HTML. Each element in XML is
either a View or ViewGroup object (or descendant thereof). View
objects are leaves in the tree, ViewGroup objects are branches in the
tree (see the View H
ierarchy figure above).

The name of an XML element is respective to the Java class that it
represents. So a <TextView> element creates a TextView in your UI,
and a <LinearLayout> element creates a LinearLayout view group.
When you load a layout resource, t
he Android system initializes these
run
-
time objects, corresponding to the elements in your layout.

For example, a simple vertical layout with a text view and a button
looks like this:

<?
xml version
=
"1.0"

encoding
=
"utf
-
8"
?>

<LinearLayout

xmlns:android
=
"htt
p://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_wi
dth
=
"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_conten
t"













android:text
=
"Hello, I am a Button"

/>

</LinearLayout>

Accident and Emergency
-

Patient Management System


26


Notice that the LinearLayout element contains both the TextView and
the Button. You can nest another LinearLayout (or other type of view
group) inside here, to lengthen the view hierarch
y and create a more
complex layout.

There are a variety of ways in which you can layout your views. Using
more and different kinds of view groups, you can structure child views
and view groups in an infinite number of ways. Some pre
-
defined view
groups off
ered by Android (called layouts) include LinearLayout,
RelativeLayout, TableLayout, GridLayout and others. Each offers a
unique set of layout parameters that are used to define the positions of
child views and layout structure.

Widgets

A widget is a View o
bject that serves as an interface for interaction
with the user. Android provides a set of fully implemented widgets,
like buttons, checkboxes, and text
-
entry fields, so you can quickly build
your UI. Some widgets provided by Android are more complex, like

a
date picker, a clock, and zoom controls. But you're not limited to the
kinds of widgets provided by the Android platform. If you'd like to do
something more customized and create your own actionable elements,
you can, by defining your own View object or

by extending and
combining existing widgets.


2.8

U
SING THE
C
AMERA


The popularity of digital cameras (particularly within phone handsets)
has caused their prices to drop just as their size has shrunk
dramatically.

To access the camera hardware, you need to a
dd the CAMERA
permission to your application manifest, as shown here:


<uses
-
permission android:name=”android.permission.CAMERA”/>

This grants access to the Camera Service. The Camera class lets you
adjust camera settings, take pictures, and manipulate str
eaming
camera previews.

To access the Camera Service, use the static open method on the
Accident and Emergency
-

Patient Management System


27


Camera class. When your application has finished with the camera,
remember to relinquish your hold on the Service by calling release
.


The Camera Parameters can be used

to specify the image and preview
size, image format, and preview frame rate.


Using the Camera Preview


Access to the camera’s streaming video means that you can incorporate
live video into your applications. Some of the most exciting early
Android applic
ations have used this functionality as the basis for
augmenting reality.

The camera preview can be displayed in real time onto a Surface.


You can also assign a PreviewCallback to be fired for each preview
frame, allowing you to manipulate or display each
preview frame
individually. Call the setPreviewCallback method on the Camera
object, passing in a new PreviewCallback implementation overriding
the onPreviewFrame method.

Taking a Picture
:


Take a picture by calling

takePicture


on a Camera object, passin
g in a
ShutterCallback and PictureCallback implementations for the RAW
and JPEG
-
encoded images. Each picture callback will receive a byte
array representing the image in the appropriate format, while the
shutter callback is triggered immediately after the
shutter is closed.


2.9

U
SING THE
B
LUETOOTH

To broadcast
messages using the device

s Bluetooth capabilities to
Generic devices (not only Android devices), the Android operating
system facilitates the developers to use the “
Intent
” class.

An intent is an abstr
act description of an operation to be performed. It
can be used with startActivity to launch an Activity, broadcastIntent to
send it to any interested BroadcastReceiver components, and
startService(Intent) or bindService(Intent, ServiceConnection, int) to
communicate with a background Service.

Accident and Emergency
-

Patient Management System


28



An Intent provides a facility for performing late runtime binding
between the code in different applications. Its most significant use is in
the launching of activities, where it can be thought of as the glue
betwee
n activities. It is basically a passive data structure holding an
abstract description of an action to be performed. The primary pieces
of information in an intent are:


A
ction

--

The general action to be performed, such as ACTION_VIEW,
ACTION_EDIT, ACTION
_MAIN, etc.

D
ata

--

The data to operate on, such as a person record in the contacts
database, expressed as a Uri.


Intent Resolution

There are two primary forms of intents you will use.

Explicit Intents have specified a component (via
setComponent(Compone
ntName) or setClass(Context, Class)), which
provides the exact class to be run. Often these will not include any
other information, simply being a way for an application to launch
various internal activities it has as the user interacts with the
applicatio
n.

Implicit Intents have not specified a component; instead, they must
include enough information for the system to determine which of the
available components is best to run for that intent.


There are three pieces of information in the Intent that are
used for
resolution: the action, type, and category. Using this information, a
query is done on the PackageManager for a component that can handle
the intent. The appropriate component is determined based on the
intent information supplied in the AndroidMa
nifest.xml file as follows:

The action, if given, must be listed by the component as one it handles.

The type is retrieved from the Intent's data, if not already supplied in
the Intent. Like the action, if a type is included in the intent (either
Accident and Emergency
-

Patient Management System


29


explicitl
y or implicitly in its data), then this must be listed by the
component as one it handles.


For data that is not a content: URI and where no explicit type is
included in the Intent, instead the scheme of the intent data (such as
http: or mailto:) is consid
ered. Again like the action, if we are matching
a scheme it must be listed by the component as one it can handle.

The categories, if supplied, must all be listed by the activity as
categories it handles. That is, if you include the categories
CATEGORY_LAU
NCHER and CATEGORY_ALTERNATIVE, then
you will only resolve to components with an intent that lists both of
those categories. Activities will very often need to support the
CATEGORY_DEFAULT so that they can be found by
Context.startActivity().

Intene ACTION
_SEND:

The intent’s send action is what we are more interested in. This action
polls

the Androids
daemon applications

that can handle the item


based on the type property
and allows the user to pick the Bluetooth
device from the action list. This further
takes the user to the
destination

client

device picker
screen where the user can search for any Bluetooth
device that is discoverable.


2.10

U
SER
I
NTERFACE
C
ONTROLS
U
SED


1)

Image View Class:

The ImageView class is used to d
isplays an arbitrary image, such as an
i
con. The ImageView class can load images from various sources (such
as resources or content providers), takes care of computing its
measurement from the image so that it can be used in any layout
manager, and provides various display options such as scalin
g and
tinting.

2)

Gallery Class:

The Gallery class is a

view that shows items in a center
-
locked,
horizontally scrolling list.

Accident and Emergency
-

Patient Management System


30


The default values for the Gallery assume you will be using
Theme_galleryItemBackground as the background for each View given
to th
e Gallery from the Adapter. If you are not doing this, you may
need to adjust some Gallery properties, such as the spacing.

Views given to the Gallery should use Gallery.LayoutParams as their
layout parameters type.


3)

Linear

Layout
Class:

A Layout that arr
anges its children in a single column or a single row.
The direction of the row can be set by calling
setOrientation()
. You can
also specify gravity, which specifies the alignment of all the child
elements by calling
setGravity()

or specify that specific c
hildren grow
to fill up any remaining space in the layout by setting the
WEIGHT

member of
LinearLayout.LayoutParams
. The default orientation is
horizontal.


4)

Tab Host

Class:

Container for a tabbed window view. This object holds two children: a set of
tab la
bels that the user clicks to select a specific tab, and a FrameLayout object
that displays the contents of that page. The individual elements are typically
controlled using this container object, rather than setting values on the child
elements themselves.

Tab Spec

A tab has a tab indicator, content, and a tag that is used to keep track of
it. This builder helps choose among these options. For the tab indicator,
your choices are: 1) set a label 2) set a label and an icon For the tab
content, your choices ar
e: 1) the id of a
View

2) a
TabHost.TabContentFactory

that creates the
View

content. 3) an
Intent

that launches an
Activity
.

5)

Tab Widget
:

Displays a list of tab labels representing each page in the parent's tab
collection. The container object for this wid
get is
TabHost
. When the user
selects a tab, this object sends a message to the parent container, TabHost, to
tell it to switch the displayed page. You typically won't use many methods
directly on this object. The container TabHost is used to add labels, a
dd the
callback handler, and manage callbacks. You might call this object to iterate
Accident and Emergency
-

Patient Management System


31


the list of tabs, or to tweak the layout of the tab list, but most methods should
be called on the containing TabHost.

6)

Toast
:

A toast is a view containing a quick little
message for the user. The
toast class helps you create and show those.

When the view is shown to the user, appears as a floating view over
the application. It will never receive focus. The user will probably be in
the middle of typing something else. The
idea is to be as unobtrusive as
possible, while still showing the user the information you want them to
see. Two examples are the volume control, and the brief message
saying that your settings have been saved.

The easiest way to use this class is to call

one of the static methods that
constructs everything you need and returns a new Toast object.


7)

Table View
:

A layout that arranges its children into rows and columns. A Table
Layout consists of a number of TableRow objects, each defining a row
(actually, y
ou can have other children, which will be explained below).
Table Layout containers do not display border lines for their rows,
columns, or cells. Each row has zero or more cells; each cell can hold
one View object. The table has as many columns as the row

with the
most cells. A table can leave cells empty. Cells can span columns, as
they can in HTML.

The width of a column is defined by the row with the widest cell in
that column. However, a Table Layout can specify certain columns as
shrinkable or stretcha
ble by calling setColumnShrinkable() or
setColumnStretchable(). If marked as shrinkable, the column width can
be shrunk to fit the table into its parent object. If marked as stretchable,
it can expand in width to fit any extra space. The total width of the

table is defined by its parent container. It is important to remember
that a column can be both shrinkable and stretchable. In such a
situation, the column will change its size to always use up the available
space, but never more. Finally, you can hide a
column by calling
setColumnCollapsed().

The children of a TableLayout cannot specify the layout_width
attribute. Width is always MATCH_PARENT. However, the
layout_height attribute can be defined by a child; default value is
Accident and Emergency
-

Patient Management System


32


WRAP_CONTENT. If the child is a
TableRow, then the height is
always WRAP_CONTENT.

Cells must be added to a row in increasing column order, both in code
and XML. Column numbers are zero
-
based. If you don't specify a
column number for a child cell, it will autoincrement to the next
availab
le column. If you skip a column number, it will be considered
an empty cell in that row. See the TableLayout examples in ApiDemos
for examples of creating tables in XML.

Although the typical child of a TableLayout is a TableRow, you can
actually use any Vi
ew subclass as a direct child of TableLayout. The
View will be displayed as a single row that spans all the table columns.

Accident and Emergency
-

Patient Management System


33



C
HAPTER
3



A
PPLICATION

D
ESIGN
A
ND
I
MPLEMENTATION


3.1

S
UMMARY

.

3.2

U
NDERSTANDING THE
C
ODE

.

3.2.1

S
OFTWARE
D
ESIGN

.

3.2.1.1

S
AMPLE



3.2.2

A
PPLICATION

L
AYOU
T


3.5

C
ONCLUSION

.








REFERENCES

Accident and Emergency
-

Patient Management System


34




A
PPENDIX


S
OURCE
C
ODE