Multi-Client Single Server Teaching Aid with

Integrated Attendance Marking System

(AMS) based on Android

A project report submitted in partial fulfillment of the requirements for

B.Tech. Project

B.Tech.

by

Ankit Bansal (2013IPG-20)

Ansul Sharma (2013IPG-25)
Ashish Krishna (2013IPG-28)

ABV INDIAN INSTITUTE OF INFORMATION

TECHNOLOGY AND MANAGEMENT
GWALIOR-474 010

2016
 i

CANDIDATES DECLARATION

We hereby certify that the work, which is being presented in the report, entitled Multi-
client, Single Server Teaching Aid with Integrated Attendance Management Sys-
tem based on Android, in partial fulfillment of the requirement for the award of the
Degree of Bachelor of Technology and submitted to the institution is an authentic
record of our own work carried out during the period May 2016 to September 2016 un-
der the supervision of Prof. Aditya Trivedi and Dr. Wilfred Godfrey. We also cited
the reference about the text(s)/figure(s)/table(s) from where they have been taken.

Date: Signatures of the Candidates

This is to certify that the above statement made by the candidates is correct to the best
of my knowledge.

Date: Signatures of the Research Supervisors

Date: Signatures of the Research Supervisors

 ii

ABSTRACT

Representing more than half of the presently used hand-held gadgets, Android, as an
Operating System, has provided clients with a great chance to implement, innovate
and initiate a great number of things, right from the comforts and convenience of their
cell-phones. Beginning as a phone OS, the variety of gadgets compatible with Android
is guiding the business sector towards greater PC involvement in mobile computing,
with grapevines suggesting that Intel and some of its partners are working on some lap-
top prototypes running on Atom Processors. Thus the requirement for versatility and
mobility has ascended quickly. Individuals have begun creating applications for every
other need. The first part of the project involves Android Application Development of a
teaching aid implementation based on Multiple Screen Casting technology that serves
to ease the task of teachers/professors as well as the students by opening up a more
dynamic and efficient communications bridge between the two. The slides presented
by professors are wirelessly routed to android devices of students, with an option to
register doubts as well. Moreover, the application also features a floating canvas over
the slides that empower professors to write/draw upon slides, and the same would also
be transmitted to the students device. This will usher in more productive teaching ses-
sions, as well as reducing the effort by a great extent. The second part of the project
involves introducing a whole new Attendance System for use in ABV-IIITM Gwalior,
using Android enabled devices boasting of many features such as batch and subject
segregation. This would serve as an effective management tool resulting in the reduc-
tion of the no. of man hours spent in managing the attendance for each of the subjects
for the semester. The professors wont have to do double the work, i.e. take pen paper
attendance and then upload onto the machines. A simple, easy to use interface makes
attendance marking a much more lucid experience, and is surely one trouble lessened
for our esteemed faculty members.

Keywords: Multi Screen, Screen Casting, Socket Programming, Service Applica-

tion, FTP, Servers.
 iii

ACKNOWLEDGEMENTS

We would like to express our utmost gratitude to Prof. Aditya Trivedi and Dr. Wilfred
Godfrey for having faith in us and allowing us to carry out a project on a technology
that was quite challenging. They helped massively by directing us over the course of
the undertaking, motivating us to take up new difficulties along the road, and simultane-
ously, providing us with most valuable suggestions and constructive criticisms. Despite
having a hectic schedule and very little time at their disposal, they always had time to
listen to us and solve our problems, even suggesting valuable modifications to the appli-
cation system. This application, in its totality, owes its very existence to them, and we
can never thank them enough for making this journey of making an android application
from scratch worthwhile and immensely fruitful. Thank you sirs.
We also extend our heartfelt thanks to all well wishers and peers who in some way
or the other were part of the application making process, however small or big it may be.
Lastly, we owe a big thank you to our institute for providing us with the opportunity of
making an application that would help make a difference in our immediate surrounding,
and benefit a large number of people.
(Ashish Krishna) (Ansul Sharma) (Ankit Bansal)
Contents

ABSTRACT ii

LIST OF TABLES v

LIST OF FIGURES vi

1 INTRODUCTION 2
1.1 Need for a new Application . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Pre-existing Applications . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Drawbacks of pre-existing apps . . . . . . . . . . . . . . . . . 3
1.1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Strengths of the new Application . . . . . . . . . . . . . . . . . 4
1.2 Multi-Screen Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 General Constraints . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 IIITM Gwalior Attendance Marking System in Android . . . . . . . . . 6
1.3.1 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Application Overview . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2.1 General Constraints . . . . . . . . . . . . . . . . . . 7
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Report Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 MULTI-SCREEN CASTING AND IMPLEMENTATION 9

2.1 Multi-Screen Cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Authentication Module . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Doubt Module . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Interchange Module . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 FTP Server Module . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 UML and related Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 16

iv
CONTENTS v

2.5 Major Classes Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Workflow Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 IIITM GWALIOR ATTENDANCE MARKING SYSTEM 24

3.1 Need for the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Present Attendance Marking System in IIITM Gwalior . . . . . 24
3.1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Strengths of the app . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Attendance Module . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Major Classes used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Workflow Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 RESULTS 29
4.1 Technical Implementation-Technologies Used . . . . . . . . . . . . . . 29
4.1.1 Android Studio IDE and ADT . . . . . . . . . . . . . . . . . . 29
4.1.2 Apache Server . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.3 PHP Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.4 MySQL Database . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.5 Screencast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.6 Socket Programming . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.7 Other tools used . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 UI Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Master Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Receiver Side . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 DB Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 CONCLUSION AND FUTURE SCOPE 46

5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.1 Comparison with other applications . . . . . . . . . . . . . . . 46
5.2 Future Enhancement and Scope . . . . . . . . . . . . . . . . . . . . . . 48

REFERENCES 48
List of Tables

5.1 Feature Comparison Table . . . . . . . . . . . . . . . . . . . . . . . . 47

vi
List of Figures

1.1 Pre-Existing Applications. . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Authentication Process Flow Diagram. . . . . . . . . . . . . . . . . . . 10

2.2 Doubt Module Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Interchange Module Diagram. . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Master Interface Design. . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Client Interface Design. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Sender Side ER Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Class Diagram 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Sender Module Workflow. . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Receiver Module Workflow. . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 Doubt Module Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Working Diagram of Attendance Module . . . . . . . . . . . . . . . . 26

3.2 Workflow of Attendance Module . . . . . . . . . . . . . . . . . . . . . 28

4.1 a. Splash Screen || b. Set Port Screen || c. Set Port Dialog || d. M Cast
Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 a. Browsing and selecting PDF file || b. Demonstration of Canvas-
Fetching pre saved canvases || c. Attendance Menu || d. Registration of
New Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 a. Selecting Class and Mode of Attendance || b. Submit Attendance ||
c. Submit Attendance || d. Take Attendance(Mark As Present) . . . . . 35
4.4 a. Attendance List || b. Download as CSV file || c. Options for sharing
CSV file || d. View Attendance by Date Dialog . . . . . . . . . . . . . 36
4.5 a. Attendance of the date fetched || b. Dialog to download from web ||
c. Webview opened for download || d. Reseting Progress Dialog . . . . 37
4.6 a. View of doubt || b. Demonstration of interchange module || c. Master
Privileges granted to client . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 a. Login/Registration Page || b. Register Form || c. Login Form || d. C
Cast Home Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vii
LIST OF FIGURES 1

4.8 a. Ask Doubt Dialog || b. View/Delete Doubt Dialog || c. Notification

for master privilege || d. Menu displayed after interchange . . . . . . . 40
4.9 Structure of Clients Database . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Structure of Doubts Table . . . . . . . . . . . . . . . . . . . . . . . . 42
4.11 Structure of Datewise attendance database . . . . . . . . . . . . . . . . 43
4.12 Structure of Table for attendance for a particular class . . . . . . . . . 44
4.13 Main Databases that has all tables . . . . . . . . . . . . . . . . . . . . 45

ABBREVIATIONS

ADT Android Development Tools

DBMS Database Management System
EDGE Enhanced Data for GSM Evolution
GPRS General Packet Radio Service
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
JSON JavaScript Object Notation
OTP One Time Password
PHP Hypertext Preprocessor
SDK Software Development Kit
Chapter 1

INTRODUCTION

This chapter includes the details of Screen Casting, Multi Screen Casting, Attendance
Marking System (AMS), other related existing applications and the need thus, for mak-
ing this application. This would further elucidate in the best manner possible, the major
identified objectives of the project.

1.1 Need for a new Application

In this section, we will briefly describe some of the existing applications that can be
considered as worthy competitors to the developed application, and later discuss why a
new application was developed in the face of other pre-existing apps.

1.1.1 Pre-existing Applications

(i) Lensoo Create: This application is a classroom solution which essentially a
whiteboard, offering voice recording and digital writing. The session is recorded
in the form of a video which then can be uploaded on a website, thus reaching a
larger audience. It also supports advanced graphic options.

(ii) Explain Everything: This is a popular educational aid application that is helpful
in teaching sessions. It functions as a collaborative and interactive whiteboard
with advanced canvas options that can be used to record interactive sessions and
later uploaded at one s convenience.

(iii) All Cast: This is a screen casting application that supports multimedia streaming
to devices. Files like video and images can be streamed live to a device from a
source device. Only one client is supported at a time. Transactions happen over
Wi-Fi network.

2
CHAPTER 1. INTRODUCTION 3

(iv) Educreations: This application records screen animations and also functions like
a whiteboard which is used to capture screen drawings. The main drawback of
the application is that it is supported only on iPads.

(v) VideoScribe HD: This application is one of the pioneer applications in the do-
main of whiteboard animation, or fast drawing, as it is called. It has proven very
useful in teaching/classroom related activities.

Figure 1.1: Pre-Existing Applications.

1.1.2 Drawbacks of pre-existing apps

Most the applications have been traditionally limited to the whiteboard model, with
greater emphasis over presentation of recorded sessions. All the applications discussed
in the previous applications are yet to offer an integrated application system with fea-
tures that might prove beneficial in a traditional classroom environment. The same
unexplored avenues have been turned in to strengths of the new application, which will
be taken in great detail in future sections.

1.1.3 Objectives
The following are the broad objectives of the application based on the above discussion:

(i) To make a classroom friendly application that revolutionalizes the way things are
taught.

(ii) Maximum utility for stakeholders, i.e. Professors and Students.

(iii) Finding a way out for the students to reach out to professors with their doubts in
the most subtle and efficient manner.

(iv) Cut down on time consuming class-activities so as to improve productivity.

CHAPTER 1. INTRODUCTION 4

(v) Exploit digital technology for a better classroom environment.

1.1.4 Strengths of the new Application

Though there are pre-existing apps in this domain that have indeed made lives of all
stakeholders, be it professors or students, a lot easier, there still lay avenues that were
not yet explored. In todays information age, when man seeks and expects even more
convenience from technology, it becomes of the same to provide him with it. The same
spirit has been our principle guiding force while making this app. We enlist some of the
features that have not been seen on any application till date, and are one of the major
pros of the new applications.

(i) Ability to cast to multiple clients: All the pre-existing applications have casting
capability limited to just one screen. The new application is based on a revo-
lutionary new concept, that of simultaneously casting to multiple screen over a
Wi-Fi Network. Video/Screen Content can be simul-casted to client devices very
efficiently and fast.

(ii) Integrated Doubt Module: The app also features of an integrated doubt mod-
ule, which works in two ways: It guarantees total anonymity to students asking
questions thus doing away with the problem of groupthink and shyness, and also
facilitates the professors in efficient redressal of doubts. This module is unheard
of in any other application.

(iii) Interchange Module: This empowers the client devices to switch places with
the master device by gaining master privileges temporarily. The privileges are
granted by the master device and are subject to master s consent. The master, if
it wishes, might withdraw privileges at any given point of time. This helps any
student to broadcast his/her screen to the class in an even of mass-doubt, and get
the same resolved by the master.

(iv) Integrated Attendance Module: The application aims to be a complete solution

to day to day classroom issues. It also tackles the menace of tiresome activities
like attendance marking by simplifying the process. We will further delve into
this in subsequent sections.

(v) Security and Privacy: Most of the communications that is involved in this ap-
plication is encrypted with MD-5 encryption thus guaranteeing greater security.
Also the registration and login modules guarantee security to the users.

(vi) Network Connectivity: The application has been optimised for superior perfor-
mance on a Wi-Fi network. The same will be discussed later.
CHAPTER 1. INTRODUCTION 5

(vii) Canvas Overlay: The application features a canvas on top of a presentation being
casted live to devices, that acts as a floating whiteboard, a concept unheard of
before. This will be taken in greater detail in succeeding sections.

For further simplification, the application has been bifurcated in to 2 broad divisions,
which are listed in the succeeding sections.

1.2 Multi-Screen Casting

This section deals with the Multi-Screen casting feature of the application in brief.

1.2.1 Problem Formulation

The new application is a service based application which helps in enhancing a class-
room experience. It does this by replicating the slides being displayed on a master
device to many client devices. The application also features a basic canvas, upon which
things can be drawn/written; the same is transmitted to all client devices connected to
the master device. Some Key points about the App:

(i) Screen sharing (Multicasting Node screen to clients) for classroom slideshows.

(ii) Doubt removal (Queuing up doubts for resolution with absolute privacy)

(iii) Secure duplex communication

(iv) Ability to draw upon the canvas/slides and the same being relayed to client devices
in real time.

This application deploys use of socket programming along with a host of APIs. In
particular, we have used ScreenCast Libraries, tweaking it a little bit for faster per-
formance, and enabling multi-client support as the library only supports single client
streaming. Also, use of Gesture libraries has been made for the sake of Canvas editing.
We have utilized an Apache Server with PHP and MySQL support for remote database
use. The information exchange to or from the database happens with the assistance of
PHP scripts and as JSON objects. The android end of the user application handles these
JSON objects through HTTP clients.

1.2.2 General Constraints

Hardware

(a) Any Android Enabled Handheld (running on Android v5.0 and above)
CHAPTER 1. INTRODUCTION 6

(b) Any Android Enabled Tablet PC (Master device)

Software

(a) Server-Side Requirement : Web Server - Apache 1.2, Apache 2.x

(b) Server-Side Requirement : Database Server - MySQL 4.1 or higher

(c) Server-Side Requirement : PHP - PHP 4.4.0 or higher (5.2 recommended)

(d) Hosting Site: ecowebhosting.uk

(e) Client End : Network Enabled system with Android Studio and ADT Plug-in (for
emulator use and debugger)

1.3 IIITM Gwalior Attendance Marking System in An-

droid
This section deals with the Attendance Marking feature of the application in brief.

1.3.1 Problem Formulation

The Application, Attendance Marking System has been primarily designed for use of
professors of IIITM Gwalior which would help them in efficiently managing attendance
related functions for students enrolled in different programmes. The current prevailing
system requires the faculty members/professors to do the following:

(i) Taking physical attendance first.Taking physical attendance first.

(ii) Then, forward the attendance records to the concerned authority (Administra-
tive/Academic Section).

(iii) Digital attendance is limited till now to M.Tech/Ph.d scholars for issues related to
stipends, and is yet to be implemented in day to day classes.

(iv) The digital attendance till date is in the form of biometric imprint, and is used on
a very limited scale.

The above process may be simplified by:

(i) Moving the present attendance system to mobile devices

(ii) The lodged attendance with the help of mobile device would be immediately for-
warded to the database via network connectivity

(iii) Attendance/Absence marked through simple user interface employing colour schemas
making the experience hassle free
CHAPTER 1. INTRODUCTION 7

1.3.2 Application Overview

The application in this manner created would go far in lessening the man hours spent
in overseeing/managing the attendance of around 1000 students. Simple push action on
the buttons against the enrolment numbers of students pertaining to different branches
would mark the attendance of the student. A reed colour against the enrol. number
would easily indicate the absence of student. Also, there is scope of accommodat-
ing students from different branches in a single classroom in case of such eventuality.
Date-wise checking of attendance of any class/session is further made possible, and the
application is built in a way that it might function in two ways: either marking students
absent which are by default all absent or marking students present who all are by default
absent. The application also supports exporting attendance of any class in .CSV0 for-
mat which increases portability and support. We were guided by Ableson et al. (2009),
Rogers et al. (2009), Lee (2012), Murphy (2009), Murphy (2010) and Meier (2012) in
this endeavor.

1.3.2.1 General Constraints

(i) Hardware

(a) Any Android Enabled Handheld (running on Android v5.0 and above)

(ii) Software

(a) Server Side : Web Server - Apache 1.2, Apache 2.x

(b) Server Side : Database Server - MySQL 4.1 or higher
(c) Server Side : PHP - PHP 4.4.0 or higher (5.2 recommended)
(d) Client End : Network Enabled system with Android Studio and ADT Plug-in
(for emulator use and debugger)

1.4 Summary
This chapter managed questions like why the application was made and what does it
stand for. Outline or general working standards have been given. The issue proclama-
tion for each has been itemized and dissected well. The nature of these prototypes has
been clarified. A presentation into why Android was chosen as target OS has addition-
ally been given.
CHAPTER 1. INTRODUCTION 8

1.5 Report Organization

The accompanying postulation has been composed in order to give an unmistakable
perspective of what and how the application acts. Chapter 1 gives a prologue to why
the application was made in the first place. It likewise explains to regarding why the ap-
plication is superior to its competitors and to what ends the applications are required in
addition to the extent of the applications. Section 2 talks in insights about Multi-Screen
Casting application. It gives a reasonable perspective as to each part of the application
beginning from the outline stage to the testing and recreation on an emulator. Section 3
gives a point by point depiction about the IIITM Gwalior Attendance Marking system
ported to an Android gadget. We can discover a portrayal of the applications capacities
and the product/equipment requirements assuming any. All Emulator and live device
use were shown with screenshots of every conceivable info and results. Part 4 of the
report discusses the implementation side of the application, wherein the various tools
used for development have been discussed. Part 5 deals with the future scope of the
application and conclusion of the report.
Chapter 2

MULTI-SCREEN CASTING AND

IMPLEMENTATION

This section will broadly deal with the first part of the application developed, which is
screen casting to many clients at a given point of time. The chapter will also discuss
the various modules involved in greater details.

2.1 Multi-Screen Cast

This section would deal with the screen casting feature of the application in greater
detail.
Screen Casting: About the technology
The method is used to mirror a screen from host device/master device to client de-
vices. The client device receives live stream of screen content from the master device
along with live streams of canvas overlay that shows any text/drawing created by pro-
fessors in real time. Only one client is traditionally supported via this media, i.e. a
master device can mirror its screen to just one device at a time. The data transmitted is
encrypted for enhanced security and zero risk.
Multi Screen Casting
An implementation of Screen Casting that enables screen mirroring/casting to mul-
tiple client devices from master device at a time. This is a new revolutionary take at
Screen Casting that forms the very base of the application and its core functions.

2.2 Modules
This section describes the modules used in the Multi-Screen Casting feature of the
application in greater detail.

9
 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 10

2.2.1 Authentication Module

ule 1.png Module 1.png

Figure 2.1: Authentication Process Flow Diagram.

This module takes care of the authentication part involved in the Multi-Screen Casting
process. As elucidated in the figure 2.1, the authentication process is carried out in the
following manner:

(a) The user registers first with his/her data.

(b) User is also provided with a Port number by the master device which serves as a
OTP for the particular class the user wishes to be a part of. The same gets registered
in the database.

(c) Prior to this, the Master device resets all IPs which might get retained in the
database from the previous sessions.

(d) The user now logs into the session by the credentials used while registering.
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 11

2.2.2 Doubt Module

Figure 2.2: Doubt Module Diagram.

This module deals with the doubts that might arise from the clients side. As shown in
figure, it is done in the following way:

(a) The client device enters a doubt.

(b) The doubt gets registered on the master device, and is maintained in the form of a
queue.

(c) The client may view his/her doubts at any point of time by pressing the View
Doubts button.

(d) The client may choose to delete his/her doubts at any point of time by long pressing
the registered doubt in the View Doubt menu.

The things on the Master Device side are a little different. The same have been enu-
merated as below:

(a) The master device can view doubts registered by all client devices via View Doubt
Button.

(b) The Master device may choose to remove an active registered doubt by long press-
ing the doubt in the view doubts menu.

The doubts can be lodged with the master device using this module in a safe and
secure way. The doubts are registered to the master device through MD-5 encryption,
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 12

hence leading to a faster, more secure 2-way communication. The Master device also
yields the power to discard the doubts from active list upon its successful redressal.
Also, the application gives the power to client devices to assume temporarily role of a
master device for casting of client screen to other client and master screens (Interchange
module) which will be dealt in detail in the next section.
Figure 2.2 depicting the above features have been shown for convenience.

2.2.3 Interchange Module

Figure 2.3: Interchange Module Diagram.

This Module deals with the interchange procedure involved in the screen casting pro-
cessing. In this process, the master privileges to cast to all client devices are temporarily
bestowed upon a chosen client device, which then moves forward to cast upon success-
fully receiving a notification. The details have been enumerated as below:

(a) The client which is to assume Master Privileges sends its IP to the server which
relays it to the Master Device.

(b) The Master device then saves the IP address of the client.

(c) The Master then sends its IP address to the server, which relays the same to the
client device which is to assume master privileges.

(d) The client then saves this IP address. Status is set to 1, which triggers a notification.

(e) Upon receiving the notification, the casting process initiates in 10-15 seconds.
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 13

The same have been elucidated in greater detail in figure 2.3.

2.2.4 FTP Server Module

This module ensures the files in use are transferred to/from the FTP server. This helps
users in the following ways:

(a) The files in use are not required to be stored on the device. They might be fetched
from the server conveniently.

(b) During interchange process, the client which has assumed master privileges might
not have the presentation stored locally. It may fetch the same from the FTP server.
 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 14

2.3 Interface Design

This section deals with the interface design of the application. We first deal with the
Master Interface Design.

aster 1.png

Figure 2.4: Master Interface Design.

As shown in figure 2.4, the primary interface design for the master device features
3 subdivisions. The first one deals with the authentication process, the second one
with the functions related to screencast, and the third one deals with the IP addresses
and database transactions. Splash screen implementation for Master Interface has been
inspired from AndroidHive.info (2016).
 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 15

g Receiver 1.png

Figure 2.5: Client Interface Design.

Figure 2.5 shows the client interface design, which again has 2 broad subdivisions.
One pertaining to the registration process and the other with the logging in process.
Both have been demonstrated clearly in the figure.
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 16

2.4 UML and related Diagrams

Figure 2.6: Sender Side ER Diagram.

The above diagram, Figure 2.6, is a Use Case Diagram of the Multi-Screen Cast-
ing. Standard notations and symbols have been used, depicting the intricate relation-
ship between various classes such as MainActivity, EncodingAsyncTask, VideoChunk,
SenderAsyncTask etc. as shown.
 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 17

png

Figure 2.7: Class Diagram 2

Figure 2.7 describes relationships between classes and entities used in the making
of the app, as is clear from the same. Requisite labeling has been done for simplification
of explanation.

2.5 Major Classes Used

Some of the classes used while making this part of the application, and their use have
been discussed in this section.
a. CanvasMain.java

(a) Creates a canvas outlay over the slides for editing/drawing.

CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 18

(b) Contents of the canvas are then further sent to all client devices.

(c) The canvas also has advanced editing features such as Pen color, Change from pen
to eraser, option to select between already saved canvas etc.

b. VideoChunk.java

(a) Divides video into chunks.

(b) The chunks are further sent to destination device.

c. PdfFileRenderer.java

(a) Renders the PDF files into images suitable for streaming through screen casting.

(b) The rendered images are sent sequentially so as to imitate a video.

d. FileBrowser.java

(a) Helps pick documents/slides (pdf) from local storage

(b) Also helps pick downloaded files from local storage

e. EncoderAsyncTask.java

(a) The video chunks are divided and then further converted to format fit for transmis-
sion through socket programming.

(b) Utilises an active connection such as Wi-Fi for communication through socket pro-
gramming.

f. JSONParser.java

(a) JSON stands for JavaScript Object Notation is the most popular way to serialize
and transmitting data over network. In android, application uses JSON to transmit
data over networks and JSON data is parsed, while it is received from cloud servers
and from some where else.

(b) JSON provides data in form of object that is to be parsed while reading from source
and a JSON object is created, whenever data is to be transmitted over network or
any source to destination.

(c) If function is -POST-, then a HTTP Client sends instructions that is contained in
params to the remote server. which is designated by url. The received response doe
contains no appreciable data apart from success or failure execution information
when this connection method is used.
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 19

(d) If function is -GET-, then a HTTP Client sends information that is contained in
params to the remote server, which is designated by url. The response is received
from the server having the required data when this connection method is used.

(e) The received response is built to string-text and encoded into the JSON format
which is parsed later by other objects to retrieve information.

g. SenderAsyncTask.java

(a) The data is received post encoding from Encoder AsyncTask.

(b) This data is then sent via Socket Programming to multiple devices.

(c) The recipient devices are the ones connected to the active network, hence utilising
the sockets.

(d) This hence sends the encoded data for rendering on client devices.

h. FTPServer.java
This helps put the selected file on the FTP server for further transmission to client
devices.
i. WebDownload.java

(a) This allows master device to download a file which is not present on local storage
from internet (third party source).

(b) It brings in more flexibility in presenting slides.

j. MakeMaster.java

(a) This class involves transfer of powers of master device to a client device.

(b) A client device might assume role of a master device temporarily in order to demon-
strate an item of importance to all other client devices and the master device.

k. ResetSession.java

(a) This class resets the active session.

(b) Facilitates the creation of a new session

l. ReceiverAsyncTask.java

(a) The encoded video chunks that are sent from the master device to the client device
are received at the client end.
CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 20

(b) This is done via socket programming, utilizing a port number (OTP).

m. CreateDoubt.java

(a) This class facilitates the creation of a new doubt by a client.

(b) The doubts hence created are maintained in the form of a queue at the master device
end.

(c) Parameters like Nature of doubt, Name are to be entered, and a time stamp is added.

(d) Doubts registered via service application.

n. ViewDoubt.java

(a) This class facilitates viewing of doubts at the master device end.

(b) All active doubts are shown on the master device upon clicking the required button.

(c) Options to remove/delete a doubt from the queue upon its successful resolution is
also made available.
 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 21

2.6 Workflow Sequences

To start the process of casting to multiple devices, the following needs to be done, and
in the same manner as shown in Figure 2.8.

Module.pdf Module.pdf

Figure 2.8: Sender Module Workflow.

 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 22

The process at the receiver side (or the client device) via ScreenReceiverTest.apk is
also shown in Figure 2.9.

Module.pdf Module.pdf

Figure 2.9: Receiver Module Workflow.

 CHAPTER 2. MULTI-SCREEN CASTING AND IMPLEMENTATION 23

Doubt module workflow, and is as shown via diagram in Figure 2.10. The steps for
lodging a doubt and also viewing them, as also described in the preceding sections are
once again shown via workflow diagram.

module.pdf module.pdf

Figure 2.10: Doubt Module Workflow.

2.7 Summary
This chapter dealt with the first half of this project which was casting screen content
from a master device to many client devices. Also, its many features, such as Doubt
module (which facilitates doubt registration by students in real time) and Canvas (which
facilitates drawing/writing over slides in order for the professor to emulate whiteboards-
like experience digitally) were discussed in details along with its software modules. The
screenshots for testing purposes of both the User Interface (UI) and the database have
also been shown in the section.
Chapter 3

IIITM GWALIOR ATTENDANCE

MARKING SYSTEM

This chapter will broadly outline the need for making the Attendance Marking System
(AMS) part of the application and other details. This part of the application is integrated
into the Master Device module of our application.

3.1 Need for the app

This section outlines the need for making a new application, and the external/internal
factors that contribute to the same.

3.1.1 Present Attendance Marking System in IIITM Gwalior

(a) The current attendance system in ABV-IIITM Gwalior is not very efficiently man-
aged, with most of the related work done manually.

(b) Moreover, the digital aspect of the attendance system is limited to the M.Tech stu-
dents/Ph.D scholars in the form of biometric attendance system of which also a
major part is done manually.

(c) The day to day attendance affairs are still taken attended to in the form of pen and
paper attendance marking, which is a painfully slow and erroneous process.

(d) It also tends to take up a lot of useful classroom time which might be put to some
other productive use.

(e) The written system of attendance also generates a lot of paperwork, wasting paper
in the process.

24
CHAPTER 3. IIITM GWALIOR ATTENDANCE MARKING SYSTEM 25

(f) The management of the same becomes very difficult for the designated departments
(Academic/Administration).

(g) Also, accessing the information related to attendance becomes very difficult as it is
very cumbersome to go through so many pages of document.

(h) There is also an associated risk of misplacement and loss of documents.

(i) Next to zero transparency is prevalent in the current system, which is not desirable
at all.

(j) The present system is also not equipped properly to accommodate students from
different course/disciplines in special classes as far as attendance is concerned.

3.1.2 Objectives
(a) To design an application that simplifies the attendance marking process.

(b) The designed application should thereby aim at saving precious time for more im-
portant activities.

(c) The designed application would thus try to usher in greater productivity and effi-
ciency.

(d) The application should offer flexibility to the users in its options.

(e) The application should render attendance in a format hat is readable on other de-
vices/platforms.

3.1.3 Strengths of the app

(a) The AMS features a simple, intuitive UI which easily readable.

(b) The AMS effectively cuts down the large amounts of time taken to register atten-
dance in day to day affairs.

(c) The AMS maintains multiple database for both datewise as well as class-wise at-
tendances, which can be accessed easily at the touch of a button.

(d) The AMS also features an Export as CSV option, which renders the attendance
readable on other devices/platforms as well.

(e) The application offers two modes to take attendance: MARK AS ABSENT and
MARK AS PRESENT, giving more flexibility to the end user.
 CHAPTER 3. IIITM GWALIOR ATTENDANCE MARKING SYSTEM 26

3.2 Modules
This section gives details of the modules used in the Attendance Marking feature of the
application.

3.2.1 Attendance Module

png

Figure 3.1: Working Diagram of Attendance Module

The attendance module works in the following manner:

(a) Firstly, master device registers a classroom by entering its name and the number of
students in the class.

(b) This information is then stored in the database.

(c) The database houses two Tables: One for storing total count of attendance of a
particular class, and the other for storing datewise attendance for the class.

(d) Next, the master moves to mark the attendance of the class.

(e) Master can mark attendance in two modes: MARK AS ABSENT and MARK AS
PRESENT.

(f) Upon selecting the mode and specifying the class, the master then marks attendance
of the class by tapping on the button hence poplated from the database depending
on the total number of students in the class

(g) The marked attendance is then submitted which is reflected in the database.
CHAPTER 3. IIITM GWALIOR ATTENDANCE MARKING SYSTEM 27

(h) Also, the marked attendance can be exported in .CSV format which provides users
with cross platform readability.
The details of the database and its screen-shots have been provided towards the end
of the chapter in section 3.6.

3.3 Major Classes used

Some of the major classes used while making this part of the application have been
described as below:
a. Attend.java
This is the main activity consisting all main menus.
b. CheckAttend.java
This is used to check the total attendance of the class.
c. CheckDateAttend.java
This checks date-wise attendance of the class
f. TakeAttendance.java
This class registers the total attendance of a class on a particular day.
g. Registration.java
. This helps in registering a class for which attendance data is sought.
. For one course, different classes might be registered.
h. PrefManager.java
. Retains user entered data in Shared Preferences.
i. ClassSelection.java
. This selects the students for elective courses.

3.4 Workflow Sequence

This shows the workflow sequence of the attendance module as given in figure 3.2. The
diagram explains the processes taking place in the attendance module as described in
Section 3.2.1.
CHAPTER 3. IIITM GWALIOR ATTENDANCE MARKING SYSTEM 28

Module.pdf Module.pdf

Figure 3.2: Workflow of Attendance Module

3.5 Summary
The chapter dealt with the second part of our project - IIITM Gwalior Attendance Mark-
ing System. This was designed keeping the needs in mind as shown in the previous
sections. The requisite classes were shown for further elucidation, and the sequence
workflow was also shown for in depth analysis of the working of this part of the an-
droid application system. Also, the figures showing the process in greater detail were
elucidated in text.
Chapter 4

RESULTS

This chapter deals with the end-results of the project undertaken.

4.1 Technical Implementation-Technologies Used

The section gives a brief insight into the various technologies used while making this
android project.

4.1.1 Android Studio IDE and ADT

According to GitHub.com (2016), Android Studio is the official integrated develop-
ment environment (IDE) for Android platform development. It was announced on May
16, 2013 at the Google I/O conference. Android Studio is freely available under the
Apache License 2.0.
Android Studio was in early access preview stage starting from version 0.1 in May
2013, then entered beta stage starting from version 0.8 which was released in June
2014. The first stable build was released in December 2014, starting from version 1.0.
Based on JetBrains IntelliJ IDEA software, Android Studio is designed specifically
for Android development. It is available for download on Windows, Mac OS X and
Linux, and replaced Eclipse Android Development Tools (ADT) as Googles primary
IDE for native Android application development.
For android application development, we need to download the Android Develop-
ment Tools (ADT) plug-in for eclipse and install it. After this, we need to run the SDK
manager so as to download the Android SDKs for developing onto newer android OS
versions and also the Google APIs and other support functions so as to use Google
licensed android services like Maps, OAUTH 2.0 etc to full use.
The IDE configuration where we have developed the applications is as follows:
. Android Studio : Version 1.5.1
. ADT Package : Version 23.0.1

29
CHAPTER 4. RESULTS 30

. Android SDK Tools : Revision 23.0.3

. Android SDK Platform-Tools : Revision 23.0.3
. Android Support Library : Revision 23.4.0
. Android SDK Platform : 6.0.1 - API 23 - Revision 2, 5.0.1 - API 21 - Revision 2
. Google APIs : 6.0.1 - API 23 - Revision 2, 5.0.1 - API 21 - Revision 2

4.1.2 Apache Server

According to about.com (2016), Apache is generally recognized as the worlds most
popular Web server (HTTP server). Originally designed for Unix environments, the
Apache Web server has been ported to Windows and other network operating systems.
The name "Apache" derives from the word "patchy" that the Apache developers used
to describe early versions of their software.
The Apache Web server provides a full range of Web server features, including
CGI, SSL, and virtual domains. Apache also supports plug-in modules for extensibility.
Apache is free software, distributed by the Apache Software Foundation that promotes
various free and open source advanced Web technologies.

4.1.3 PHP Scripting

According to NTCHosting.com (2016), PHP was established as the leading website
programming language several years ago, even though it is much younger than other
languages. The cause of the extensive popularity the PHP distribution enjoys is the
easy-to-grasp syntax, allowing even people with no coding experience whatsoever to
quickly enter into the PHP realm. And it is exactly the easily created scripts that make
PHP so popular among the Internet community. PHP was established as the leading
website programming language several years ago, even though it is much younger than
other languages. The cause of the extensive popularity the PHP distribution enjoys is
the easy-to-grasp syntax, allowing even people with no coding experience whatsoever
to quickly enter into the PHP realm. And it is exactly the easily created scripts that
make PHP so popular among the Internet community.

4.1.4 MySQL Database

thesitewizard.com (2016) says, Many computer programs, including web-based pro-
grams like blogs, photo galleries and content management systems need to store and
retrieve data. For example, blog software need to store the posts (ie, articles) one writes,
and retrieve them when a visitor goes to one s site. Similarly, photo galleries store in-
formation about their pictures (for example, for sites that allow users to rate the photos,
the numerical rating for each picture is stored in a database). Instead of reinventing the
CHAPTER 4. RESULTS 31

wheel and implementing their own system of storing and retrieving data, these software
simply use specialised database programs. To make it easy for other programs to access
data through them, many database software support a computer language called "SQL"
(often pronounced as "sequel"). SQL was specially designed for such a purpose. Pro-
grams that want the database software to handle the low-level work of managing data
simply use that language to send it instructions. There are many databases that sup-
port the use of SQL to access their data, among them MySQL and PostgreSQL. In
other words, MySQL is just the brand of one database software, one of many. The
same goes for PostgreSQL. These two databases are very popular among programs that
run on websites (probably because they are free), which is why one often sees one or
both of them being advertised in the feature lists of web hosts, as well as being listed
as one of the "system requirements" for certain web software (like blogs and content
management systems).

4.1.5 Screencast
From the website whatis.com (2016), A screencast is a digital video recording that
captures actions taking place on a computer desktop. Screencasts, which often con-
tain voice-over narration, are useful for demonstrating how to use specific operating
systems, software applications or website features.
Screencast production requires some kind of video-capture software and a micro-
phone. The software, which can be a desktop client or web-based service, captures
and synchronizes the video and audio files and compresses the completed movie into a
format that can be shared.

4.1.6 Socket Programming

The website tutorialspoint.com (2016) defines Socket Prgramming as, Sockets allow
communication between two different processes on the same or different machines.
To be more precise, its a way to talk to other computers using standard Unix file de-
scriptors. In Unix, every I/O action is done by writing or reading a file descriptor. A
file descriptor is just an integer associated with an open file and it can be a network
connection, a text file, a terminal, or something else.
To a programmer, a socket looks and behaves much like a low-level file descriptor.
This is because commands such as read() and write() work with sockets in the same
way they do with files and pipes.
Sockets were first introduced in 2.1BSD (Linux Variant) and subsequently refined
into their current form with 4.2BSD. The sockets feature is now available with most
current UNIX system releases.
CHAPTER 4. RESULTS 32

4.1.7 Other tools used

The following tools were also used in the making of the app:
MS-Paint:
This was used for drawing the diagrams regarding different modules.
StarUML:
This was used for rendering all the Use Case diagrams shown in the report for
different modules.
Hosting Website:
The URL to the web hosting site is: http://www.ecowebhosting.co.uk. We cite it as
follows: Hosting (2016).
CHAPTER 4. RESULTS 33

4.2 UI Screenshots
This section shows all the screenshots of the working application.

4.2.1 Master Side

Figures 4.1, 4.2, 4.3, 4.4, 4.5, 4.6 illustrate the UI of the master device (M Cast).

[a ] [b ]

[c ] [d ]

Figure 4.1: a. Splash Screen || b. Set Port Screen || c. Set Port Dialog || d. M Cast Menu
CHAPTER 4. RESULTS 34

[a ] [b ]

[c ] [d ]

Figure 4.2: a. Browsing and selecting PDF file || b. Demonstration of Canvas-Fetching

pre saved canvases || c. Attendance Menu || d. Registration of New Class
CHAPTER 4. RESULTS 35

[a ] [b ]

[c ] [d ]

Figure 4.3: a. Selecting Class and Mode of Attendance || b. Submit Attendance || c.

Submit Attendance || d. Take Attendance(Mark As Present)
CHAPTER 4. RESULTS 36

[a ] [b ]

[c ] [d ]

Figure 4.4: a. Attendance List || b. Download as CSV file || c. Options for sharing CSV
file || d. View Attendance by Date Dialog
CHAPTER 4. RESULTS 37

[a ] [b ]

[c ] [d ]

Figure 4.5: a. Attendance of the date fetched || b. Dialog to download from web || c.
Webview opened for download || d. Reseting Progress Dialog
CHAPTER 4. RESULTS 38

(a) (b)

(c)

Figure 4.6: a. View of doubt || b. Demonstration of interchange module || c. Master

Privileges granted to client
CHAPTER 4. RESULTS 39

4.2.2 Receiver Side

Figures 4.7 and 4.8 show the UI of the receiver side ( C Cast).

[a ] [b ]

[c ] [d ]

Figure 4.7: a. Login/Registration Page || b. Register Form || c. Login Form || d. C Cast

Home Screen
CHAPTER 4. RESULTS 40

(a)

(b)

(c)

(d)

Figure 4.8: a. Ask Doubt Dialog || b. View/Delete Doubt Dialog || c. Notification for
master privilege || d. Menu displayed after interchange
CHAPTER 4. RESULTS 41

4.3 DB Screenshots
Full page images in the subsequent pages show the database and its features. This
further elucidates structure of database and its components as discussed in previous
sections. Figures 4.9 to 4.13 illustrate the same.

Figure 4.9: Structure of Clients Database

CHAPTER 4. RESULTS 42

Figure 4.10: Structure of Doubts Table

CHAPTER 4. RESULTS 43

Figure 4.11: Structure of Datewise attendance database

CHAPTER 4. RESULTS 44

Figure 4.12: Structure of Table for attendance for a particular class

CHAPTER 4. RESULTS 45

Figure 4.13: Main Databases that has all tables

Chapter 5

CONCLUSION AND FUTURE

SCOPE

This chapter deals with the future scope of the developed application as well as draws
conclusions of the Modus Operandi of the application.

5.1 Conclusion
The other applications present in the market were found to be grossly inadequate, and
lacking behind vis a vis this new app, and hence the reason for its development. Not
only does this app provide seamless communication among many devices, it also fea-
tures many new features like doubt removal module and an integrated attendance man-
agement system never seen on an app of this kind. This has been illustrated in the table
on the next page (Table 5.1).
The app thus will go a long way in reducing the burden of our esteemed faculty
members, and would thus be our way of saying thank you for their sustained support
and guidance all these years. Not only will this reduce the burden of our professors,
this would also result in greater classroom engagement and more productive session,
with more time remaining at the disposal of the faculty members due to pruning of the
unnecessary time lost (due to processes like attendance marking).
This app truly would herald in a transparent system where students and faculty
members both seek to benefit a lot.

5.1.1 Comparison with other applications

Table 5.1 shows comparison of the developed with other contemporaries.

46
CHAPTER 5. CONCLUSION AND FUTURE SCOPE 47

Features Our Software Lensoo Create AllCast

MD-5 Encryption O X X

Casts to Multiple clients at the same time O X X

Easy interactive learning experience O X X

Canvas Overlay O X X

Live Screen rendering with minimal lag O X X

Drawable Canvas O O O

Real time (No recording and upload required) O X X

Registration for specific classroom sessions O X X

Login and Logout for a session O X X

Supports more than one classroom sessions at a time O X X

View active doubts O X X

Register doubts in real time O X X

WIFI for faster, seamless experience O O O

Casting capability of multimedia X X O

Video Quality X X O

Adaptability to slow connection X X X

Attendance Management System O X X

Integrated Doubt Module O X X

Table 5.1: Feature Comparison Table

CHAPTER 5. CONCLUSION AND FUTURE SCOPE 48

5.2 Future Enhancement and Scope

While this app has been built with utmost dedication and perseverance, there still re-
main some avenues where this application might improve in the days to come. These
have been enumerated below:

(a) Some rare, occasional bugs while transmitting data.

(b) Complexity regarding the login/registration process might be tackled with in the
future.

(c) Use of newer technologies like Li-Fi may lead to great improvements in the near
future.

(d) The UI might as well be revised in order to reduce complexity.

(e) The interchange module might be reworked on to gain substantial performance

improvements.

(f) No support for in-middle-of-a-session joining of a client device to a screen cast

session.

(g) The attendance module may be tweaked for compatibility with various courses
taken in a single class.
Bibliography

[1] Ableson, F., Collins, C. and Sen, R.: 2009, Unlocking Android, Manning Publica-
tions Co.

[2] about.com: 2016, Apache web server.

URL: http://compnetworking.about.com/cs/webservers/g/bldefa pache.htm

[3] AndroidHive.info: 2016, Implementing android splash screen.

URL: http://www.androidhive.info/2013/07/how-to-implement-android-splash-
screen-2/

[4] GitHub.com: 2016, Using android studio.

URL: https://github.com/codepath/androidg uides/wiki/U sing Android S tudio

[5] Hosting, E. W.: 2016, Ecoweb hosting.

URL: http://www.ecowebhosting.co.uk

[6] Lee, W.-M.: 2012, Beginning android 4 application Development, John Wiley &
Sons.

[7] Meier, R.: 2012, Professional Android 4 application development, John Wiley &
Sons.

[8] Murphy, M. L.: 2009, The Busy Coders Guide to Advanced Android Develop-
ment, CommonsWare, LLC.

[9] Murphy, M. L.: 2010, Android programming tutorials, CommonsWare, Llc.

[10] NTCHosting.com: 2016, Php script.

URL: https://www.ntchosting.com/encyclopedia/scripting-and-
programming/php/php-script/

[11] Rogers, R., Lombardo, J., Mednieks, Z. and Meike, B.: 2009, Android application
development: Programming with the Google SDK, OReilly Media, Inc.

[12] thesitewizard.com: 2016, What is mysql database.

URL: http://www.thesitewizard.com/faqs/what-is-mysql-database.shtml

49
BIBLIOGRAPHY 50

[13] tutorialspoint.com: 2016, Socket programming.

URL: https://www.tutorialspoint.com/unix s ockets/whati s s ocket.htm

[14] whatis.com: 2016, Screencast.

URL: http://whatis.techtarget.com/definition/screencast