Today’s article is from Delphi developer Alessandro Negri. Alessandro talks us through his company’s development of a potentially life-saving reporting tool which links to a system that helps visualize hazards for motorcyclists. Alessandro describes what made them decide to step away from other programming solutions and choose Delphi for the project. He also explains why the success of this project has convinced him to use Delphi with the Skia4Delphi library for planned future cross platform apps.

What is the Motorcycle Hazard Reporting Monitoring Tool?

Through a DOT government contract, we pitched and successfully developed a motorcycle hazard reporting and alerting SDK for mobile applications called BARRACUDA. The BARRACUDA SDK was integrated into the Beta versions of the REVER Android and iOS mobile applications and launched globally. The BARRACUDA SDK was written as a native service in Kotlin for Android, Swift for iOS, and the backend using Python.

Once we have completed the development of the SDK and deployed the backend to the cloud using Microsoft Azure as a provider, we realized we needed to quickly visualize and gauge how hazards were being reported by users. We did not want to create a web application for it, as we had developed our backend as a secure REST API and did not want to add anything to it at this point.

We needed a tool that would provide geospatial capabilities to visualize the hazards, have the tool work cross-platform between Windows and MacOs, and have the ability to develop and modify it quickly. I thought this would be a great project to level up my Delphi development and so I decided to take a plunge and build the tool using my Delphi Professional license since I knew it would support both platforms and develop the software within a couple of hours designing and implementing the tool.

Where can we read more about the BARRACUDA project?

For reference you can find more about the project under this link: BARRACUDA – Charles River Analytics

What sort of design decisions and process drove your project?

The first steps were to do a quick outline of the features needed, and then do a mockup (on paper) of what the tool should look like for the user, in this case my small team of three. Our user requirements were as follows:

1. Display a map
2. Load hazards from CSV file
3. Load hazards from REST API
4. Mark all hazards, with icons distinctive of type
5. Clear all hazards
6. Print a list of all hazard ids
7. Print all the unique hazard reporting users 
8. Enable centering of map around a specified latitude and longitude
9. Show a hazard and user count

---

What Delphi components did you decide to use and why?

The next actionable step was to figure out how to use a map on a non-mobile application embedded on the application, for that we relied on the TMS Software FNC Maps component. They supported multiple providers and we were not sure on what provider to use yet. After reviewing several, we ended up using Mapbox. REVER uses Mapbox, and we wanted to reduce the differences between our tools and integrators. Our sample SDK applications were also using Mapbox.

More on the design process

Finally, I chicken scratched in a notebook what the tool should look like. This is a step I always do since it helps me free-hand and visualize what I want to do. It isn’t a requirement to be the most artistic, but it is also a very satisfying and personal step (I do also do it when creating data models, relational databases, any type of UI, and games).

How did you go about implementing your design?

Having a mapping component selected, a requirements list, and a chicken scratch UI design I could focus on making the tool work and make a shareable build. During the two hours I focused on the following:

1. Create the UI, shown below in the editor.
2. Map the UI components to the events, in this case it was mostly event clicks for the following:
   1. Load hazards from a CSV file
   2. Query REST API and display latest live hazards
   3. Clear hazards
   4. Center map view in a specified location (the eye icon next to the specified lat/lon edit fields).
3. Code the basic functionality, every step is tested
   1. Display a browse file dialog
   2. Load and parse a CSV file
   3. Leverage the REST component to access the backend
   4. Parse the JSON data
   5. Overall test application
   6. Count the total hazards during data parsing
   7. Count the unique users using a dictionary to track how many hazards each user had reported while data parsing
   8. Extra time was taken to make sure the TMS FNC Map functionality to render the markers was correct
4. Enhance the basic functionality and test
   1. Obtain a lat, lon center average of all hazards during parsing
   2. Add constraints to the lat and long edit fields
   3. Center the location on the map
   4. Test the overall application in Windows
   5. Compile to MacOS and test.

What other components did you use?

I leveraged the REST components provided by Embarcadero. Then I used the JSON libraries to parse the data from the REST API and create/add markers to the map.

The TMS FNC Maps had a few gotchas, such as batching the update of the markers, if this was not done it would take a long time to load and render the map markers. There was also a bug that was quickly fixed specific to the Mapbox version of the component. The TMS devs were very good at helping on their forum and updating their components to address the bug I had encountered. This was my first real project using Delphi and the TMS components, and it proved to be a solid choice for me.

What does your project look like in action?

The final build of the tool can be seen in the image below, where the user has queried the backend to download hazards and display them on the map.

Do you have any final words on your Delphi project?

With Delphi and FMX I was able to quickly develop an internal standalone tool to support our internal needs without adding a web dashboard to our existing REST API, without the bloat from an electron application, embedded maps, and cross-platform support for both Windows and MacOS. This simple tool not only did it fit our current needs, but also gave me a chance to increase my knowledge and development skills with Delphi. The best places to test and skill up are usually with internal tools for your company/project as it will force you to make something that others will need to use (usually it is a small user base) and failing is easier to take and recover. I am a big proponent of small internal tools to automate, validate, and monitor bigger projects.

Delphi has come in very handy and paves a road to larger and more complicated projects. Currently I am using Delphi to create a mobile application for both Android and iOS, using the Skia engine, to monitor the progress of oncology patients through their 12-week recovery.

---

This article was submitted as part of our Enterprise Article Showcase. If you have a success story to tell about a project which makes use of RAD Studio with Delphi or C++ Builder, or any of our other great enterprise products please get in touch, you could be featured too and win a prize! Read all about it here: Enterprise Article Showcase