We gave both the iOS and Android applications a native design.

The first thing we did when working on Possio was define the wireframes. As Possio’s target audience is primarily businessmen, it was necessary to minimize the time it takes to fully understand all features of the app. Therefore, we designed both the UI and UX according to Google’s Material Design guidelines. As per Material Design standards, the app’s design is clean, minimalist, intuitive, and concise. It helps users get the information they’re looking for quickly and easily.

We established the color scheme based on Possio’s corporate style and colors.

Possio Hardware Device. To use Possio, users must install a Possio tracker directly in each vehicle. These trackers collect various types of data depending on how they’re configured: GPS, GSM, movement, acceleration, and so on. This data is then processed in real time to identify any notable events while the vehicle is moving (e.g. collisions, turnovers, harsh acceleration or braking, entering and leaving set speed ranges or geo-fences, etc.). The collected data is then sent to a single communication server provided by the device manufacturer.

Database. Possio consists of five server instances that run independently from one another. In order to handle these operations, we needed a database that would be accessible from each instance within the product scope. For this reason, we used Amazon Relational Database Service and PostgreSQL for database management.

Server performance and application response latency were our biggest challenges, as devices continuously send large quantities of data (in less than half a year in production, we’ve already collected more than 14 million GPS records). Because of this, we had to denormalize the database structure and add a number of custom indexes and complex SQL queries, which consequently solved our performance and latency issues and made the application run swiftly and smoothly.

Notification Server. We implemented an asynchronous HTTP server to handle message delivery across three different channels: SMS, push notifications, and email.

Once an event has been registered in the database, it’s immediately queued for delivery. The server checks all events individually to determine both the final notification receiver and the channel through which that notification should be sent.

Setting up this process was a bit tricky, since several different users may be tracking the same device though each have different notification preferences. Nonetheless, the server figures all this out, prepares individualized notifications based on templates, and delivers them.

Django Server. The Django server is responsible for several operations: providing a REST API for mobile devices; performing calculations, validations, and aggregations; managing registration, authentication, payments, subscriptions, and the database structure; and a lot more.

The server also manages processes such as device firmware updates, notification configurations, and journey aggregations.

To improve the overall utility of such a complex project, make the service more comfortable for users, and provide administrative features, we integrated a number of third-party services.

System Management. Amazon CloudWatch aggregates logs in one place from all five Possio servers. OkMeter locates and helps fix bugs and unexpected system behaviors. We configured it to track various metrics such as system load, memory usage, system processes, and PostgreSQL stats. This made it possible for us to run custom SQL queries and display them as timeline metrics so that we can check which queries take the most time, which devices are active, which tables are updated more often than others, and know when anything has gone wrong. Sentry is used for error tracking.

Payment Management. Stripe supports all in-app payments. Taxamo does everything tax-related: calculates VAT rates and reports invoices.

Notification Management. The Amazon Simple Email Service sends email notifications to users. We used Firebase for push notifications and Callr to send SMS notifications and perform phone number verification and emergency communication with devices. Tele2 sends SMS messages to trackers. Tele2 is the GSM provider whose sim cards are installed in Possio devices. MailChimp collects emails of registered users so that they can receive newsletters and other important Possio-related information.

Geolocation Management. The Google Maps API gets addresses of points on the map. The Google SnapToRoad API interpolates the list of coordinates received by trackers, which aren’t always defined properly due to some inadequacies in the GPS technology itself, and then snaps them to roads on the map.

The Possio iOS app is written in Swift. For its architecture, we decided to go with Model–View–ViewModel (MVVM) and a Service-Oriented Architecture (SOA), as these were a perfect fit for our client’s needs.

We implemented Alamofire for all RESTful API interactions and used ObjectMapper to work with the API’s model management. For image caching, we chose SDWebImage. API calls are observed by a network activity indicator, whereas custom extensions and structures are responsible for error management.

With native animations, it was possible to improve the overall user experience. By tuning their tension, damping, and velocity carefully and by making all transitions custom, we succeeded in satisfying all of our design requirements.

To retrieve tracker data in real time, we used WebSockets (the StarScream Framework). For Swedish and Norwegian language support, we used a native localization mechanism. To cache user filters, we decided to implement a default file storage.

The Possio tracker application for Android is written in Java and Kotlin. The main architecture patterns are Model-View-Presenter (MVP) and Model-View-ViewModel (MVVM). By combining both patterns, we were able to use their strongest features to produce highly maintainable code and make development very efficient time-wise.

For the REST API interaction, we used the stable and popular RxJava + Retrofit combination, which allows for easy and simple management of requests. Crashlytics by Fabric IO is used to track crashes, swiftly fix them, and keep a detailed log.

To satisfy the UX requirements, we created a number of custom views tailored in accordance with Material Design guidelines.

The tracker integrates an interactive UI and custom views to control user inputs, manage Google Maps, and visualize data.