Mock and websocket - go to homepage
Mock and websocket logo

Mock and websocket

Consuming websocket data

The data provided by TMMs websocket server is identical to the mock location data - except its a flat object.

 

In contrast to mock locations the websocket server works on all platforms - so iOS and Android. Hence its an easy and fast way to integrate highly accurate receiver positions with rich meta data information into applications.

 

For details take a look at the documentation here. Android mock locations have two parts: the location object next to location.extras. In contrast the websocket server has a single flat json object which is a combination of the two above.

To ensure that the socket server in TMM does not get stopped by the operating system the state of the server is tightly coupled to the active connection to a receiver.

The operating system does not kill applications if a connection to an external accessory is active - hence the websocket port will only be available if a receiver connection has been established.

From a user perspective this means:

  1. The user starts TMM, configures the survey and connects
  2. The user minimizes TMM and jumps to the application consuming positions
  3. The raw positions can be consumed either via the default location API OR via the socket server

Due to this its a good practice to monitor the connection state of the socket client - and try to reconnect in case of a connection loss.

Testing the socket

A very simple way to test the web socket is via browsing to the websocket page in your browser.

Connecting to

127.0.0.1:9635 

or

ws://127.0.0.1:9635

Equivalent for secure connections:

127.0.0.1:9636

or

wss://127.0.0.1:9636

will show you a json blob with elements as defined above.

This way e.g. progressive web applications can consume highly accurate positions based on the TMM locations.

Keep in mind that an active receiver connection is required to create the socket server within TMM.

 

Certificate handling

Important: The secure web socket server uses a self-signed certificate - hence the Certification Authority (CA) is unknown by e.g. the browser. This may result in security exceptions. Its not possible to use a certificate created via e.g. LetsEncrypt as the certificate would be valid for IP 127.0.0.1 aka localhost - hence copying from device to device is possible - and against the idea of certificates. Its usually possible to handle such exceptions - either on a global base or specific to certain certificates. Technically another option is adding the certificate to the list of trusted certificates - but this requires user interaction on every device.

ServicePointManager
    .ServerCertificateValidationCallback += 
    (sender, cert, chain, sslPolicyErrors) => true;