W.A.S.T.E.

The mobile app will be programmed in Swift using Xcode. The app will be made to be compatible with iPhone 6 models and newer.

A. Input
            The app will receive information from the home base about the status of the sensors. The user will be able to choose which sensors to monitor. The status of the sensors will be available at all times (assuming system is functioning correctly) when the app is open. If a sensor status changes, the user will be notified via a notification so the user is notified even when the app isn’t open and in use. See Open Questions for additional information.

B. Output
           The app will output the status of the sensors. See Open Questions for additional information.

And Yet Another Subheading

The mobile application is written in Swift using Xcode and is only compatible with iPhone 6 and newer models. The code for the app can be accessed on GitHub. Simply download the files from the ‘master’ branch and run the ‘3-20-client.xcworkspace’ file from Xcode on a Mac computer.

The main reason the app is only available for the iPhone 6 and newer is because the app is secured using fingerprint login. Older phone models do not have fingerprint login capability. The app will not crash if it is used on an older model. An error will be presented to notify the user that the device does not have fingerprint login functionality.

The app uses a pre-existing MQTT client written in swift called Moscapsule. The framework is implemented as a wrapper of Mosquitto library, an open source message broker that implements MQTT. Moscapsule can be installed as a ‘CocoaPod’, a dependency manager for Swift and Objective-C.

The app utilizes ‘NSUserDefaults’ to save information unique to each user. ‘NSUserDefaults’ is a built in tool provided by Apple. Unless the app is completely deleted from the phone, it will save information even after the app is ‘killed’. The app will save the user’s sensors and MQTT server information. Each time the user edits the list of sensors or the MQTT information, the User Defaults are updated.

Each sensor object has the following properties: name, status, last updated time, and image. The status is displayed as ‘Waiting’ when first created until a message is received. When a user adds a sensor, the sensor object subscribes to the topic matching its name. When the user attempts to save a new sensor, the app checks to make sure the name of the new sensor does not match the name of already existing sensor. If it does, an alert will display to indicate to the user that the name needs to be changed.

Notice in the product setup that the user is told that it is very important that the sensor is named the same thing in the app and the Wi-Fi manager. When a message is successfully received, the app checks which topic the message came from. Once the specific sensor is determined, the app changes the sensor’s status property to the received message and the last updated time property to the time the message was received. This information is updated in User Defaults and then updated in the table on the app. The user can also remove sensors from their list in the app. Once removed, the app unsubscribes from that topic. The user can change the MQTT server information at any time from the settings button in the app. Once updated, the app makes a new connection to that server and saves the information in User Defaults.

For the project demo, an AWS server was used to store MQTT messages. The benefit of using a server is that the app and the sensors don’t have to be on the same Wi-Fi network to receive status updates