Table of contents
Here, we describe the technical details of the mobile app and its back-end server, intended to assist you in being able to reproduce the system for your own project. This is intended for those who are software developers, IT administrators or others who have experience in working on computer software and hardware.
Please note that while this description below applies to the mobile app and server made for YSSC specifically, the source code can be modified as little or as much as you see fit for your school’s or organisation’s needs. For more details on the source code itself, go to the Source code page.
Mobile app
Functionality
Designed for the students of YSSC, the mobile app is intended to show information about the compost scheme at the school, as well as describe why it is being done, and the details about compost such as what it is and how it is made. Additionally, it shows the current points total for each house as well as the current readings from the compost sensors. We consider the most important informational screen to be that which shows what scraps can be brought in from home for composting.
This information is separated out into different screens, which users can navigate between using the scroll-able menu at the top of the screen. Originally, this was a drop down menu, but was changed to its current form after the students suggested that navigation should be controlled using gestures.
These informational screens mainly use text and images. On some pages they are hidden away in red “tabs” that are revealed when the user taps on them. Some pages also contain videos that automatically play when the user navigates to that screen, and stop and return to the beginning when the user navigates away. There is also a screen that allows the user to take a quiz to test their knowledge about compost and the circular food economy. Five questions are selected from random from a larger collection of questions, and the user gets a summary of what they answered correctly and incorrectly at the end.
The app gets the house points and the sensor readings from the Internet of Things. A user can scan a QR code (introduced to allow the app on the Apple App Store, as they required functionality that would only work on a mobile device) to open the current house points, which are retrieved from the server. Viewing the current readings from the sensors also requires a connection to the server; the server is linked up to the cloud data server (in this case, ThingsBoard) to download new sensor data when it is sent by the sensor.
To prevent users outside of the school from attempting to use the app, a pass code is required on loading the app which is supplied to the school to give out to students and staff (though if you are coding your own version of the app, this pass code requirement can be easily removed).
Technologies
For ease of cross-platform development, the React Native framework has been used. It uses native UI elements to render mobile apps and has allowed the app to work on both iOS and Android platforms without having to manage distinct versions.
React Native is built upon React, a JavaScript library for building user interfaces; therefore it is coded using JavaScript as well as JSX syntax for defining elements, similar to a web page. A large variety of different JavaScript libraries is also available to add functionality and components to a React Native app; the mobile app makes use of several of them.
The Expo platform was also used while developing the mobile app. This platform is intended to assist in development and testing of React Native apps, and was used in this project to test the mobile app on a variety of iOS and Android devices using emulators, to ensure that functionality was the same across them. However, when preparing for a release build, Expo is removed from the project so that the code for collecting advertising IDs is not included (the app does not use this, but having the code included still necessitates a declaration that the advertising ID is collected).
Server
Functionality
In order to enable some of the functionality on the mobile app, there is also a server application that is (as of the writing) hosted on YSSC’s IT administrator’s computers. It is intended to store data on two different things:
- The current points tally for each house at the school, based on how many food scraps the students bring in; and
- The readings from the custom-made sensors, measuring temperature, humidity and methane.
The server will send this information to the mobile app when the user views the house scores or compost sensor screens on the latter.
For administration purposes, the server also provides a set of web pages. There are two levels of user accounts: regular and administrator. Regular users are able to access the page for changing house points. This is typically done by manually setting the number of points for a specific house and submitting it to the server. An automated way to add house points when a student brings in food scraps has not been implemented as of yet, but this page also includes the ability to parse a CSV file from the cloud library system Oliver which is used by YSSC to check for returned compost caddies.
Administrator users gain access to additional pages on the web site, and a default administrator account is created when the server is first set up (if the instructions included with the source code are followed). An administrator can add and remove from the list of compost sensors that are stored in the database; the server will automatically refresh the sensor connections to reflect the new list. Every 30 minutes, if the connections are still valid and the sensors are operational, the latest set of data will be downloaded and stored on the server. If there are any issues that cause the connection to the sensors to be interrupted, the connection to all of them can be refreshed manually.
Also accessible to administrators is a page to manage user accounts. Accounts can be created, modified, or removed. If a user has forgotten their password, the administrator can also reset it to a random string (and contact the user to inform them of the new password). All logged in users can access a separate page to change their password at any time.
There is also a setting to activate or deactivate accounts without removing them completely; this is partly left over from when users could create their own user accounts from the mobile app, when the app required an account for certain functions. To prevent administration becoming impossible without modifying the database using a database management system, the last administrators account cannot be deactivated or removed.
The web site also includes pages for the public; apart from the home page, all users, including unauthenticated users, can view the Public information page that shows information about the circular food economy scheme at the school the current house points, and the latest readings for all sensors.
It should be noted that the mobile app can still function without the server application. It only connects to it in order to show the house points and latest sensor readings.
The gallery below shows some of the pages in the server website. Click on one of the images to show the full screenshot.
Technologies
Like the mobile app, the server application is also coded using JavaScript. In this case, the Node.js library has been selected, along with the Express.js framework to handle the code for the main functionality of the server. Several other libraries are also used, such as cookie-session for storing login information for the current user and Knex.js for communicating with the database.
For the web pages that are visible to users, the Pug template engine is used in order to enable pages to be rendered dynamically depending on the current state of the server. Initially, the pages had a bare bones design, but later on, the Fomantic UI library – intended to ease the process of styling a website as well as including scalability to different devices – was added to aid usability as well as provide a more polished look to public visitors.
Currently, the cloud data service that is used to initially store the data from the sensors, and which this server application connects to, is ThingsBoard, which was selected by Substation33. This server uses ThingsBoard’s API in order to open a persistent websocket connection for each sensor registered in the database. It then monitors this connection for any messages sent from ThingsBoard, and if it receives the data for a new set of sensor readings, it stores it in the database.
Note that while the code currently only works with the ThingsBoard API, a different cloud service API can be used, though this will require modification of the code that connects to ThingsBoard and downloads the information. Alternatives for ThingsBoard include Adafruit IO and ThingSpeak.
The server includes a relational database which is used to store data on house points, compost readings and user accounts. It was coded for using either a MySQL or MariaDB database – the two are interchangeable for the purposes of this server and which is chosen is down to developer preference.
While Oliver is used as the school’s cloud library system and the server application parses CSVs downloaded from there, it is not compulsory to use this, just as it is not needed to use ThingsBoard. However, if another system is used for keeping track of compost caddies, the code for parsing the downloaded data will likely need to be changed to reflect on what that system outputs. If that new system also provides an API, that can also be used for parsing compost caddy loan information.
Hosting
The server application should be installed on a computer that is accessible via the internet, so that the mobile app can communicate with it anywhere. Depending on what is available to you and how much you wish to spend on the project, this can take several forms: it can be installed on a dedicated server computer, on a virtual machine present on a networked computer, or uploaded to a cloud service.
Depending on your organisation, whether or not the cloud server will be accessible inside as well as outside will depend on security policy. For example, schools in Queensland are limited in what is accessible on the school network and so a cloud-based server solution is not possible.