User avatar
AndrewC
GpsGate
Posts: 316
Joined: Tue Apr 01, 2014 12:30 pm
Location: Sweden
Contact: Website

Dispatch 5 developer blog

Mon Oct 30, 2017 6:48 pm

Dispatch 5.1 architecture

As a developer myself, whenever I read a set of patch notes or a feature blog post, I'm always interested in the details behind the note. We try to make our notes a little more specific than the infamous "Various bug fixes and improvements" when we can, but there's always a deeper story behind that one line of text. For this Dispatch beta period, we're going to release a series of developer-centric blog posts to provide some more context to those who are interested in the direction of Dispatch.


If you are light on time, our recently released patch notes will tell you about the new features we've made and the old ones we've retired. Our GpsGate blog posts will explain how our new features can help your business and fulfill your customers' needs.

These developer blog posts are designed to provide some extra insight on the creation of the plugin for those looking for more technical details or the intent behind the various features and are purely optional reading material.

In the coming weeks we will have some deep dives on the design and the implementation of our various key features touching on topics like our new native apps, our route management and optimisation, the analysis panel and our developer APIs.

This week we'll be looking at our motivations for redesigning both the server and the user interface of Dispatch.

Let's start at the very beginning.

Why?

The main motivation for this redesign of the Dispatch plugin was to address 3 key issues that we were having with Dispatch 4.

  • Performance
  • The resistance involved in creating new features
  • Usability of the UI at scale


Performance

Performance is one of the simplest concepts to understand in software for both users and developers. While using the features of the program, everything should work responsively and not stutter and stop when it's stressed. To get to this level of usability in modern software with its terabytes of data flying around between thousands of interlinked features, performance, for developers becomes a never-ending quest and a state of mind.

In a piece of software, the very slowest component immediately becomes your performance bottleneck. It's obvious when you think about it. Who cares if the server is flying at 88 miles per hour if your user interface is immediately choked by the data it's getting. If your data storage takes a long time to load your data, every subsequent component is waiting around idle.

To achieve good performance, every aspect of the system between the user's screen and the store with your data needs to be designed in a way that does not block anything else. Every time you implement a fix or feature, you need to consider how it will work when there is a lot of data and a lot of users. If you do this in every aspect of your system, then you can have good performance.

Updates

GpsGate Server is used by many different types of partner and solves so many business cases that we won't ever be able to add every feature that everyone would like. Despite this, we have a strong commitment to working with our partners and turning their feedback into features whenever we can. We typically have a much faster turnaround time on features and fixes than most software developers and we look for opportunities to design our systems in a way that can help us with this goal. It's important to us that Dispatch provides a platform that aids our ability to be responsive with updates and we saw an opportunity to make it better at this with Dispatch 5.

Usability

When a large system is working smoothly and there are no performance issues, the next thing to address is whether the data that you can serve to the user is useful. If your system can display 1 million items to the user, can they use that information in a meaningful way? There's a chance that you're just making a lot of noise that is hard to interpret. For the performance to be meaningful the system needs a way of displaying all the information that will help the user the most, while ideally having the rest of the data close at hand.

How?

The concept of usability is a very complex one and is best addressed in discussions about specific features. We will leave this topic for the posts about our features in the coming week and instead concentrate on performance and adaptability.

These two concepts are unrelated at first glance but it turns out that a shift in design can help you in solving both at once.

Traditionally the best way of gaining performance has been by optimising code to do as little work as it can to achieve the goal that you want. The fewer operations that the processor must perform, the faster it will go. If your processor is faster, it can do more operations in a certain time and the faster your software will go. Both principles still hold true and are still valuable tools to improve performance but in a modern system there are a massive amount of operations taking place at once. Very quickly you will hit a point of optimisation and server capacity that can't really be tweaked all that much better.

With the increase in complexity of systems come more moving parts in the system. This is a blessing as well as a curse. A lot of the functionality of these smaller parts don't need to be very connected to each other aside from when they start and when they finish. With this in mind, it's almost always possible to break each small part of the system down into a self-contained little black box that only needs two things outside of their own world. When they start an operation, they will need to be given instructions and data to process, and when they finish they'll need to tell some other part what they managed to produce.

The Server

In Dispatch 5 we have rewritten the server back end to use a message-driven architecture. All the system has been split into smaller parts that do their own work and spring to life when they are sent a message telling them to do something. When they are finished, they send a message to the other parts that will want to know about the result, who in turn can act on this message.

Breaking the system down into very self-contained parts like this creates a small amount of extra work compared to extremely optimised code that directly links into parts of other systems to bypass a few redundant operations. In exchange for losing a few extreme optimisations you get many benefits:

  • The code to deal with each part of the system is completely separated from other aspects of the system. This instantly solves a lot of our concerns about making sure that the system can be updated and fixed easily. You can change inside one feature without causing a lot of side effects.
  • The code to run an operation of a certain type has nothing to do with other parts of the system. They communicate only by sending a message to each other when a message is ready. This means that we get access to “asynchrony” when it makes sense; the ability to run the code at the same time as another operation without waiting for the other operation to finish. Asynchronous programming is not a new concept and GpsGate Server has taken advantage for it for years, but a message-driven architecture allows asynchrony without adding a lot of the complexity that comes with traditional asynchronous programming.
  • As we just created some asynchrony we now also have scalability. Instead of trying to supercharge our processor even more, we can just throw more processor cores at the workload and benefit from them. An operation can run on any free resource and fall asleep when it's either waiting for a message that it needs, or has no work to do, freeing up the resources for another operation.
  • As all our processes communicate with passing messages we don't need to stop at multiple cores. We can have the different parts, usually called micro-services, live on different servers that are tailored to what they're trying to achieve. A server with a lot of disk storage for the database and a lot of processor power for the route optimisation, for example. GpsGate 5 now has support for the track store running on a cluster of these servers and in the future Dispatch will also be able to be scaled to a cluster that you can tailor for your business case.
This architecture isn't a magic solution and even when you separate code into self-contained parts you will need to occasionally wait for other operations to finish so that you can use their data. You can't work on rendering a report before you have the data finished, for example, but the benefits to a server workload are clear and substantial.

The Interface

Things have subtly changed on the server now. In a message-driven architecture you should no longer start an operation and wait for a response. Waiting is a waste of time as the part of the system you are communicating with will send you a message when it's finished. If you would like, you can even ask it to stream messages to you as it finishes each part of an operation.

This concept is something that we want to exploit on the interface side. Using HTML5 server sent events we can split up our server communication logic to be two different systems. One system sends requests to the server when the user wants to do something or wants more data. One system processes any incoming data that is received from the server. This means that operations in the interface finish immediately and release control back to the user. It also means that the instant the server is finished processing some data, it can inform all the connected clients - web or app - that the new information is available. This messaging happens without leaving any processes sitting waiting for responses on the client side. As there are no processes waiting, it also means that on the server side you don't need to have an operation that is sitting and waiting for the response data for each request that is sent in. Now you don't have a server that is being choked by lots of longer running requests.

As well as the communication with the server being rewritten, our web interface refresh and new apps are designed to work with large amounts of data. A lot of effort has been put into making sure that with this increase in server responsiveness, the user interface can keep up.

We will share more details about the interface in the upcoming blogs.



What is next?

Throughout the beta period for our live Dispatch 5 release we will be concentrating on fixing bugs and tuning the performance even more based on our own testing and feedback from all our beta testers. We are proud of our new system but we're not ready to call it finished. There will be glitches and bugs and we'll be working to get them smoothed out.

Alongside bug fixing, the development team will be making sure that all the features listed in our Known Issues patch notes section are included in the plugin and working before we go live.

Our design team is working on constant improvements to both the user interface and the wider user experience for GpsGate Server and their efforts will be debuted in Dispatch 5 as soon as they are ready. Other plugins might take some time to be updated but Dispatch 5 will be at the front of the line.

While the beta period is ongoing we have some of the team working on our first major feature release. Our current plan is to have a beta build ready very soon after Dispatch 5 is released to the update channel. We will share more about our first feature patch nearer to the end of our beta, but it will introduce some very requested features such as the ability to add media to Dispatch custom fields and a more powerful search functionality in the Dispatch panel.

Feedback group

We will be releasing blog posts during the beta phase highlighting new and upcoming features for Dispatch 5, but we are also running a Dispatch 5 beta feedback group. Members of our beta feedback group will get emails with the developer deep dive posts, be assigned specific feature feedback assignments to communicate with the developers and be a part of shaping the development of Dispatch 5 for our first feature patch and beyond!

Our first round of specific feedback gathering will be targeted at our Mobile apps so sign up now if you haven't already!

Sign up to our beta feedback group here.


Andrew is a developer at GpsGate in Stockholm. He works mostly on designing systems for GpsGate 5 and in his spare time enjoys trail hiking to the fridge.
Last edited by AndrewC on Tue Oct 31, 2017 12:27 pm, edited 1 time in total.
Reason: Sticky during Dispatch 5 beta period only.
Regards,
Andrew
GpsGate Support

slester
Posts: 10
Joined: Thu Nov 16, 2017 4:32 pm

Dispatch 5 developer blog 2

Mon Nov 20, 2017 5:40 pm

Dispatch Mobile Apps: designing mobile apps for end users

This time we are going to talk a bit about which technologies we have used in our mobile app for the Dispatch feature of GpsGate Server.
If you are light on time, our recently released patch notes will tell you about the new features we've made and the old ones we've retired. Our GpsGate blog posts will explain how our new features can help your business and fulfill your customers' needs.
These developer blog posts are designed to provide some extra insight on the creation of the plugin for those looking for more technical details or the intent behind the various features and are purely optional reading material.

Goals
For Dispatch 5’s worker UI, our goal was to have a smoother, higher performing, native mobile-feeling experience for users. We now have a native mobile app for Android and iOS that offers many advantages over our previous solution. The previous worker UI was in the GpsGate Fleet app, a hybrid web/mobile app.
In order to reach our goal, we figured we needed a true native mobile app, which does all of the above better than a web solution. We needed both Android and iOS compatibility, with the platforms having the same features and functions. However, we did not want to maintain two different apps (one for Android and one for iOS). Instead, we looked at solutions that let you write code once and reuse it on both platforms.

After doing some research, we decided on React Native, which is a JavaScript framework for building native mobile apps made by Facebook. We use a lot of JavaScript in our VehicleTracker web app, so our developers already know it well.

Development
Now you might be thinking that JavaScript and native mobile apps don't sound right together. Let me quote Facebook: "With React Native, you don't build a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that's indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React."
So React Native lets us write code in JavaScript. We can also write and use true native Android/iOS components, so we are in no way restricted to JavaScript. For example, we use the phone's camera to scan QR codes for fast connection to your server (see more below).
While developing with React Native, you don't have to recompile the app every time you make a change. Instead, the app reloads automatically on your phone (or simulator) whenever you make a change. Less time waiting on compilers is always welcome. This makes development much faster.
We liked React so much that after doing the Dispatch mobile app, we have also started using React in our VehicleTracker web app. We will talk more about that in a future blog post.
Read more about React and React Native here: https://facebook.github.io/react-native/

Architecture
Server connection
We have integrated our new GpsGate Server registration system (pairing service) which makes it easier to connect the app to your GpsGate Server instance.
Operators can generate a QR code for the server in the Dispatch for VehicleTracker plugin. When a worker opens the mobile app, they can scan the QR code using the phone’s camera. The server address is entered automatically, so the workers are connected in seconds.
Once logged in, the app is connected real-time to the server using server-sent events (see https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events). Traditionally, you need to send a request to the server to receive new data (polling). Using server-sent events means that whenever an operator updates a job, that change is immediately received in the app.
We use the same technique in the VehicleTracker web app. For example, vehicle position data and in the new Dispatch for VehicleTracker plugin (but once again, we will talk more about this in a future blog post).

Client state
All the data received from the server must be stored in some way. Most React and React Native projects use the Flux architecture/pattern for that. Flux utilizes a unidirectional data flow (data only flows one way). The other option is two-way data binding that is also popular. See below for a comparison.
twoway.png
twoway.png (23.16 KiB) Viewed 1313 times
Image 1. Two-way data binding.
flux.png
flux.png (25.52 KiB) Viewed 1313 times
Image 2. Flux architecture. Notice the added Action and Dispatcher steps.

In Flux, the code is much more explicit with less "magic" involved. This should reduce the number of bugs, and allow easier debugging when we actually find bugs. However, it does require a bit more boilerplate code.
In our app, we use an implementation of the Flux ideas called Redux (see https://redux.js.org/). The data flow is similar to the second image above.
1) When you click a button OR receive data from the server, you dispatch an action
2) The client state store is updated according to the action you dispatched
3) Views are re-rendered IF the client state changed

Work offline
A major new feature in the app is the ability to work offline. To solve this, we save worker action history on the phone's storage, if a worker is offline. Once back online, all actions will run again to synchronize with the server.

This was quite simple to implement using Redux actions (see above) and optimistic updates. ‘Optimistic updates’ means that the UI is updated even if the server did not confirm the change.
An example:
1) Login
2) Wait for all the jobs to download
3) Go offline
4) Start a job (a Redux action is sent)
5) Cannot send to server. Store the Redux action in queue and optimistically update the UI
6) Go online
7) Send all Redux actions in the offline queue to the server
8) The UI is reverted in case of failure, otherwise nothing happens since the UI was already optimistically updated

Push notifications
With push notifications, workers will never miss new jobs, even when their phone is locked or the app is closed. Whenever an operator assigns a job to a worker, a notification is sent to the worker's phone, as long as he/she is logged in.
For sending push notifications, we use Google Firebase Cloud Messaging (see https://firebase.google.com/docs/cloud-messaging/), which is a cross-platform messaging solution. We just need to implement it once on the server, and once in the app, and it does not matter what type of phone we are sending to.

What's next?
Right now, everything is in place to make a great Dispatch app, but we need your help!
How can we improve the workflows within the app to better suit your business?
What features are you missing?
Join our beta feedback group to tell us! here

Mattias is a developer at GpsGate in Gothenburg, Sweden.

slester
Posts: 10
Joined: Thu Nov 16, 2017 4:32 pm

Re: Dispatch 5 developer blog 3

Mon Nov 27, 2017 4:16 pm

The persistence layer of Dispatch 5

Introduction
In this week's developer blog post, we are going to talk about the "Persistence Layer", the bottom part of our server back-end. It is a critical part to improving system performance. In layered system architecture, there are several layers, and each is dedicated to certain functions. These layers communicate with each other, beginning with receiving a request from the client, shaping/validating it, and finally porting it to the database. The Persistence Layer's job is to interact with the database. In most cases, this part is the slowest if we have mass amount of data to deal with, so it can easily become a bottleneck in a system's performance. One of our major tasks was to speed up the communication with the database as much as possible. But where did we start and how far did we get ?


Legacy Dispatch Persistence


In the old system we had a main database table for Jobs, and many other tables were joined to it to keep our database normalized. This turned out to be a downside when we try to read thousands of Jobs, because table joins are quite ‘expensive’ operations. Reading thousands of Jobs can take a long time and make all other operations halt. The user will experience very long waiting times and poor responsiveness.

To write Jobs in the old Dispatch, we used database generated IDs for the table rows. We had to insert our Job first to have its ID generated before we could write to the other connected tables. That meant several update calls to the database to write only one Job. You can imagine what happened when a large amount of Jobs were about to be saved.

The old system was working perfectly fine with smaller customers, but we had to think big as we started to handle hundreds of thousands of Jobs each day. Since every layer above lies on the Persistence Layer, we had to speed up the database I/O operations and after that, we could improve the performance of the upper parts as well.


Dispatch 5 Persistence

We needed to rethink the database structure of our Dispatch system. The old relational normalized way seemed outdated in bigger scale. First, we wanted to get rid of the table joins, so we denormalized the Job table and tried to store as much information about a Job in it as possible. This may cause redundant data storage, but also means that we have only one table to deal with to read or write a Job. Read queries do not link other tables to the main one anymore, which means better performance for massive data loads.

Removing the joins also positively affected the database writes. Now we can save a Job with only one update call instead of several. We’ve also changed the old strategy of dealing with Jobs one by one. We now batch them, and with one update call hundreds can be inserted or updated in the database at one time. Reaching for the database is always an expensive operation, so reducing the frequency of database calls was a big win. Basically, instead of hundreds of update calls, we only make one. That's a massive improvement in the performance.

Finally we have also changed the ID generation process. We don't rely on the database incremental unique generator which was too slow. We instead use a technology called snowflake id. This technology created by twitter allows you to generate in memory ID in a fast, unique and scalable/shardable way. Thanks to that the create operations on the database are much faster.


The Future

This database structure means that we are slowly moving away from relational databases. In the new Dispatch 5 system we don’t link tables at all. Since we no longer use the relational model, we don’t need to. Entire rows are updated now instead of detecting changes and updating columns. In the future, we would like to move on to a non-relational database structure, where there's only an ID and a data column. Data is stored in a JSON format, so for updates we update the whole row, but hey, that's what we're doing now!

That's one of our main plans to improve Dispatch's performance even more.


Right now, everything is in place to make a great Dispatch app, but we need your help!
How can we improve the workflows within the app to better suit your business?
What features are you missing?

Join our beta feedback group to tell us here!


Denes is a developer at GpsGate Budapest in Hungary.

slester
Posts: 10
Joined: Thu Nov 16, 2017 4:32 pm

Re: Dispatch 5 developer blog

Mon Dec 04, 2017 4:20 pm

Dispatch 5 in Vehicle Tracker: Designing UI to make sense of huge quantities of data

When we designed the new Dispatch 5 UI, knowing that it should be able to handle hundreds of thousands of jobs, we had two big challenges:

  • What data do we show and where?
  • How can we achieve great performance?

Carousels and Cards

When you have a lot of items to show, but limited space, you need a smart way to present the data. In our case we had workers, routes and jobs to present, all of which relate to each other in different ways.

Displaying all jobs in a table would not make sense since we have multiple levels in the data structure (workers have jobs/routes and routes have jobs). Displaying all jobs with the assigned workers and related routes (if any) as column data would make it difficult to get an overview (e.g. how many jobs a certain worker has, or which jobs belong to a certain route). Grouping jobs based on the assigned workers and routes would make the table too complex with multi-level headers.

In the previous Dispatch plugin, we presented the jobs using cards instead of a table. Cards allowed us to display several jobs on the same row, while with a table you can only have one job per row. However, there were two issues: first we didn't have a good way of presenting routes and second we didn't have a way of limit the number of jobs for each worker. The latter issue could result in the whole panel being filled with jobs from the first worker, so you would need to scroll down to find the jobs for other workers.

The solution: we introduced the carousel concept as shown in the picture below. That helped us limit the number of jobs shown per worker, which in turn made more workers visible at first sight. The user can limit the number of workers shown by changing the height of the panel, and limit the number of jobs shown by changing the width. Hopefully this will provide a flexible way of working with the Dispatch plugin.
newCarousel.png
newCarousel.png (25.77 KiB) Viewed 1040 times


Another thing we also improved was the colored labels for each worker representing how many jobs in each state a worker has (finished, late, ongoing, etc.). Looking at those labels you can easily get a good overview of the worker's current "state".


Only show relevant information

When you cope with large amounts of information, it is very important to see the most relevant part of the information. An issue with the previous Dispatch plugin was the job custom fields display in the route form window. Having many custom fields would result in a large horizontal scroll, making it difficult to find the relevant custom field.

The solution: Instead of displaying all job information on each row in the table, we only display the most relevant information such as location, date etc. We also made the table read only and added a “edit” button to each job. If the user wants to edit any job information or view the custom fields, he needs to click on the “edit” button to get an "edit job" window. This is the same window opened when creating a single job (i.e. job that does not have any route).
form window.png
form window.png (58.83 KiB) Viewed 1075 times

Summary of all data

Dealing with hundreds of thousands of jobs, we thought it would make sense to have a separate panel for showing charts that would help the user to get a good overview. In this first version of the analyze panel, we have charts for each of the different job states. For example, the user can see how many jobs have been assigned to a worker, how many of those assigned jobs have been dispatched, how many dispatched jobs have been finished, etc.

Having the Dispatch plugin split into two different panels also makes it possible for the user to view the charts and keep a good overview while working with organizing the jobs. The charts are updated in real time for all changes the user himself or any other user makes. This is due to the amazing server-sent events discussed in previous blog articles.


Performance

A very important aspect when handling huge amounts of data is the performance. If you have bad performance, the tool is not useful. So one of the requirements with Dispatch 5 was to achieve great performance no matter if it was just a few hundred jobs or hundreds of thousands of jobs.

In this case, React was the perfect library to use. First, the Dispatch 5 mobile apps were written in React Native, so it made sense to keep using the same library. Second, React has proven to have good performance. It uses the principle "single source of truth" which basically means there is one source that holds all data (all workers, name of the workers, all jobs, the states of the jobs, etc.). It is this source that is used to decide what is rendered in the UI.

For example, if one wants to change the color of a job you do that in the source resulting in the DOM being re-rendered. React uses a virtual DOM to keep track of all the elements and only updates the "real" DOM if it is necessary. This results in better performance than e.g. jQuery that manipulates the DOM directly which can be expensive when dealing with huge amounts of data.


What's next ?

We want to improve the search functionality, as we think that will be a key feature. It is a big challenge to achieve fast search when having hundreds of thousands of jobs to consider. Currently we are working on it and hope to release a first version of the search functionality for you to try soon.

We also want to improve the Analyze panel to make it possible to dig further into the data. Please let us know what kind of data you would be interested in.


Join our beta feedback group to tell us here!


Marcus is a developer at GpsGate Gothenburg in Sweden.

slester
Posts: 10
Joined: Thu Nov 16, 2017 4:32 pm

Re: Dispatch 5 developer blog

Mon Dec 18, 2017 3:28 pm

Why SOAP style APIs are legacy and what comes next

In this new article, we are going to talk about the Json web service that can be used to communicate with the Dispatch plugin.

What is the API ?

API for Application Programming Interface is a way to give access to some server resources on a (eventually) public endpoint so developer can use it to consume the services provided.

In GpsGate use case, the dispatch API is used to give an access to the dispatch powerful features but without using the the VehicleTracker interface. This means that thanks to the API,

you can create your own custom front end to fit your needs even better.

The use of such an API requires some programming knowledge and you need to understand the workflow of the Dispatch plug in to use it well.


What was in the previous version ?

The former version of the API was based on the SOAP ( Simple Object Access Protocol) technology. But today this technology is a bit outdated. It relies a lot on a WSDL contract. It can be handy,

because it gives a full view of what is doable with the API, but it also can be troublesome for the third party using the API because it makes it hard to update API version in a client.

It also sends the data in the XML format which is very verbose. XML is not easy to write and read for human. The fact that it can be used over different

transport protocol is nice but as most of the internet runs on HTTP, this is not very useful anymore.


What do we use for Dispatch 5 ?

For this new version of the plugin, we've changed the technologies used for the API. We now rely on REST protocol and Json RPC.

REST (REpresentational State Transfer) Is a technology working over HTTP. It has become one of the most used technology for web API. It is able to handle multiple kind request format (XML, Json etc...)

But we chose Json because this format makes the data lighter and more readable/writable for a human being. It also makes it easier to version and add new stuff in the API. It's very easy for the end user to update.

The REST protocol usually relies on HTTP verbs (GET, POST, UPDATE, DELETE) to process operation. On our API we've choose to go only with GET and POST with meaningful names for the endpoints.

We think it makes it easier for a public API to be used and understood by external persons.


What for the future?

For the next step of the external API, we are thinking of 2 different things. On the short term, make the REST API more standard by using a technology like swagger, because it's one of the most popular REST framework

On the long term we would like the API to be able to use the full power of the new DIspatch plugin. Because of the synchronicity of Request/Response pattern of REST, we cannot use the Push technology we implemented for the

web version of the platform. We would like to find a way to do it. Then the API would be even faster


Join our beta feedback group to tell us here!


Simon is a developer at GpsGate Budapest in Hungary.

slester
Posts: 10
Joined: Thu Nov 16, 2017 4:32 pm

Re: Dispatch 5 developer blog

Tue Jan 16, 2018 10:43 am

The beta of Dispatch is moving forward and the plugin is approaching an official release state. Currently, Dispatch is in its 5.0 version.

Today, we are giving you a preview of what is coming in the 5.1 version of Dispatch. Read on to learn more!


Why we rebuilt Dispatch.

To understand where we are going, we need to understand were we come from. In its former state, Dispatch was a very useful plugin, but it was built as a tool for small companies with a small amount of vehicles and jobs. With time, the plugin became more and more used. Eventually, there was more data than it was able to handle. In order to make Dispatch work for YOU, our customers, we decided to rewrite it.


The philosophy.

With the new Dispatch, we had one major goal: build something fast, reliable, and able to handle a huge load of data. And we did it. This new version of Dispatch is able to handle up to 250K jobs while maintaining performance levels. And that will keep improving in the future releases of the plugin.


Features to come.

For the future releases of the plugin, we want to keep in mind this philosophy. Here are some features we will implement in the 5.1 version (maybe some of them in the 5.0):


Batch operations: Give the admin the possibility to execute an operation on a group of jobs (dispatch, delete, etc...).

Filter: Implement a powerful filter in the vehicle tracker UI to make it easy to find a job among 250k of them.

Job history: Maintaining a trail of the events for a job to make it easy to remember all of the actions taken.

UI tweaking: Keep improving the UI based on your feedback to make it fast and easy to understand.

Performance: Continue to remove bottlenecks to improve the overall performance of the plugin.


And some other features not performance related:

Media custom field: a more powerful custom field able to handle picture/videos to improve communication between workers and admins.

Sign on glass: Allowing signature on the mobile app to confirm a delivery.


Thank you for your testing and feedback thus far. We're excited for you to use the new features.

Join our beta feedback group here to tell us what you think.

Return to “GpsGate Server - How to setup and use”