To get realtime updates about changes to presence data, use the Presence API. This article includes instructions on how to implement Dittoβs Presence APIs to enable the following end-user functionality for network monitoring and management within your app:
- Setting and updating peer-specific information, such as name, role, and location.
- Viewing information about other peers currently connected in the mesh.
Accessing Presence APIs
To access API methods for mesh presence functionality, call the presence namespace on the root Ditto object:
Presence Graph
Once discovered in the mesh, peers automatically establish a presence graph by advertising their device presence within the mesh and forming network connections with other connected peers.
The presence graph is a data structure representing the current state of the mesh from a specific peerβs point of view.
You can integrate the presence graph into your app to enable end-user functionality like network monitoring, management, and transport optimization. For example, once implemented, end users can input personal information, such as their name, and inspect remote peers connected within the mesh. For more information, see DittoSwiftTools on GitHub.
Accessing Presence Graphs
To view your current presence graph:
Once invoked, Ditto returns the following object, allowing you to perform actions like displaying the status of connected peers and managing network resources:
The localPeer is the metadata set by the end user within your app. The remotePeers property provides an array of the other client devices connected to the mesh. (See End-User Defined Metadata for more information.)
Observing Presence Graph Modifications
To monitor and handle changes observed to the presence graph, call the change handler with the updated graph object as follows:
Make sure the observer response object remains in memory during runtime; otherwise, Ditto removes
it during the periodic garbage collection process running in the background, resulting in the
change handler no longer being triggered.
Android: Always close presence observers explicitly. On Android, if a PresenceObserver is garbage collected without being closed first, its finalizer runs on Androidβs FinalizerDaemon thread. If the teardown performs any I/O (for example, due to a custom log callback registered via setCustomLogCallback), the finalizer can exceed Androidβs hard 10-second timeout, resulting in a java.util.concurrent.TimeoutException crash.To avoid this, always call close() on the observer when it is no longer needed. If you are wrapping the observer in a Kotlin callbackFlow, ensure the awaitClose block calls observer.close() and that the Flowβs coroutine scope is properly cancelled β for example, by collecting within lifecycleScope.
Closing Presence Observers
When you no longer need presence updates, close the observer to release resources:
In Kotlin v5, presence.observe() returns a Flow<DittoPresenceGraph> instead of a DittoPresenceObserver. When you collect the Flow within a lifecycle-aware scope like lifecycleScope, cancellation and cleanup are automatic β no manual close() is needed.
Peer Key Identifier
Once discovered in the mesh, each peer device running Ditto is automatically assigned a peer key.
Reading Peer Keys
View your local deviceβs peer key or the peer key identifying a specific remote device:
- To retrieve the peer key for the current peer:
- To retrieve the peer key for a remote peer:
End-User Defined Peer Metadata
Using the peer-metadata property, you can provide each peer connected within the mesh the ability to set and view information about themselves or read information defined by other peers within the mesh.
Data added to the peer metadata object is shared during the connection handshake. Large data
payloads may impact performance on low-bandwidth connections, such as BLE.
The following table provides an overview of key considerations to know before setting peer metadata, as well as Dittoβs recommended best practices to ensure optimal mesh performance and avoid potential issues:
To implement functionality providing end users the ability to define metadata, call the setPeerMetadata API method as follows:
Once set, inspect the metadata:
To inspect the metadata set by all other peers in the mesh:
Identity server metadata is application information that is set when the user is authenticating. As part of the authentication process the application developer can provide information about the peer that is added to the userβs peer object and shared with other peers in the mesh.
The identity server metadata is signed by the identity server and validated by all peers reading to prevent spoofing of the information.
The identity server metadata is set during the See End-User Access>Setting Identity Server User Metadata for specifics.
To inspect the identity server metadata of the local peer doing the following:
To inspect the identity server metadata set by other peers connected within the mesh: