4.1 Overview
In this chapter, we will discuss some of the details that we should pay attention while implementing this system. After that, we will have a view of the implemented system and the analytics of data that was collected in real practice.
4.2 Implementation Guideline
Server Side Implementation:
Before we go on, here is an overview of the main events that Server would need to handle:
- User authentication
- Client request (information access, match request, etc.) - Message delivery
- Push Notification - File upload & download
In native, an XMPP Server can satisfy the need for authentication and online message delivery with the help of a database. Although there is a built-in database in Openfire, an external database is recommended for higher scalability and portability, especially if the system structure is distributed. In this implementation, a MySQL database is used for better management and compatibility with self-developed plugins.
Though Openfire can handle online message delivery, it is not enough to fit the user behavior of mobile apps nowadays. Regarding that users will not always run a single app and keeps it opened. In other words, users are not always online; therefore an offline message delivery mechanism should be included for such condition.
For iOS and Android clients, Apple and Google provide APNS and GCM services to support third-party server push notification, where push servers can store those notifications to be pushed in pool and push them to target clients once they are online.
Making use to push services, we can add a message interceptor, in form of a plugin, to the Openfire server; Whenever there is a message delivery request, this interceptor can decide whether to deliver the message directly to client or through APNS and GCM push services, depending on the presence of the message receiver.
The advantage of using push notification for offline message delivery is that users can see messages from their exchange partners even if they are not using this app currently. This helps to keep conversations going on and can retain user in this app, but there is a limitation that APNS service only allows a payload size of maximum 256 bytes and GCM supports up to 4kb. Therefore offline messages exceed the limited size will not be forwarded by the push servers.
Besides text messages, there will be frequent transfer of image and audio files between our server and clients too. Therefore server will need another plugin to handle
it. There are many ways to handle file transfer; in this implementation, our server will store any uploaded files in file system and write the reference links to the files in database. The main advantage of this approach is that file system and database are managed separately, which can keep the system structure simple and is easier for management. Another advantage is that, for any file requests, server can respond with the corresponding download link rather than the file directly. Client can decide the timing to download the file or only launch a download where necessary. This can help reducing the amount of data flow and memory storage, which should be well controlled for mobile phone environment.
The handling of the remaining client requests, such as information retrieval and update, can be achieved by implementing similar plugins with the help of HTTP Request and SQL. Since these plugins are relatively straight forward and therefore we will not be discussing in details. This is all about the implementation guideline of server, and in the next part we will take a look at the client side.
Client Side Implementation:
For the client side, there are two criteria that we should always keep in mind while implementing a mobile application: one of them is network environment, and the other is memory space. Unlike PC environment, mobile phones usually work under a relatively unreliable network environment and the memory space is much smaller.
Therefore most mobile operating systems, such as iOS and Android, have corresponding control policy for mobile applications.
While an iOS application can be allocated up to 49% ~ 68% of the total memory according to the specification of the device and its OS version, the memory allocation of an Android application can be ranged from 5% of total memory before OS version 2.x to 25% after version 4.x by actual test [18, 19]. Base on the fact that users usually do not run only one single app at a time, an application will not always get the ideal available memory allocation. As a result, we should always not forget the concept of memory control and optimization while implementing a client application, especially if the application consists lots of images that would take up a bulk of memory space;
otherwise the application can be killed by the operating system once the application exceed the memory limit or when memory is insufficient.
If we go on, the remaining issue will be about network. For each mobile application, there is a “Main Thread” (or UI Thread) that keeps interacting with user, including the responses for users’ touch events and UI rendering. In order to improve user experience, any time-consuming and network process should be carried out in sub-threads to keep the Main Thread always ready for response. This is especially critical on Android system which has the ANR (Application Not Responding) mechanism. Whenever there is a “no response” to a user input within 5 seconds, or a
broadcast event is not finished within 10 seconds, an ANR dialog will be triggered to notice user that the app is not responding and the application can be shut down in result.
After discussing the implementation of the system, we will be taking an overview of the implemented client application and the result of a short period of real trial in the next chapter.