IS480 Team wiki: 2013T2 The CodeFather Final Development Overview

From IS480
Jump to navigation Jump to search

The CodeFather Logo.png

Back to Main Wiki   Progress Summary   Project Management   Development Overview   Quality of Product   Reflections

Technical Complexities

Streamlining XMPP and GCM

Streamlining connections-1.png
During Mid-term, when a message is being sent, it message will make two connections. Firstly, the message will be sent to Schedulous server, which will in turn forward the message to Google Cloud Messaging (GCM). GCM will then do a push notification to the desired android phones. Secondly, the message will be sent to XMPP server. When the users in the group open the chat, the messages will be loaded from XMPP server.

Streamlining connections-2.png
After mid-terms, we were developing Web Chat, and it struck us that we must streamline our connections in order to make sure there is only one entry point were message will be sent. This will allow us to know where are the potential bugs when any issues occur. Therefore the idea of creating an Adapter surfaces.

Streamlining connections-3.png
The Adapter lies in the XMPP server itself. It intercepts the message packets from the sender. By filtering to the specific packet with a "message" body, the Adapter is able to extract the sender, the destination of the message as well as the message content itself. In addition, the Adapter also adds in a timestamp to the extracted message. This time stamping method allows the android client to cache the message locally. Once the packet has been processed, it will continue its path to the XMPP server and then to the client itself. Simultaneously, the extracted contents will be sent to Schedulous server by executing a shell command from within the Adapter itself.

The technical difficulty of this implementation is the understanding and usage of three different languages - XML, JAVA and Unix Shell. When developing the Adapter, there were a few difficulties which we faced. Firstly, there was insufficient documentation as to how to develop an Adapter. Therefore, we have to take reference code samples from other adapters and understand how the adapter works. Secondly, since we are executing Unix shell command, we have to take extra precaution to prevent any Unix shell injection. This is very important as users might be able to insert escape characters in their chat messages, and the security will be compromised.

Integrating SMU Timetable

When the user enters her/her login credentials on the android client, the data will be transmitted over a secure channel to the Schedulous server. At the Schedulous server, the request will be queued and processed. The extract timetable function by the works by using the requestor’s username and password to login into BOSS. BOSS is the Bidding Online SyStem which students will enter to bid for their modules.

Smu timetable-1.png Smu timetable-2.png Smu timetable-3.png

Once logged in, the script will do some filtering. In order to identify the correct term, the script will scrap the HTML codes and look for a few particular keywords. They are Term 1, Term 2, Term 3A and Term 3B. Taking into account the month of the year, it will determine which term to navigate to. For instance, currently, after we login today, BOSS will show us Term 3A. Therefore, we have to navigate back to Term 2, as this term is not over yet.

Smu timetable-4.png

To navigate back to Term 2, BOSS keep tracks of 2 particular tokens. They are State and Event Validation token. These 2 tokens will remember the current point in which the user is at, so in the browser environment, it will remember which page to load when the user close and open the BOSS Dashboard.

Smu timetable-5.png Once it reaches the correct Term, the script will then download the timetable in Comma Separated Values (CSV) format. Since it is in CSV format, it is easy to use a CSV Parser and extract the information from the file and store it in database.

Once the data is stored in database, a push notification will be sent to the requestor's android phone to notify him that his/her timetable is available on Schedulous calendar.

Smu timetable-6.png Smu timetable-7.png The problem with integrating SMU calendar is due the timeout feature on android phone. Android phone will timeout a http request after about 10 seconds and that results in a disruption in the extraction function. Therefore, we came up with the solution of having an internal queue using Beanstalkd. So when a timetable requests come in, it will be queued internally and sent for processing. After the SMU timetable has been extracted, Schedulous server will notify the user by push notification to inform him/her that the timetable is available for viewing on his/her phone.

Openfire XMPP

Locally Caching of Chat

For our schedulous mobile application, we aim to increase the usability of the user through the local caching of chat messages. This is essential as if the messages are not locally cache, the mobile application would need to retrieve the chat messages from the server every single time. The problem here was that the bulk of the waiting time was for users to login & join room. This would in turn cause a lag time for the messages to appear when the user clicks on the individual chat page.

The Codefather Main Chat Page.png The Codefather Individual Chat Page.png

Below shows the flow in which the messages are locally cached:

The CodeFather Screen Shot 2014-02-23 at 3.04.13 pm.png

The Codefather Screen Shot 2014-02-23 at 3.35.29 pm.png

One of the suggested ways by android to retrieve data asynchronously from SQLite is via LoaderManager. We first start by initializing the loader and have it connected with our chat listview’s adapter.

The Codefather Screen Shot 2014-02-23 at 3.39.50 pm.png

Next we write their callback methods which will take us to the right database, table and data we want. Upon finish execution, it will call the onLoadFinish method to swap the cursor that was given to the listview’s adapter.

Screen Shot 2014-02-23 at 3.40.51 pm.png

The recommended way of receiving messages from Openfire is to use their message callback listener. It allows us to write the method to be called whenever a message is received on the Smack API. This asynchronous method allows us to not block up the UI thread and also not need use a async method.

The CodeFather Screen Shot 2014-02-23 at 3.41.44 pm.png

This receiver is what allows activity to be informed of the update in database and asks the listview to refresh the list from SQLite.

Managing Connections

Screen Shot 2014-02-23 at 8.12.16 pm.png

The main difficulty in managing connection is that for Android,there is no single start point of the app. App can be onResume at any activity and XMPP needs to be reconnected but every time you reconnect it’s a 1-2 seconds delay.

To achieve this, we are using onBind method with services (Singleton). So we have made all our activities other than loginactivity extend a commonActivity class and in its onResume and onPause, we call the bind and unbind method respectively. The connection will only be called once in onCreate when the first activity calls onbind and disconnected in onDestroy when all activities unbind from this service. What this means is that users can now navigate through all our apps without having to connect and disconnect from xmppservice.

Another critical problem we have to resolve is to prevent disconnection from server due to a time-out. Openfire does this in the interest of not to overload of our server. However, if the service is to timeout, a similar reconnection will be required when user resumes activity. So the solution we have implemented is to created a handler which repings the server every 2 minutes while service is alive. Service dies once all activities unbinds (when app is not in active window).

In order to achieve increased usability in the application is through GCM notification, when message is received. Upon receiving the message from GCM server, we wanted Schedulous to be able to receive and store the messages once GCM informs Schedulous of new messages. This is also to reduce the 1-2 seconds wasted when user clicks on the notification and have to login to Openfire.

Customizing 3rd Party Libraries

  • Business Requirement

As part of our application’s requirement, we needed to allow users to pick several dates and times. However, there were no existing libraries well designed for the task. From our User Testing, we realized that users were unhappy at having to go through several screen to select dates and times. As such, we had to tweak existing libraries to suit our needs.

  • Technological Difficulties

With the business requirement in mind, we proceeded to tear apart existing libraries to fulfil our need. In doing so, we faced some difficulties in that the codes written had incomplete documentation. Method names were also not very descriptive.

As such, we had to understand in depth what each code was doing before we could make the amendments we needed. An example of a library we changed is shown here:

Screen Shot 2014-02-23 at 8.18.11 pm.png

We originally took the Caldroid library, which was a library designed to select dates. It allows for selection of multiple consecutive dates, and coloring of individual dates. We had to change the code to do several things which it originally was not designed to do:

  • Select multiple, non-consecutive dates.

To select multiple, non consecutive dates, we first had to understand how the library initially selects consecutive dates. After some tracing, we realized that it used a hashmap to store the dates being selected. We then had to amend the existing methods of selecting the data from the dates the user chose.

To complicate methods, we wanted to have the date selected only when a specific time was selected. Logic had to be written such that the method call to select the dates are triggered only when times are selected.

  • Select times for each date.

To build in the time selector, we had to create a GridView below the existing fragment showing the Calendar. These time slots had to be linked to a the selected date, and had to store the all dates that a user selects within this session. To do so we utilizd a hashmap. An additional layer of logic had to be implemented to ensure that the time selected is not in the past. This custom gridview was wholly coded out by us, and attached onto the library.

  • Indicate the date being selected

Lastly, we had to indicate which day the user was selecting times for. The calendar library, being designed to select only one date, had no way to do so. As such we had to tweak the library once again to create a special variable to track and highlight the date the user selected, and show it in a different way from the dates that he has selected. We changed the font color to indicate the date he is viewing, and used a background color to indicate all dates that have selected times.

Screen Shot 2014-02-23 at 8.18.14 pm.png

There are other libraries that we amended, such as the second calendar library we used in the main screen; it was amended to show the details of the events, and to show calendars that the user chooses to show, rather than every calendar synced into the user’s mobile phone. This particular library was difficult to tweak as there was no documentation in the code at all.