You need a GPS locator in your app. You might not even know it yet, your app might be at a stage where it’s just an inkling of a future idea. Still, it’s going to need location service. Is it a social app? Obviously, location is crucial. Dating app? Please. Uber, or something similar? Undeniably. 10-15 years ago hardly any apps used location.
In 2019 the prompt “Do you want the app to use this device’s location?” can pop up in a kids’ coloring app. There are two ways of creating mobile and web apps integrated with a geolocation server, like eg. our HomeDoctor app for home visits. We either develop our own solution to receive and send GPS data or use an existing service.
Which one do you choose? We had to ask ourselves this very question when recently we got a project that required receiving information about devices’ location.
Is it better to create your own solution or use an Open Source server?
To answer this we took the project apart for analysis. Functionalities and requirements were put against capabilities each of the solutions had. First, we looked at the option of writing our own solution. The obvious advantage here was full control over the server’s set of functionalities. This would let us avoid the issue, where we wouldn’t be able to implement a functionality due to Open Source server’s deficiencies. The downside of a custom solution was lengthy and resource heavy process of implementation.
Additionally, a custom made server would require thorough preparation, highly optimized source code and continuous support. More work for us, and higher cost to the client.
This led us to turn our focus to finding what’s at our disposal in terms of ready-made servers meeting the requirements. Further research was needed.
How do you find a ready-made solution to meet your needs?
Good old Google yields more than enough in terms of comparisons. Popular servers, opinions, pros and cons, are all available in abundance. In our research, we set the following as priorities:
- Price – free tool being most preferable,
- Open Source code – to enable modifications of certain functionalities as the project develops,
- Functionality range covering our requirements,
- Continuous support and comprehensive documentation.
Our search yielded 3 names that appeared to best fit these prerequisites: OpenGTS, GPSWOX, and Traccar. The latter caught our attention being free, written in Java and continuously supported. It sported a very good rating and its creators’ assurances of the high efficiency of the server. Intrigued, we decided to concentrate on Traccar and dig a little deeper. The next step was to get acquainted with the system and verify its functional coverage of our requirements.
Traccar – what is it and where did it come from?
Traccar is actually a company specializing in GPS device tracking and software development (Traccar Ltd). The Traccar platform is a product developed and implemented by a 50+ strong team of developers, both in-house and external specialists. Clearly, a lot of hard work and expertise went into this development.
Impressive client base
The project’s official website says Traccar is used by thousands of companies from over 140 countries, which is both impressive and convincing when choosing a provider. Finding its use in all kinds of apps for vehicle tracking, locating devices, calculating the distance between users etc.. All the examples and customer base shows that Traccar is a reliable service, created by specialists in GPS location services.
What about the technical details?
Let’s see what this “modern GPS tracking platform” actually offers. Traccar is divided into two main modules – a multi-platform server and a web interface. Example Android and iOS apps at your disposal to show the service at work. The server works with over 170 communication protocols and supports in excess of 1500 types of GPS devices. We can define groups and areas, send/receive notifications and alerts about events. The system stores tracking data and gives access to reports and historical data on tracked devices. The tool works on Apache License 2.0 – a license allowing commercial use and source code modifications. The documentation is solid and comprehensive. So far, so good. What else do we get?
Windows, Linux and iOS installers
The installer is available for download directly from the main website. Windows, Linux and iOS versions available. To adjust the server to our requirements, it has the option to define a wide range of configurable parameters.
REST API and Realtime API
Communication with the server is done mostly via REST API with Realtime API added in recent versions, which now allows receiving of data from the server in real time. As for authentication, we get 2 options: cookies or HTTP header. Management of all the server functionalities is done using the web interface, which is well designed and intuitive.
How is it in practice?
Practical use of Traccar was pretty much the most important issue to verify. How well will the server manage a high volume of queries? The creators claim the system, adequately configured, can manage around 8k queries per second with 100k users. As much as the info seemed reliable, we decided to test it ourselves. The client’s requirements were well below the capabilities of the service – 100 requests per second or thereabouts. Tests showed the server managed the load very well.
What about a custom protocol and notifier?
Moving on with analyzing client’s requirements we faced an apparent obstacle. It turned out we would need to define a custom protocol and a notifier that will inform the app about events where a device exits and enters a certain area on the map. According to Traccar’s official website, the server is designed so as to allow this without significant modifications of the source code. As Java is extremely popular among itCraft developers, we decided to take up the challenge, which turned out to be the right call. We managed to add both the protocol and notifier and to implement our own API method on top of it.
Some improvements could be made
The conclusion of this exercise was that the software is flexible and there shouldn’t be any significant issues working with it. We also noticed that some functions could be improved, if only slightly. Namely, the WebSocket based Realtime API could benefit from further development, as so far it only allows receiving of largely unfiltered data. Another improvement could come from allowing defining of new protocols directly from the interface level to eliminate the need to build a whole project each time just for this instance. These were more improvement ideas than critical issues, so didn’t much mattered in overall adequacy of Traccar as a solution.
If it looks good, why not try it out?
Once the efficiency testing and functional analysis were complete, it was time for conclusions. Summing up our research, Traccar is a well thought through, efficient solution, rich in useful functionalities with easily modifiable source code. A wide variety of protocols and a large number of supported devices ensures seamless communication between the users and the server. The standard REST API is user-friendly and comprehensible. One of the crucial selling points to us was the fact that Traccar is continuously developed and supported so in case of any issues, we would have the official forum and the community to help us out.
We use Traccar!
In the end, we gave up the idea of writing our own server in favor of using Traccar software for our application. So far we had no issues working with it. The solution looks to be one of the most interesting among free, Open Source servers. The functional range makes it a perfect fit for a variety of apps utilizing GPS device location.
Wondering about traccar implementation?
Contact us and let’s talk about working together.