Extending Sakai Web Services for Mobile Application Support

Honours Project Report 29/10/2012

Extending Sakai Web Services for Mobile Application Support Sascha Watermeyer Supervised by:

Prof. Sonia Berman Second Reader:

Dr. Anne Kayem

Category 1 Requirement Analysis and Design 2 Theoretical Analysis 3 Experiment Design and Execution 4 System Development and Implementation 5 Results, Findings and Conclusion 6 Aim Formulation and Background Work 7 Quality of Report Writing and Presentation 8 Adherence to Project Proposal and Quality of Deliverables 9 Overall General Project Evaluation Total Marks

Department of Computer Science University of Cape Town``

Min 0 0 0 0 10 10

Max 20 25 20 15 20 15 10 10

0

10 80

Chosen 15

15 10 10 10 10 10 80

Abstract Mobile development will reduce the digital divide of developing countries in Africa. The demand for mobile applications within Africa is only growing, including universities like the University of Cape Town where an increasing number of undergraduates have mobile devices with internet capabilities. The university use a learning management system that runs on a SAKAI platform which already provides the members of the university with educational resources but not an adequate mobile interface. A mobile interface could greatly benefit the students of UCT’s access to educational resources. Our project called ‘VulaMobi’ aims to design and implement a mobile application for UCT’s learning management system called ‘Vula’.

This report will focus on the back-end design and implementation of the system. This component will be a web application that acts as an intermediary service between Vula and the front-end of the system developed by my team members. To integrate systems a common format needs to be recognised by either system therefore JavaScriptObjectNotation (JSON) was chosen, an efficient and simple data interchange format used to interact our mobile interface with Vula. Web services are required for mobile applications to communicate with the backend. Mobile applications use Asynchronous JavaScript and XML (AJAX) techniques to access these web services and retrieve JSON objects of information. Therefore in an attempt to solve the problem of bridging the communication between Vula and the front-end I will adopt an AJAX framework to enable back-end web services that provide mobile application support for the front-end.

2

Acknowledgements I would like to acknowledge Stephen Marquard of the Center for Educational Resource (CET) for his support in the project. Samsung for their donated devices we could test with and Angus Comrie for another pair of eyes on the work and finally Professor Sonia Berman for her guidance through my final step.

3

Table of Contents Abstract

2

Acknowledgements

3

List of Figures

5

1.

Introduction

6

2.

Background

7

3.

4.

5.

2.1

Learning Management Systems

7

2.2

Mobile Interface Support

9

2.2.1

Blackboard

9

2.2.2

Moodle

9

2.2.3

Sakai

12

2.2.4

Critical Comparison

13

2.2.5

Thoughts

14

Design

15

3.1

Goals

15

3.2

Architecture

16

3.3

Interaction with Client

16

3.4

Interaction with Vula

18

3.5

Frameworks

19

3.6

API

20

Implementation

21

4.1

Prototype

21

4.2

API Development

23

4.2.1

Same Origin Policy

25

4.2.2

PDA Portal

25

4.3

API Functions

26

4.4

Limitations of System

28

Testing

30

5.1

ADSL Test

31

5.2

Honours Lab Test

32

6.

Conclusion

35

7.

References

36

A.

API Funtions

38 4

List of Figures Figure 1: Vula Mobile Portal

13

Figure 2: Mobile interfaces of the University of Oxford, Indiana and Florida

14

Figure 3: Client-Server-Server

17

Figure 4: System Overview

21

Figure 5: Prototype Interface (Login,Home,Active-Sites view)

23

Figure 6: Navigation Protocol

27

Figure 7: ADSL Response Time

32

Figure 8: ADSL Download Speed

33

Figure 9: Honours Lab Response Time

34

Table 1: Pros and Cons of the different approaches to developing a mobile app

12

Table 2: Summary of the features offered by the LMS mobile interfaces

15

Table 3: Team Back-End Requirements

25

Table 4: Overview of the API Functions

27

5

1.

Introduction

To allow access to educational resources for students and staff; university’s around the world have installed in an ever increasing number Learning Management Systems (LMS). A learning management system is an information system that administers instructor-led and e-learning courses and keeps track of student progress[13]. The University of Cape Town (UCT) adopted Sakai [19], an open source LMS that provides an environment students and lecturers can collaborate in.

Vula is UCT’s flavour of Sakai that has been customized and extended for UCT learning purposes and is used for student and lecture convenience to access course information and resources. Vula currently has a web based mobile portal for devices accessing the website through a browser; this has a simple interface with ease of navigation through courses and tools, except the format that each tool is presented in the mobile interface is exactly the same as the desktop interface. This format is not appropriate for the small and low resolution screens of mobile devices presently.

This leaves room for improvement for a richer user experience of the Vula mobile interface and is the project taken up by my team named ‘VulaMobi’. Our team is a group of four and is the largest honours project team this year, the separation of work was decided to be split by the front-end and back-end of the system. Everyone else in team except me would focus on the front-end aiming at delivering a quality user interface, which leaves the back-end, as my task to complete.

In this report I will explain how I designed, developed and tested the backend of the system, this component would require a means to retrieve requested data from Vula and then deliver it in an efficient manner to be presented on the front-end. The mobile interface (front-end) would require a data inter-change approach that is very efficient as mobile phone battery life and connection speeds are limited. Efficiency is critical in modern day mobile development and will result in an unfeasible application if underestimated.

In response to solve this problem I developed a back-end component which will integrate Vula and the front-end. The component adopts a Representational Transfer Protocol (REST) & JavaScript Object Notation (JSON) protocol which delivers data from Vula as a web service that can be called by any mobile device and utilises JSON as the inter-change format to transport the data. The REST & JSON protocol is the clear leader these days for mobile backend support due to its efficiency and simplicity.

6

2.

Background

Sakai is an open source course/learning management system – C/LMS- that provides the platform for an enterprises online learning environment by enabling the management, delivery and tracking of online and blended learning [14]. Resistance of vendor lock-in and escalating licensing costs have led many colleges and universities around the world to choose open source learning management systems such as Sakai over the limited proprietary options [17].

Due to the current influx in the number of mobile devices purchased, more and more students eventually will own a mobile device with internet access and opens the opportunity of e-learning on hand and not just in the classroom. To avoid platform specific dependencies – e.g. applications for Android or iOS - an interface that is interoperable between all mobile platforms offers a better solution. This can be achieved by implementing a mobile optimised web learning management system that provides enhanced access throughout an institution. HTML5 is the new standard for presenting content on the internet and offers improved support for current multimedia and can be written specifically for mobile devices with smaller screens than standard desktops.

In this chapter, we will cover learning management systems and the various mobile interfaces offered by these learning management systems. Then cover the advantages and disadvantages of these mobile interfaces and explain the different approaches taken to design the interfaces. Finally we will conclude which interface outperforms the rest by comparing the features offered by their interfaces.

2.1

Learning Management Systems

Learning management systems are software systems designed to support student learning. They contain a number of presentation, assessment, communication, and management tools, for example, Sakai, Moodle, and Blackboard [6]. A range of institutions use learning management systems for their operations; for instance corporations use LMS for their corporate training of record keeping or employee registration, Universities use LMS for the student self-service, trainer notifications – announcements to the students from lectures -, resource management of courses, collaborative learning – through chat room – and online learning courses. Learning management systems are a form of e-learning and can include elearning tools that provide direct feedback from student to teacher. These systems have a large scope of features and some are even completely web-based to provide access to a learning environment throughout an institution.

7

Considering the past development of learning management systems there are three methodologies to implementing these systems:

a)

Commercial LMS: e.g. Blackboard

These cover the proprietary learning management systems, that Blackboard Inc. has a near monopoly over the market. Blackboard expanded their dominance in 2005 by their merger of WebCT - its largest rival in the education software industry – [5]. The rapid growth of this company has forced institutions who previous had WebCT as their primary LMS to upgrade to a premium Blackboard licence by the end of the 2012 that would include Blackboard community features at triple the cost. As indicated in the introduction of this chapter, resistance of vendor lock-in and escalating licensing costs have led many colleges and universities around the world to choose open source learning management systems over the limited options of proprietary options. b)

Locally Developed LMS: e.g. CourseWork from Stanford

These refer to the "in-house" developed software at a particular institution; in 2003 Stanford University announced the open source release of its course management system that the university had been developing since 1998 [5]. Since the open source release of CourseWork, Stanford University has joined forces with three other institutions, the University of Michigan, Indiana University, and MIT, to develop a new Collaboration and Learning Environment now called the ‘Sakai project’ or as we will refer to it, ‘Sakai. c)

Open source/Community LMS: e.g. Sakai, Moodle

These include the learning management systems that are developed under open source licences and often include a community of developers who contribute to the lifecycle of the software. The Sakai project is an experiment in collaborative development, implementation, and productive use of eLearning software systems [7] between Stanford University, University of Michigan, Indiana University, and MIT based on the original Stanford learning management system called ‘CourseWork’. Moodle - originally an acronym for Modular Object-Oriented Dynamic Learning Environment - is effectively the open source competitor of Sakai that was developed by Martin Dougiamas who designed the program while working on his Ph.D. at Curtin University of Technology, Perth, Australia [16]. Both Sakai and Moodle offer viable solutions for institutions wanting to implement free learning management systems as opposed to the forced premiums of privately owned LMSs.

8

2.2

Mobile Interface Support

In the rest of the chapter I will discuss three examples of learning management system with mobile interface support. I will discuss approaches for implementing a mobile interface for one commercial learning management system – Blackboard - and two open source projects –Sakai and Moodle –then compare the advantages and disadvantages of the different approaches.

2.2.1 Blackboard Blackboard has grown rapidly since 1997 by overcoming their major competition through acquisitions, most importantly the buyout of WebCT in 2005 then the acquisition of Angel in 2009. At this time the only other major competitor left was Desire 2 Learn (D2L) however D2L had been embroiled in a three year-long multimillion-dollar patent infringement lawsuit from Blackboard. Blackboard’s patent infringement allegations were nullified but the long term impact for D2L was unknown [17]. WebCT had stopped having support from Blackboard in 2005 straight after the acquisition and Angel continuously losses support since its acquisition in 2009.

Blackboard being a profit seeking entity doesn’t have to rely on an open community driven project to develop a mobile interface to extend the Blackboard Learning System thus the enterprise has developed a complete mobile platform called ‘Blackboard Mobile’. The platform was released in 2009 [2] that provides students with access to all learning and teaching content through a native mobile application. Blackboard developed applications for most popular mobile platforms; Android and iOS – not Blackberry- but this still leaves a gap in the interoperability between all types of mobile platforms. Students at an institute that support Blackboard Mobile will be able to download the application through their mobile platforms application store that has support for up to seven languages including Arabic.

2.2.2 Moodle Moodle unlike Blackboard is an open source project that was founded by Martin Dougiamas who based Moodle from research on his Ph.D. in Perth, Australia. The word Moodle was originally an acronym for Modular Object-Oriented Dynamic Learning Environment, which is mostly useful to programmers and education theorists [1]. Moodle has an aim of being as interoperable as possible; an important feature of this is the ability for institutions restricted by the premiums of Blackboard to migrate Blackboard sites into Moodle.

9

Under the Moodle page for their mobile application they provide a thorough rationale for mobile apps and explain the different approaches that an application developer could use for implementing a mobile app:

Mobile Optimised Web Current mobile platforms have web browsers so Moodle works immediately without modification however an interface designed for a large desktop screen won’t necessarily be adequate for the small screen of mobile phones. There are frameworks designed for mobile devices like the UCLA mobile framework[20] which provides a solution for the small screens The advantages of this approach are that the application will run without an installation needed on all mobile platforms- write once, run anywhere – though the application won’t be able to run offline and doesn’t have the ability to utilise all mobile features. HTML5 Application HTML5 introduces the ability to utilise all mobile features and act more like a native application including being able to run offline e.g. Google Apps. This has the advantage like the mobile optimised web approach of being interoperable between all mobile platforms and doesn’t require a special client to run. An HTML5 application can also cache data offline however because the development of HTML5 is still in its early days, an application written in HTML5 wouldn’t be able to harness the full performance of a native application. Native Mobile Application Apps are still the predominant paradigm for mobile development and have full capability of mobile features such as GPS. The Moodle community already has number of mobile apps but they rely on "screen scraping" the web interface, which means they can't work offline and don't add many features beyond the basic web interface. The advantage of a native application is that you can insure a stable build for a mobile platform which is easier to develop for than HTML5 however one would needs to develop a separate client for each mobile platform you support. Hybrid Mobile Application (cross-platform compiled) Another approach to developing a mobile application is to use a cross-platform development framework (Airplay SDK, Appcelerator Titanium and Corona SDK) that produce native code for various mobile platforms. This has the advantage of being able to generate iPhone/Android apps at the same time and keep them synchronised however debugging is often not as pleasant as on a native SDK and has some features missing like push notification. The framework is also dependant on an external company that may be too expensive and might have some vital features missing from the framework.

10

Table 1: Pros and Cons of the different approaches to developing a mobile app

Approach

Mobile-optimised Web

HTML5 app

Pros • Interoperable on all platforms without installation

• 'write once, run everywhere' • Customising of theme is easy • Interoperable on all platforms without installation • No special client required

Cons • Unable to run offline • Can’t utilise all mobile features • Unable to harness the full performance of a native application • Need to develop each client

Native mobile app Hybrid mobile app (cross-platform)

• Easy to develop for stable platforms independently • Full use of mobile functionality • Easier to develop than HTML5 • Debugging is often not as • All the benefits of a mobile app pleasant than on native SDK • Syncs development of • Missing Features e.g. Push iPhone/Android apps Notifications

Considering the approaches covered above, Moodle decided to initially tackle Native mobile apps because these have the most functionality and can assume safe builds when developing for mobile platforms. The apps would use the web services infrastructure developed in Moodle 2.x to communicate securely and consistently with Moodle sites. I feel the detailed discussion brought up by Moodle about the different approaches to developing a mobile application is extremely applicable and should be considered before implementing a mobile application.

11

2.2.3 Sakai This is the focus of my project as Sakai is the current learning management system in use at UCT. The ‘Sakai project’ is an open source, community driven learning management system that started in January 2004 when four universities; the University of Michigan, Stanford University, Indiana University, and the Massachusetts Institute of Technology began the development of a learning system to replace systems developed separately by each of the universities [7]. The Sakai architecture consists of two parts; the Sakai framework and ‘tools’. The framework supports the implementation of applications called ‘tools’ by providing appropriate web services and interfaces for the tool. To ensure compatibility between the tools of different learning management systems, Sakai decided to support the IMS Global Learning Consortiums Tool Portability Profile work group, if successful, this would ensure portability among learning systems like Moodle and Blackboard [12].

Sakai has had a portal for mobile devices since 2.4 [18] that does minimum requirements to transform the data into a small screen:   

It flattens the tool/site hierarchy so that they can coexist in the same location It serves up an iframeless experience It removes many elements from the portal that would be noise in a small screen

Figure 1: Vula Mobile Portal

12

The task of creating a finished interface that supports all the tools relies on community driven projects and until May 2011 mobile development efforts have been scattered across individual institutions with little coordination and collaboration. So the Universities of Cambridge, Florida, Indiana, and Oxford have proposed the establishment of a “Mobile Sakai” collaborative project to expand upon current, limited mobile functionality, build upon current work in progress, and to develop frameworks usable by local institutions to integrate Sakai into their own mobile initiatives [15]. This collaboration will become the core component of Mobile Sakai and extends an invitation to any other Sakai institutes that want to engage in the development of Mobile Sakai. The project is still early in its life cycle and has the opportunity for improvement as more tools can be integrated into the mobile interface but offers a stable platform to develop on.

Figure 2: Mobile interfaces of the University of Oxford, Indiana and Florida

1. 2. 3.

http://www.jisc.ac.uk/inform/inform31/MobileLearning.html http://www.pappy.com/app/iu-mobile http://www.flickr.com/photos/dwc/5815679999/

2.2.4 Critical Comparison The LMS mobile interfaces discussed in the previous chapter were chosen for comparison because they are the current major learning management systems in operation at institutions throughout the world. When comparing the mobile interfaces of the learning management systems in Table 2, there are certain features of some systems that outdo the other. For instance, Blackboard doesn’t support the migration from a different learning management system into a Blackboard installation, this feature is particularity useful to an institution investing into Blackboard after a dissatisfactory experience with a previous LMS. Both Moodle and Sakai – the open source LMSs – offer features to migrate from different learning management 13

systems but both quoted that Blackboard is tough to migrate from because it has three diverse versions. Table 2: Summary of the features offered by the LMS mobile interfaces LMS mobile

Supports

Supports

interface

migration from

Mobile

another LMS

Optimised Web

×

×

Blackboard

Commercial

Open

Licence

Native

Source

Fees

Mobile Platforms supported

√

×

√

iOS, Android

Moodle

√

×

×

√

Free

iOS, Android, Blackberry

Sakai

√

√

×

√

Free

none

Blackboard and Moodle both don’t support mobile optimised web interfaces as there is more mobile functionality through a native application though this restricts the interoperability between mobile platforms. Sakai mobile interface is going the opposite direction in the path of mobile optimised webpages that run in any mobile browser without an installation needed. Moodle and Sakai’s biggest advantage over Blackboard is the benefit of not needing to pay licence fees to utilise the software. One would certainly prefer open source over the Blackboard premiums that can reach up to $60,000 per annum

2.2.5 Thoughts If an institute was pondering which LMS to select, I would advise Moodle or Sakai firstly because they are open source and an institute doesn’t have to pay a premium to implement the system. When left with the decision between the mobile interface of Moodle or Sakai, they both have their advantages but depend on whether the institute believes in a native applications ability to fully utilise all mobile features or the interoperability of a mobile optimised web framework. I feel a hybrid web approach is substantial because it offers the benefits of native apps and one doesn’t need to develop separate applications for different mobile platforms. Sakai Mobile has a mobile portal with adequate navigation but lacks mobile user interfaces with each tool.

14

3.

Design

My responsibility in the ‘VulaMobi’ project is to develop the backend layer of the system; a software artefact that will interact directly with Vula and serve student and lecturer data to the mobile interface. In this chapter I will list the goals of the project and the design decisions that justify the application I implemented.

3.1

Goals 

Build a web application that acts as an intermediary service between Vula and the mobile interface: The web application will offer a third party service that extracts data from Vula and transports the data to the front-end. The approach taken must use an efficient method and be simple enough to interact with, for ease of use for my team members as well as other future users. This system will be accessible from any mobile device that calls it and should respond in minimal time. The data should be formatted in an organized structure that can be easily parsed and manipulated to display various data combinations.



Transport data in the most efficient means possible: To ensure feasible data transport speeds for a mobile application, I will research current web service formats available and justify the reasons for choosing the one over the other.

A web service standard has great dependence on the response time of an application, I will be aiming for the current standard with the least overhead and least amount of data needed to be transported.



Test the performance of the web application: I will test the performance of the web application I implement to determine the trade-offs in response time in respect to Vula. If the system were to ever to be deployed in full production, an understanding of limitations would be beneficial.

15

3.2

Architecture

VulaMobi is a Service Oriented Architecture (SOA), it is an architectural style whose goal is to achieve loose coupling among interacting software agents[10]. The client including the design of the interface is the responsibility of my team members. My task is to implement the intermediary web server and since the server I have to create interacts with the server of Vula; it may be more accurate to say the VulaMobi architecture is entirely a Client-ServerServer model.

Figure 3: Client-Server-Server

Figure 3 displays all the components that make up the VulaMobi architecture, the interaction between the components could either be standard HTTP Request or a type of web service, this will be explained further on in the chapter. In the rest of the chapter I will explain the interaction between the different components of the VulaMobi architecture.

3.3

Interaction with Client

The architecture of Vulamobi had a major change after we presented our initial design at our prototype demo. The client as explained in section 2.2.2 could be designed in four ways each with their certain benefits. In this section I will explain the design of the initial prototype and explain reasons behind the critical change to the architecture.

Our initial design for the client presented at our prototype demo was a ‘Mobile Optimised Web’ approach. We saw it fit for the purpose because a mobile optimised web approach is interoperable between mobile platforms by operating through the browser of the device. The other great benefit of developing a mobile optimised web is that there is no need to implement a client that is native on a mobile device. The web interface for mobiles can be 16

hosted from the server with a few javascript libraries. This leaves out the redundant time taken to develop a native application.

One idea of my team member was to design a client which could access the mobile phones native API’s to be able to access the camera. The camera could be used to take pictures of class activities or a solution on the blackboard. The pictures could then be accessed under the site the students uploaded the picture to. For a client to be able to access the native API’s of a phone it has to be designed as a native or hybrid application. This meant our system had two interfaces interacting with the back-end; the mobile optimised web and the native/hybrid application implemented by our team member.

The feedback from our prototype demo was that the system lacked a single entry point. We realised that the system was somewhat segregated because of two entry points; one being the web application accessed through the browser of users mobile phone and the other being the native app initially designed by George which allows use of the camera. We decided to go the hybrid application route to unify the interface into a single entity which includes the advantage of using native mobile API’s to access phone components and uses a framework that can be compiled onto any mobile platform i.e. iOS, Android & Blackberry.

A hybrid application would require web access to retrieve user information using a lightweight data interchange format. This format requires minimum battery use of the mobile device and minimum data exchange to ensure a responsive application. There are various methods to transport data between web applications such as XML and JSON.

XML( eXtendible Mark-up Language) and JSON(JavaScript Object Notation) are alike in that they both use plain text, both can be transported using AJAX and both are hierarchical. Where they differ is in the simplicity and speed of data, XML requires end tags names and a DOM parser to parse the data. JSON is shorter in text, uses arrays and only requires the built-in eval() function to parse the data. For applicatuions that synchronize data to a web server repeatedly power management is a key factor. JSON is the better format for data synchronization because it has better efficiency in terms of synchronization, parsing on server side and better performance in battery life[8].

Considering the facts that trump JSON over XML, I decided to use JSON as our data interchange format between the intermediary server and the hybrid application (client). JSON is much more lightweight than XML and is well adapted for mobile application support.

17

3.4

Interaction with Vula

Vula was installed by UCT’s Centre for Educational Resources (CET)[3] and has certain web services enabled but not thorough support for all tools e.g. Gradebook, Resources, Assignments, Chatroom, Participants. Some tools don’t have a web service enabled for it at all and data has to be accessed by parsing web pages. A site on Vula represents a course a student is enrolled in, each of these sites incorporate a selection of tools, and the same combination of tools is highly unlikely across different sites. No tool can be guaranteeded to appear on every site. Due to all the different combinations of tools for a certain site, we had to decide which tools we were going to support.

Deciding which tools to support brought up a design issues because we needed to establish who our user is. We found that for each faculty there were different preferences of what tools to support e.g. in the Commerce faculty they make extensive use of the ‘quiz’ tool to allocate weekly online tests for courses with a large enrolment count. However in the Computer Science department we don’t make use of the quiz tool at all. After some HCI research and user consultation by my team members – who will further justify in their reports - we choose to support these tools:



Announcements:

The ‘announcements’ tool is the only tool that has a decent web service on Vula. Under ‘vula.uct.ac.za/direct’ you will find a list of RESTful web services available. The Vula announcement web service can return data in XML or JSON if you simply encode site-ID and data type in the URL.



Gradebook:

Vula does not have a web service enabled for ‘gradebook’ currently. The only way to access course results for a site is to parse the results on a web page using the HTML Dom. The gradebook is useful however across faculties because the results that get inserted into the gradebook can come from assignments or quizzes. Different faculties use assignments or quizzes but the both need the gradebook tool to see results.



Resources:

The ‘resources’ tool is usually a given to be used by a site because most courses require access to course material in a centralised means. However Vula doesn’t have a web service enabled for resources. Like the gradebook the only possible approach to access the data is to parse HTML Dom of web pages. 18



Chatroom:

The ‘chatroom’ was a tricky decision to be supported because again it’s a decision depending on which faculties use the tool or not but for the sake of this honours project we will be focusing on the Computer Science Department which has seen a great deal of dependence on the chatroom to negotiate class decisions and obtain information from other students.



Assignments:

The ‘assignments’ tool has a direct correlation to the ‘gradebook’ because when an assignment is handed and then returned, the result appears in the gradebook. This also happens for ‘quizzes’, when completed the final result of the test or quiz appears in the gradebook which is why gradebook has a higher priority to be supported by us.



Participants

For general information about a course and who is enrolled, we decided to support the roster of a course. Students use the information to get the email address or the student number of their colleagues and lecturers conducting the course.

The system will not only support the tools listed above but include functions to return information about the student, meaning the student name and student number. Quite a critical component is a function that returns all the active sites for a user, active sites are the tabs that appear at the top of the Vula header when a user logs into the website. The home page of the hybrid application would require this list of active sites when the user first logs in.

3.5

Frameworks

Frameworks are designed to save development time for the programmer by providing builtin functionality to assist in common tasks and reduce the amount of code needed to produce an intended outcome. Since the evolution into Web 2.0, a variety of frameworks are available for use under open source licences.

When choosing a web application framework, you first need to identify the environment the application will reside on. In terms of VulaMobi, it would be preferable to deploy the intermediary server on the local network of Vula to ensure a high response time therefore I choose to use the space on nightmare given to all honours students. Nightmare has a Linux OS with a PHP environment enabled so I researched which PHP frameworks were currently 19

available on the web. There are many well established community’s devoted to maintain PHP frameworks but I found two that were highly recommended for the task; the Yii Framework[23] and CodeIgnitor Framework[4]. I will explain my experience with these frameworks and which one I chose for the job in section 4.2.

3.6

API

To allow my team members to utilize the backend effectively they require an interface to all the different functionality of the system therefore I developed and documented an application programming interface. To allow public access to the source code, I choose to use version control system called ‘git’, more formally it is known as a distributed revision control system because the program can be used by a team developing the same application and can collaborate on the same source code. GitHub[9] is a website dedicated to hosting git repositories and allows anyone to be able to contribute to a project.

To document the system, I uploaded a repository on GitHub for the VulaMobi back-end[21]. GitHub has a Wiki function that creates a page with whatever information the user edits it to therefore I used this feature for the documentation of the API. The wiki lists all the functions of the system and what are the required parameters and responses of each function. By uploading this repository I hope to see future contributions from external developers or future honours projects.

Figure 4: System Overview

Given the frameworks and data interchange formats described in this chapter, Figure 4 displays an update of the VulaMobi architecture to help give an understanding of the different components and the flow of data. Sencha is the hybrid application framework – entirely javascript - chosen by my group members to develop the client.

20

4.

Implementation

This chapter details how I went about implementing the design discussed in the previous chapter.

4.1

Prototype

As mentioned in the previous chapter the prototype was developed using a mobile optimised web approach. The back-end processing would be performed by PHP due to the environment of nightmare. The front-end would be achieved by using javascript libraries that automatically adapt to the size of the screen of the mobile device accessing the website. We decided to use jQuery Mobile as the framework for the user interface because it was easy to get working out of the box and is cross-platform between most mobile operating systems.

The PHP and javascript are included together in a single script when developing a mobile optimised web. This means there is no modularity between the front-end and back-end development causing conflict issues when two people develop on the same script. The obvious solution is to use a distributed version control system like ‘git’ to track and change made by team members before committing your own changes. Considering this, I introduced my team-members to ‘git’ and ‘GitHub’ with a small demonstration though their interest proved to be lacking because it meant learning version control for the first time. I still highly advise the use of a distributed version control system when developing a group project, especially when there are four or more members.

To explain what back-end work was required for the prototype, I first need to explain what each of the front-end members responsibilities were: 

Donovan:

Donovan would focus on designing an innovative tool for students tracking the progress of their work and course results called the ‘Feedback’ tool. 

George:

George would concentrate on a tool that incorporates the use of mobile multimedia for M-learning. 

Tatenda:

To redesign the Vula mobile interface, Tatenda wasn’t required to add any new tools but rather had the responsibility of designing the applications interface to ensure consistency and ease of use. 21

The prototype shown in figure 5 was designed for the initial demonstration as a vertical prototype because each team member designing the user-interface focussed on the functionality of their component. In terms of back-end work; both Donovan and Tatenda required the data from the ‘gradebook’ of a student for the feedback tool and a standard view respectively. Before I was able to start work on the gradebook, I first had to implement a login function that performs cookie authentication with Vula. Vula keeps a session via cookies every time a user logs-in, these cookies expire after a certain time. Once that was completed, my attention moved towards the ‘gradebook’ tool which currently has no web service enabled for it on Vula. The only way to access the data would be to crawl the web pages of Vula.

Figure 5: Prototype Interface (Login,Home,Active-Sites view)

To crawl html pages with PHP you first need to access external web pages from script. A common and widly known approach is to use cURL, a library used to transfer data using various protocols. cURL is an alternative approach to accessing web content other than web services. Once the data was received from an address like the gradebook of a student, a method to parse the HTML Dom was required. I used a PHP library called Simple HTML Dom to parse the Dom and access an intended element to extract data like grade results of a student. The combination of these wonderful PHP libraries creates a web crawler that can access information on any web page.

George required a location to upload the pictures taken by his camera tool, it would be preferable to upload the pictures for a user on Vula but no method was found to do this as of yet. There is a resources tool for each student under their ‘MyWorkspace’ site and is an ideal location to upload the pictures to except cURL is not able to perform this task because the submit form uses Javascript and not a static link. Instead the pictures will be uploaded on the intermediary server under a folder named after a user student number. To support 22

George’s requirements I implemented a function to upload a file to the server and a function that lists all the files in a student’s picture folder.

When the time came to demonstrate the prototype in front of the first and second reader, as said in the design chapter, there was a fault in the design identified by the readers. The fault was the segregation of entry points into the application between George’s native application and the mobile optimised web. Building two separate interface designs was infeasible as this would require twice as much work and two entry points. When comparing the two approaches, we chose the hybrid application route because George’s functionality was dependent on accessing the mobile phones native API’s for camera functionality. Even though HTML5 has seen extensive improvement lately, it is still early in its development cycle and does not have functionality to access mobile phone camera’s yet which leaves out a mobile optimised web approach.

4.2

API Development

Choosing the hybrid application approach meant the architecture of system became a Client-Server Model between the hybrid application built by the front-end members and the intermediary server I built. Now that there was a distinct separation between client and server, I could develop the back-end without fear of team members editing or changing functionality. Modern web frameworks have adapted the Model-View-Controller (MVC) design pattern to separate the representation of information from the user’s interaction with it. Utilizing this design approach ensures modularity between components developed by my team members

Section 3.5 mentioned the two popular PHP frameworks; Yii and CodeIgnitor. Before investing time into a framework developing the back-end, I tested out a ‘helloworld’ installation of each framework to determine which one required the minimal learning curve and least effort to operate. Yii is designed in a way much like Ruby on Rails which provides you with command-line-based automatic code generation; the framework comes with many other rich features but involves a slightly steep learning curve for the user to learn all the different commands. CodeIgnitor on the other hand has all the rich features that Yii has to offer but does not require a command line to interact with the framework, therefore I chose CodeIgnitor PHP web application framework to aid me in implementing the intermediary server.

23

To collect requirements from my team members of what functionality they required from the intermediary server, I asked them to fill out a form with the name of the function, the input parameters and the expected JSON output: Table 3: Team Back-End Requirements

Donovan: Call GetStudentGrades

Input Parameters Course

GetCourseAverages

Course

GetRole

Course

GetStudentResources

Course

Returns An array of the students results for the specified course An array of the class averages for each assignment/test Returns the role of a participant e.g Lecturer - Student An Array of the resources for a specified course. Some thought needs to go into how to represent this as it’s effectively a tree.

George: Call Getimages

Input Parameters Student number or ID

Upload

File

Getfile

Student number or ID

Returns Returns a JSON encoded object with all the images for the particular user logged in. Doesn’t return anything but instead uploads picture to the user directory on the server Returns the JSON encoded image

Tatenda: Call GetGrades

Input Parameters Course

GetAllGrades

Course

GetAnnouncements

Course

GetAllAnnouncements

Course

GetResources

Course

GetChatroom

Course

GetAssignments

Course

GetParticipants

Course

Returns Returns a JSON encoded object with grade for a Course Returns a JSON encoded object with grades of all Courses Returns a JSON encoded object with announcements for a Course Returns a JSON encoded object with announcements for all Courses Returns a JSON encoded object with resources for a Course Returns a JSON encoded object with chat for a Course Returns a JSON encoded object with assignments for a Course Returns a JSON encoded object with participants for a Course 24

Considering all the requirements listed, I then needed an approach to develop the web services that can be called asynchronously by any device. Asynchronous JavaScript and XML(AJAX) is a web development technique used on the client-side to perform asynchronous calls to the server. This technique can be used to implement the data flow for a mobile web application. After extended research, I was able to find an Ajax Framework for CodeIgnitor which provided simple classes that use CodeIgnitor controllers to access parameters from the URL.

4.2.1 Same Origin Policy When we initially began integrating the front-end and back-end for the first time, an unforeseen problem arose when we started the process. We noticed an error occurring when sending a request from the hybrid app to the intermediary server using XMLHttpRequest. Instead of an expected JSON output, the browsers console printed “Cross Origin request error”. This error refers to the Same Origin policy; which was designed as a security feature to prevent scripts running on an external server from accessing the methods and properties of pages of a different domain.

Under the Same Origin policy; when a server receives a request, the server checks the URL of the request and determines whether it is from the same domain as the server or a potentially malicious site. When creating web services to integrate external systems into your own system, the requests will always come from an external domain; therefore I looked at an approach for a solution. Cross-Origin Resource Sharing technique [11] extends existing HTTP headers with a new Origin request header and a new Access-Control-AllowOrigin response header. The server is able to list which domains are allowed to access the resource in the response header, I set the field in the response header to Access-ControlAllow-Origin to *(all).

4.2.2 PDA Portal In Donovan’s research he came across a Ph.D student in the Physics department called Angus Comrie who has been working on a project to improve on the interaction of the quiz tool. While researching for his project, Angus meet Donovan who explained to him what my part of the system is. This interested Angus because parts of his project have same aspects to ours.

Angus sent me an email informing me that while working with the code from the GitHub repository [21], he noticed that the format of the gradebook is different if you are logged in as a student or lecturer. The lecturer view has a list of all the students and their average marks as opposed to a student which only shows their own marks. Angus advised me to 25

rather crawl the PDA portal instead of the standard desktop portal because the format of certain tools is the same whether you are logged in as a student or a lecturer. I was unaware of the difference in format of the gradebook when I began this project and since I have student credentials not lecturer credentials, I didn’t accommodate for the lecturer interface and focused the project on the student interface.

4.3

API Functions

In section 3.4, I covered the tools I decided to support and mentioned I would have to create additional functions to fully utilise the VulaMobi web services. There is a certain navigation protocol to login and navigate with the VulaMobi back-end which explains why I created the additional functionality. Vula’s current mobile portal initially logs you into a home page with a list of the user’s active sites, when you select an active site you will be redirected to a page for that site with a list of supported tool of that site.

Figure 6: Navigation Protocol

Figure 6 describes the process Vula uses to navigate through the mobile portal and is the navigation protocol adopted for VulaMobi. This is because the intermediary server is a third party communicating between Vula and our front-end and is effectively navigating through Vula. The list of active sites for a user and the list of supported tools of a certain site are both required when you navigate with the Vula Portal therefore I created additional functions indicated in blue. These are the functions the server has to perform when transitioning between the views. The red is the action taken by the user to perform a transition between views.

26

The base URL for the VulaMobi back-end web services is: “http://people.cs.uct.ac.za/~swatermeyer/VulaMobi/ajax.php?”

After the ‘?’ symbol comes the parameters for the CodeIgnitor AJAX framework in order of ‘controller/function’ e.g. if you call ‘test/t’, you will be calling the controller named ‘test’ and the function named ‘t’.

Note: Whenever you make a call to a VulaMobi web service, you are required to POST the ‘username’ and ‘password’ because the intermediary server will re-login the user every time a new call is executed. The reason the server needs to re-login every time is due to the Same Origin Policy mentioned in section 4.2.1; when setting Access-Control-Allow-Origin in the response header to allow access to all domains consequently makes the CodeIgniter Session class stop working because any domain can now call the script and not possible to keep a session for a user with an initial login.

Table 4: Overview of the API Functions

Call

Input Parameters

auth/login

username & password

auth/logout student/sites

null null

student/sup_tools

site_id

student/name

null

announce/site

site_id

announce/body

site_id, announce_id

announce/all

null

grade/site

site_id

grade/all

null

resource/site

site_id

resource/page

page_id

chat/site

site_id

chat/submit

site_id

Returns A text message: logged_in or incorrect details A text message: logged_out JSON Object of active sites for user JSON Object of supported tools for a given site_id A text message of user name JSON Object of meta-data for announcements of a given site_id HTML Text of an announcement for a given announce_id taken from meta-data JSON Object of announcement meta-data for all active sites of user JSON Object of grades for a given site_id JSON Object of grades for all active sites of user JSON Object of a list of all the files in a site JSON Object of files and folders under a specific folder JSON Object of chat messages for a given site_id A text message: Success if sent 27

assign/site

site_id

assign/all

null

role/site

site_id

role/roster

site_id

gallery/upload

null

gallery/dir

null

JSON Object of assignments for a given site_id JSON Object of assignments for all active sites of user A text message of user’s role in site JSON Object of participants for a given site_id Upload picture from native application to intermediary server JSON Object of list of pictures under user’s folder on intermediary server

Most of the algorithms for the API functions follow a simple protocol of first fetching the relevant web page with cURL then parse the HTML Dom and extract the intended information. cURL can perform multiple request’s within a single script which is the case for ‘resource/site’ which returns a list of all the files of all the folders for a site. If you are familiar with the Vula interface you will notice that a new page loads every time you select a new folder under the resources tool. The ‘resource/site’ function executes as many http request’s as there are folders in a site therefore suffers a low response time but returns entire resource information for a site.

In order to get a feel of what all the API functions can do, I created a small demonstration on the nightmare page[22] using jQuery to perform the AJAX requests. The demo page includes a button for each call and a window to display the output. For detailed documentation on the different responses of each API function or the field values of JSON responses, check the wiki under the GitHub repository for VulaMobi.

4.4

Limitations of System

The system is aimed to be a complete third party between the hybrid application and Vula. All the API functions except for ‘gallery/upload’ pull data; the upload function pushes data to the intermediary server but not onto Vula as mentioned in section 4.1. The server is not able to upload data to Vula because there is no way to automate the submit option on the MyWorkspace resource tool using cURL. Having data flow from Vula to the front-end but only flow back to the intermediary server not to Vula is seen as a limitation. Vula’s lack of sufficient web services restricts integration from external systems like VulaMobi.

VulaMobi uses an AJAX framework to integrate with the front-end which is ideal for a mobile application but is not designed to be completely modular. Meaning if the system 28

used a Restful framework then external mobile applications or web applications can integrate with the system because it will have additional features such as an XML or JSON response. Improving the modularity benefits the system as a whole and encourages continued maintenance from future projects.

29

5.

Testing

For testing the performance of a system there has to be a benchmark established to compare against. An understandable choice is to test Vula against VulaMobi because the back-end system simulates Vula requests it seems a plausible option to benchmark. To compare the pair the best option would be to match which API function corresponds to a certain page on the PDA Portal. e.g. the time to load the Vula PDA Portal home page against student/sites API function which returns the active sites for a user.

cURL has a considerable amount of classes including a ‘getinfo’ function which returns request information such as total time to respond and download speed. The ‘getinfo’ class includes a size-downloaded field but the test will be comparing JSON responses against the Vula PDA Portal; size would be irrelevant because the PDA portal will be returning HTML which is larger in data size compared to JSON. cURL can be used to perform multiple requests to various URL’s therefore information about each requested URL can be recorded and executed within a single server script.

The test will be executed from two locations for broad distribution in result data. One test will be performed from my house which has an ISP supported 384kbps ADSL line. The other location the test can be executed from is on the local UCT network which has high response speeds with Vula. The second test will be performed from my honours lab compute. I chose ‘total_time’ and ‘speed_download’ as the comparison data because of their relevant units that measure performance. The API functions that have as much resemblance to a Vula PDA Portal page are listed below:      

student/sites against the Vula PDA Portal home page student/sup_tools which returns the supported tools for a site against the PDA home page grade/site against the PDA gradebook page role/roster which returns the a list of participants for a site against the PDA participants page announce/site against the PDA announcements page chat/site against the PDA chatroom page

The algorithm of the test PHP server script sequentially requests each of the links described above. The script executes each URL ten times then records the average ‘total_time’ and ‘speed_download’ for the ten requests. Averaging the data of the same request’s accounts for inherent fluctuations in network speeds and gains more accurate data.

30

5.1

ADSL Test

The ADSL test is executed on a 384Kbps line, which is not as responsive as the UCT network but is an adequate network for the test. The response time is the total time taken for a requested URL to respond. Obviously the least time is preferable but bear in mind, the backend is a third party passing on communication between Vula and the mobile application therefore the bottleneck in the response is the speed Vula can respond.

Figure 7: ADSL Response Time

Figure 7 shows that VulaMobi is overall as responsive as Vula but when the request has to demand a lot of data the response time grows substantially. This is seen with the chatroom request which has to pull a sites entire amount of chat messages for instance CS Honours 2012 has to pull more than a 1000 message. Even though the size of data downloaded for the VulaMobi JSON requests are much smaller than the HTML requests of Vula; VulaMobi still doesn’t respond faster than Vula proving the bottleneck of the total time for a request lies with Vula.

If you test for the least responsive time then you expect the requests with the greatest download speed to correspond to the request with the least time to respond. Download speed is the second metric I will be testing for as it is a good performance measuring metric like response time.

31

Figure 8: ADSL Download Speed

When focusing on the speed the script downloads the requests, figure 8 shows Vula evidently trumps the download speeds of VulaMobi. The response times of VulaMobi were only slighty lagging behind Vula but in terms of download speed Vula has a far greater throughput. The only API function that seems to beat Vula is the Announcements function which returns a JSON object of all the announcement meta-data for a site. The time to respond for this function depends on the amount of announcements there are in a site.

5.2

Honours Lab Test

The second location for the test will be executed from the honours lab where computer terminals have access to the UCT network and have direct local access to Vula. The responsive speeds increase tenfold compared to the connection limits of the ADSL line; this is shown in figure 9 where the max response time is just less than two seconds which is almost half the response time on the ADSL line. All of Vula’s responses respond in under 500 ms on the UCT network which is expected for a university’s learning management system that handles a few thousand staff and students a day.

32

Figure 9: Honours Lab Response Time

Figure 10’s max speed increases five times compared to the download speeds of the ADSL line; as soon as a script is executed on the local network of Vula the download speeds sky rocket. VulaMobi is still behind in download speed but even on the local network, the announcements API function responds more rapidly than Vula.

Figure 10: Honours Lab Download Speed 33

The test proves there is a clear distinguishment between the response time and download speeds of VulaMobi compared to Vula. I reiterate; VulaMobi is a third party passing on communication between Vula and the mobile application therefore the bottleneck in the response is the time Vula can respond in. It is not possible for VulaMobi to respond faster than Vula so it is expected to see a delay in the response time results and minimal download speeds compared to Vula. The purpose of the test is to establish if the difference in performance is infeasible for VulaMobis’s purpose.

Given the test data, I feel VulaMobi is substantial for job of mobile application support because even though there is a delay in response, the system will respond within an adequate time and returns data in a mobile application friendly format. The data also proves that the system should definitely be deployed on the UCT network for far greater performance.

34

6.

Conclusion

The original problem of this project was to build a web application that acts as an intermediary service between Vula and the mobile interface; this initially seemed a feasible task to complete and I felt confident I could create a bridge in communication between Vula and the mobile interface. My research exposed JSON as the modern approach for the data interchange format in mobile application development and proved to be a sufficient choice.

The back-end system I implemented extends the standard web services that Vula has enabled even though parsing HTML dom is the not conventional way to integrate systems, the API is able to abstract that back end processing and provide third party services with a simple format to integrate into. Using an AJAX framework to provide web services was a sufficient approach but to ensure further modularity between all third party services, a Restful framework with various response formats would be more applicable. Not all services use JSON but may use XML for data interchange format therefore must be accounted for.

The experience of this project has taught me precious knowledge about web technologies that I can use to improve my career skills. I have had exposure not only to server side development but also the requirements and design of a mobile application that interacts with the server. This project was focused on system development and implementation because the software artefact I implemented plays an imperative role in the architecture of the entire VulaMobi system.

The back-end system achieves the aim of being a web application that acts as an intermediary service between Vula and the mobile interface. It transports data in an efficient interchange format and doesn’t lack in performance required for a mobile application.

35

7.

References

[1]

About Moodle - MoodleDocs: http://docs.moodle.org/22/en/About_Moodle. Accessed: 2012-05-12.

[2]

Blackboard’s Next Phase | Inside Higher Ed: http://www.insidehighered.com/news/2011/02/22/blackboard_evolves_its_business _strategy_in_light_of_market_saturation_in_higher_ed. Accessed: 2012-05-12.

[3]

Centre for Educational Technology: http://www.cet.uct.ac.za/. Accessed: 2012-10-18.

[4]

CodeIgniter - Open source PHP web application framework: http://codeigniter.com/. Accessed: 2012-10-19.

[5]

CourseWork: an Open Source Course Management System: http://getcoursework.stanford.edu/. Accessed: 2012-05-12.

[6]

Ellis, R. 2007. Minimum indicators to assure quality of LMS-supported blended learning. JOURNAL OF EDUCATIONAL. 10, (2007), 60–70.

[7]

Farmer, J. 2005. Sakai: eLearning and more. EUNIS 2005-Leadership and Strategy in a. (2005).

[8]

Gil, B. and Trezentos, P. 2011. Impacts of data interchange formats on energy consumption and performance in smartphones. Proceedings of the 2011 Workshop on Open Source and Design of Communication - OSDOC ’11. (2011), 1.

[9]

GitHub - web hosting of Git repositories: https://github.com/. Accessed: 2012-10-19.

[10]

Hao He 2003. SOA Defined and Explained. XML.com. (2003), 1–5.

[11]

Huang, L.-S. et al. 2010. Protecting browsers from cross-origin CSS attacks. Proceedings of the 17th ACM conference on Computer and communications security CCS ’10. (2010), 619.

[12]

It’s Official: Sakai 3 has passed IMS Global’s LTI Certification | Sakai Project: http://www.sakaiproject.org/blogs/lancespeelmon/it%E2%80%99s-official-sakai-3has-passed-ims-global%E2%80%99s-lti-certification. Accessed: 2012-10-12.

[13]

LMS Definition from PC Magazine Encyclopedia: http://www.pcmag.com/encyclopedia_term/0,2542,t=LMS&i=46205,00.asp. Accessed: 2012-10-12.

[14]

Landon, B. and Poulin, R. 2006. MASSACHUSETTS INSTITUTE OF TECHNOLOGY Peer Comparison - of - Course / Learning Management Systems , Course Materials Life Cycle , and Related Costs Final Report.

36

[15]

Mobile Sakai : A Proposal To The Sakai Community - 006: 2011. https://confluence.sakaiproject.org/download/attachments/75662075/mobile+sakai +proposal+-+006.doc?version=3&modificationDate=1307738539000.

[16]

Moodle: A Virtual Learning Environment for the Rest of Us: http://www.teslej.org/wordpress/issues/volume8/ej30/ej30m2/. Accessed: 2012-05-12.

[17]

Rugg, B.M. 2011. Charting a new course from blackboard to sakai. Proceeding of the 39th ACM annual conference on SIGUCCS - SIGUCCS ’11. (2011), 53.

[18]

The Sakai PDA portal « Gonzalo Silverio’s Weblog: 2008. http://gonzalosilverio.wordpress.com/2008/11/20/the-sakai-pda-portal/. Accessed: 2012-05-13.

[19]

The Sakai Project: http://www.sakaiproject.org/. Accessed: 2012-10-12.

[20]

UCLA Mobile Web Framework: http://mwf.ucla.edu/. Accessed: 2012-05-14.

[21]

VulaMobi API - GitHub: https://github.com/zuch/VulaMobi. Accessed: 2012-10-19.

[22]

VulaMobi API: http://people.cs.uct.ac.za/~swatermeyer/VulaMobi/. Accessed: 201210-14.

[23]

Yii Framework: Best for Web 2.0 Development: http://www.yiiframework.com/. Accessed: 2012-10-19.

37

A.

API Funtions

Call

Input Parameters

auth/login

username & password

auth/logout student/sites

null null

student/sup_tools

site_id

student/name

null

announce/site

site_id

announce/body

site_id, announce_id

announce/all

null

grade/site

site_id

grade/all

null

resource/site

site_id

resource/page

page_id

chat/site

site_id

chat/submit

site_id

assign/site

site_id

assign/all

null

role/site

site_id

role/roster

site_id

gallery/upload

null

gallery/dir

null

Returns A text message: logged_in or incorrect details A text message: logged_out JSON Object of active sites for user JSON Object of supported tools for a given site_id A text message of user name JSON Object of meta-data for announcements of a given site_id HTML Text of an announcement for a given announce_id taken from meta-data JSON Object of announcement meta-data for all active sites of user JSON Object of grades for a given site_id JSON Object of grades for all active sites of user JSON Object of a list of all the files in a site JSON Object of files and folders under a specific folder JSON Object of chat messages for a given site_id A text message: Success if sent JSON Object of assignments for a given site_id JSON Object of assignments for all active sites of user A text message of user’s role in site JSON Object of participants for a given site_id Upload picture from native application to intermediary server JSON Object of list of pictures under user’s folder on intermediary server

38