MGMLaboratory
Back

Menu

01Home
02About Us
03Projects
04Publications
05Member
06Articles
07Contact

Let's Talk

Open in Mail app

Socials

Malang (ID) --:--Privacy PolicyTerms of Service

April 5, 20182 min read

Swapping pathfinding algorithms without rewriting the appSwapping pathfinding algorithms without rewriting the app

An Android navigation framework treats the shortest path method as a plug in, so the rest of the app never has to care which one runs.

  • Journal
  • Publications

Written by

  • SRShirasaka RenIT & Infrastructure · Student Member

In this article

  1. 01What sits inside the framework
  2. 02What the prototype measured

In most navigation apps, the route calculation is welded into everything else. The map screen calls it, the data layer feeds it, and the drawing code reads its output directly. Trying a different algorithm then means touching half the project.

A framework designed for the Google Android platform takes the opposite approach. It treats the pathfinder as one replaceable piece behind a common interface, and uses the Abstract Factory pattern so the application can choose an implementation at runtime instead of at compile time.

A phone running a map app. The framework targets outdoor navigation on Android. Photo: Santeri Viinamaki, CC BY-SA 4.0.
Fig. 01A phone running a map app. The framework targets outdoor navigation on Android. Photo: Santeri Viinamaki, CC BY-SA 4.0.

01/02

What sits inside the framework

  • A graph model built from Node and Edge objects, so the road network is an explicit data structure.
  • A pathfinder interface with Dijkstra and A star implementations, both selected through the same factory.
  • A data layer that pulls road geolocation over HTTP as JSON from a web service and caches it on the device.
  • A map layer built on the Mapbox Mobile SDK, chosen over the Google Maps API for its offline caching support.

02/02

What the prototype measured

The team built a working prototype in Java and ran it on a Google Nexus 6 with Android 7.0, using a campus road network of 134 nodes and 154 edges. Both algorithms returned the same routes, as expected. The interesting difference was in time.

  • Dijkstra averaged 1.22 ms per query across the test cases.
  • A star averaged 0.49 ms, ranging from 0.10 ms for nearby nodes to 1.16 ms for nodes on opposite sides of the network.

That works out to more than 60 percent faster on average for a single route, with the largest gains in the 71 percent range. The heuristic is not free though. Estimating distances with the Euclidean formula added about 0.26 ms of overhead per query, and the authors note that Haversine would give a more accurate estimate over longer distances.

A row of Android and other smartphones. The prototype targets Android devices. Photo: Carlos Varela, CC BY 2.0.
Fig. 02A row of Android and other smartphones. The prototype targets Android devices. Photo: Carlos Varela, CC BY 2.0.

Source

  1. Pinandito, A., Kharisma, A.P., Perdana, R.S. (2018). Framework Design for Map-Based Navigation in Google Android Platform. Journal of Telecommunication, Electronic and Computer Engineering (JTEC), 10(1-8).

Next articleLikes and Retweets as Extra Signal for Sentiment Analysis(Keep scrolling)(Read it next)(Loading)