Implementing Monitoring Systems in Mobile Applications – a Case Study

During the last years, the evolution of mobile applications allowed the developers to become more and more creative. In this way, we can imagine many applications models with a real impact in the real life. In this article we are trying to present a case study for a monitoring system using the Android platform and the benefits of computer networks. We use the power of mobile sockets and mobile threads, integrating them in a complex architecture in order to obtain a real monitoring system. As an immediate application, we propose a baby monitoring systems so that the children could be remotely supervised by their parents. The case study is based on an Android mobile client-server architecture and also uses the capabilities offered by the phone’s speaker and microphone. We intend to have a robust application and that’s why we initially preferred Network Service Discovery and Android P2P, but these functionalities are implemented starting with Android 4.1. So, we emulated all these functionalities by using a model based on sockets and server sockets.


Introduction
In this article we present a case study of a mobile monitoring application made on Android platform.Our goal is to implement an application which can be used by parents in order to supervise their children; this vision could be used to also improve the proposals about the intelligent tutoring systems described by [1] or to implement innovative systems described by [2].We propose the following scenario: the baby is in a room and the parent is in other room; in both rooms they have smart-phones with our application.Without using the GSM provider, the parent can hear the activity of the baby.Eventually, if the baby cries, the system will warn the parent about the situation.The application is designed to run in some conditions and rules:  the application does not use the GSM capabilities and it can also run on a tablet;  the minimum required platform is Android 2.0;  the application uses only a Wi-Fi connection and doesn't need any external remote server;  the application uses the speakers and the microphones of the involved smartphones.
Initially, we intended to use Network Service Discovery [3] and Android P2P, but these functionalities are implemented starting with Android 4.1.For these reasons, we preferred to emulate these capabilities by using the socket's technology.As a conclusion, the only restrictions are the following: smart-phones with a Wi-Fi connection, speaker and microphone.As we know, these resources are already available on almost all the smartphones, so the proposed application could be installed on a significant number of mobile devices.Although the new HTML5 standard could represent a solid enterprise mobile computing foundation and a feasible path towards the proliferation of the applications as described in [4], we consider that it is extremely important that an application could be used by a large number of clients with "normal" smart-phones.We are also conscious that, according to [5], Mobile Application Development is a popular topic these days, when tons of mobile apps are released and available tools and resources are expanding.Nowadays, the wireless networks have many sensors and protocols used to capture and transmit data [6], but one of the oldest methods of network communication provided by Java is by using Transfer Control Protocol DOI: 10.12948/issn14531305/18.4.2014.11(TCP) sockets.For this, we use two classes: Socket and Server Socket, the latter being the one to trace the connections that are made.For the audio streaming, it is used the device's microphone which is operated by Android through the objects of type Audio Recorder.
The information received by the microphone is encoded (using Audio Format class) through predefined constants (ENCOD-ING_PCM_16BIT) and it is allocated a broadcast channel (in our case CHAN-NEL_IN_MONO).The audio coding is done using PCM (Pulse Code Modulation).It converts audio signals (represented by sound waves) to a digital signal (strings of 0 and 1) with or without compression.
For the audio reception it is used the smartphone speaker.The speaker is handled in Android using AudioTrack class.The signal emitted by the speaker uses the same type of encryption like that is received by the microphone and transmitted over the network.This time, the communication channel is CHAN-NEL_OUT_DEFAULT and the speaker chosen to issue the sound is operated by Audio Manager class.The predefined constant VOICE_CALL will direct the sound to receiver, and STREAM_MUSIC will direct the information to the speaker.

Scenarios and architectures for data and sound transmission in the monitor system
The network audio transmission is made by data packets with the rules described in [7].
They can be created and transmitted using Datagram Packet and Datagram Socket which work together.From the sender's side, the Datagram Socket object transmits an object of type Datagram Packet (which contains data from a buffer) to the IP connected to that device.The IP is then passed as a parameter when creating objects of type AudioSender (the class that will manage the sound recording operation).The receiver's object of Datagram Socket type receives a Datagram Packet and the data from the packet is introduced in a buffer which is then played by the speaker with the Audio Receiver class.This emissionreception process is presented in Figure 1.

Scenario A:
In this scenario, the flow of execution is as follows:  on both devices the application starts and awaits the user action;  when the user selects a type of device, the graphical interface will change according to its type.The complete description of this scenario is presented in Figure 2.

Fig. 2. Devices waiting for the user's action
The child device waits for parent device to connect.When the socket server object from the child device detects the connection, it runs the thread of the Audio Sender object which will switch on the microphone and it will start to deliver data packets to the child device.This will start the thread of AudioReceiver in order to receive packets from the server and to deliver them as a sound.The messages are sent by the server and the client to the GUI using a special handler.The connected devices will show like in Figure 3 and in terms of hearing, the child device transmits the sounds to the parent device.

Scenario B:
This scenario assumes that the parent device is able to emit sounds to the child device.This means that the parent device will have a button that will handle events of sound emission to and from the child device.As we can observe, this scenario is more complicated.Based on the scenario A described in Figure 4, it is not enough a communication only from client and GUI, but also in a reverse sense so that the client thread knows how to manage the transmission and reception (by pressing and releasing the button).Also, the communication between client and server is no longer enough by using just sockets.The client must warn the server that it intends to transmit sound to it and the server should prepare for receiving it.In the same scenario, both client and server threads will have to manage how to communicate with the threads reserved for the sound.There will be not enough just to call the start() method of the sender and receiver's thread, but also their swap between them depending on user's action.The performances of the threading technique are very well described in [8].The threads communicate each other using socket data streams and we had in mind the rules and principles presented in [9] and [10].
In this scenario, when the client receives the signal from the graphical interface by pressing "Talk to the baby" button to send sound to the server, it will communicate to the Audi-oSender thread, through a Piped Writer object, how to behave:  "1" means that it should start recording and sending packets to the receiver;  "0" means that it should release the microphone because the audio streaming is not necessary anymore.
Meanwhile, the server is alerted via a text message (using objects of type Data Stream) that is to receive a sound in order to know to stop broadcasting and start reception.The server in turn sends messages to Audio Receiver and Audio Sender to stop or start, then to the graphical interface to know to handle the corresponding event: it will replace the image of the microphone with the image of the speaker.So it will also behave the client thread announcing GUI about the sound transmission to another device, and it will change the speaker with the microphone.The result of this process is presented in Figure 6.As we could see, the most interesting and realistic scenario is scenario B, which will be implemented in the following section.
3 The implementation of the monitoring system using Android platform In order to implement the scenarios presented in the section above, we used many specific classes: AudioReceiver, AudioSender, DOI: 10.12948/issn14531305/18.4.2014.11worked fine and the quality of the transmission was excellent.
In the future, our model could be improved with some additional features:  a warning system if the level of the sound exceeds a specified limit (for example, if the baby cries, then the parent should be warned in a specific way);  a video system which could be activated in some specific conditions (for example, if the baby does not produce any sound for a while, then the video transmission should automatically activate on the parent side).As a conclusion, we can say that the model we propose in this article is a realistic one and it has the potential to be extended with additional features.

Fig. 1 .
Fig. 1.The emission-reception process using Datagram Socket in a client-server architecture

Figure 5 Fig. 5 .
Fig. 5.The execution flow and the architecture of scenario B

Fig. 6 .
Fig. 6.The behavior of parent and child devices when they transmit sound in reverse

Fig. 7 .
Fig. 7. Connected devices according to the scenario B