IoT Application

The application allows you to track the positions of technicians who are supposed to visit a list of points designated by managers at a given time. The application also allows you to view the positions of IoT devices that are on pallets or in containers along with the customer's goods.

There are two types of users in the application - manager and technician. Each of them has separate tasks and separate functionalities in the application.

The most important for the client was to monitor the position of the technician. The customer also used IoT devices to monitor the long international journeys of their goods. In this case, the IoT device was placed on a pallet or container and assigned to a specific order. With low battery consumption, IoT devices can report data for months (with the right settings). Appropriate versions of IoT devices allow monitoring of, for example, humidity levels, acceleration, horizontal or vertical position, temperature or pressure. The technician's application mimics the IoT devices.

The technician logs into the application using a QR code that is generated from the client's system for managing IoT devices. The technician is assigned to a specific device. After logging into the application, the technician sees the points assigned to him to visit that day. The points are also accompanied by an expected time limit for reaching them. The technician's task is to reach the designated place at a given time, perform the service and then move on to the next point. The application, by reading the location, informs the system that the technician has arrived at the place. The system "marks" the point as visited and records the time of arrival.

The manager in the management system can see their position and the designated points to visit for the day. The IoT device continuously transmits the location of the technicians and the manager can see it on a map. The manager has access to statistics, such as how many points were visited according to the set time. The manager's panel also shows the status of the visited points: visited, not visited, late.

The client started cooperation with us with a problem, one sample screen with expectations and very little time for implementation, only 6 weeks. The client also expected us to integrate the application with an existing IoT system for asset tracking, which led to unusual requirements:

• The need to use the MQTT protocol, which was expected to provide seamless integration with the client's existing internal systems
• Continuous location collection and uploading to the server at 6-7 minute intervals (similar to IoT devices), which is not supported by power saving and privacy trends and solutions in the latest versions of phone operating systems
• Using GraphQL and REST API in parallel to handle all communication with client systems.

During the implementation of the work we encountered a number of challenges that are inevitable at such a scale of the project. In the initial phase of discovery it was particularly important to organize the vision of the application presented to us. Our experience shows that this is the most important phase in the project, which has a decisive impact on its proper execution. During a series of workshops we defined the final shape of functionality in response to the previously defined business needs of the client. First of all, we made sure that they were understandable for all project stakeholders, so that both we and the client knew what we would get at the end.

Another particularly important element was the look of the application. The client wanted the look of the application to reflect the unique character of Radio 357, without losing functionality. Taking this assumption into account, we made sure that the design of the application was equally important as its functionality. We also made sure that the application is easy to use in different conditions, and the buttons are easy to find and click from different angles. We wanted the listener to come back to the application as often as possible, therefore we placed great emphasis on the comfort of use, both for the web and mobile versions. It was equally important to properly present each programme and content in such a form so as to evoke and maintain the listener's interest. We also focused on the commonality of views for the mobile and web applications, so that the listener had the lowest pain threshold when switching between the versions of Radio 357. During the workshops we managed to create a design of a mobile and web application that met all these assumptions and at the same time perfectly fit into the visual identity of our client.

Another key element was the environment of the project. The owners of Radio 357 gave us a relatively short deadline for the project. They planned to release the app in early January 2021. This release date could not be moved. Given the need to analyze, discuss, design, program and implement, it was up to our team to work under strict deadlines, so efficiency and full commitment were key for us. Additionally, we had to take into account the requirements of integrating the app with external systems such as Spotify and solutions: Chromecast and AirPlay.

After the implementation, we expected a large number of users due to both the planned marketing campaign, famous radio artists creating the radio and the interest of journalists. From the very beginning, we knew that thousands of people in Poland and abroad would download the application and listen to their favourite radio at one time, often listening to live broadcasts. Therefore, the stability of the system, its reliability and a stable, scalable server infrastructure were of paramount importance to deliver the product in the intended manner. The infrastructure we created protected both applications against peaks in listener traffic, which appeared both at the very beginning right after the implementation and later on.

We can divide the whole work carried out into three stages:

• Workshops: Before starting the project, we conducted a workshop in which we created a list of functional requirements (FRD), in response to business requirements (BRD). At this stage, we also defined the scope of the system architecture (TRD). In this way, we aligned the scope of requirements with the client's needs. We better understood the objectives and found a way to achieve them.
• Development Phase: The UX design and the underlying graphic design of the application correspond to the client's visual identity. We took care of the legibility of the content in the application.
• Implementation and integration with the client's systems: Thanks to the analysis during the workshop, we got to know the details of the systems used by the client. A detailed description of the application architecture helped us to efficiently implement and integrate it with systems outside the product.

We created the project using the following technologies:

• Communication with the server is done using AWS IoT Core via MQTT protocol.
• The API consists of: GraphQL (reading data from the system), REST API (writing data to the system)
• Supported operating system: Android 8.1 and higher