Many thanks to Peter Chapman (Senior Lecturer and iTest App developer) at Newman University for providing this technical perspective to the iTest app which I reported on in my previous blog entry.
The Back End and the Internals
Early decisions as to the very nature of the app were difficult. Do we write it as a standalone with Apple, Android and Windows etc. versions meaning users would have to download and install the app? This approach has the advantage of speed, no need for logins and better graphics. The downsides are downloads, multiple development environments, appstores, a need to re-download when questions and feedback are customised and an added layer of complexity for future collection of data centrally for analysis.
The alternative is to write the app so it runs in a browser. The app is a web page held on a central server but written using the JQuery Mobile Library (JQM) which allows the appearance of the interface to be virtually indistinguishable from a native app. This approach has the advantage of one development environment, no downloads, runs on most devices, instant upgrades and ease of adding future data analysis functionality. Downsides are speed (particularly if the app architecture requires continuous database hits), user data-plan capacities and the rather contentious issue of ‘is this really an app?’.
Having decided on the JQM approach an early question was about persistent data. The iTest questions and feedback are persistent but the responses and scores transitory. Making user responses and scores persistent means providing a login mechanism with its attendant user names, identification, email address storage etc. This was shelved but not discarded. Next was where and how to store the persistent data. Costs dictated the use of a MySQL database with a simple four table structure administered ‘out of band’ with the phpMyAdmin utility. Communication between the app and the database is via a collection of PHP scripts forming an API to the DB. This API approach greatly facilitated the development of a separate administration ‘app’, also developed in JQM (but to be run in a browser on a PC). This app, as illustrated earlier, uses the API to change the persistent data allowing an administrator to extensively customise the user version of iTest.
To negate the need for continuous server hits (to the database) the app architecture loads all categories, questions and intro text into arrays the moment the iTest URL is accessed. Thus the database is replicated onto the mobile device and user responses recorded in the arrays allowing question navigation and response alteration by the user without further server database access. In practise speed is entirely acceptable even over 3G or WiFi.
After completing the questions the user scores for each category are calculated by processing the relevant internal array and each category score banded into low, medium or high. The score is then shown on the tiles of the scores tab. This brings us to how to provide the user with feedback. One obvious way would be to connect the tiles to external web pages (external to the app) which an administrator can edit at will but the pages must be responsive. However jumping outside the app will lose intuitive navigation back to the app. It also means that the admin app must provide an editing facility for the linking URLs. Alternatively we can store the HTML for the feedback pages in the database and provide a mechanism to edit the feedback HTML in the admin app. We decided the latter but had to overcome a few problems with MYSQL not liking the range of characters used in HTML.
Considerations for usage within an institution
Firstly, you will need a server which is WAMP (Windows, Apache, MySQL, PHP) or LAMP (Linux, Apache, MySQL, PHP) configured. The MySQL database will need an account set up and be populated with the iTest database tables. One centrally held PHP config file stores the relevant password, user name and database name which will relate to the admin user. Users of the iTest app itself will just require the URL to index.php file on the web server. If several separate instances of iTest are required on the same server (perhaps with different questions and responses) then the database would be replicated over several accounts. This may all sound complicated but in reality is quite straightforward for any I.T. department.