ASAPPeer

From developers perspective, there are just two relevant methods offered by an ASAP peer:

• an ASAP peer can be asked to deliver a message
• a listener can be informed about incomming messages

send a message

static final CharSequence YOUR_APP_NAME = "application/x-yourAppName";
static final CharSequence YOUR_URI = "yourSchema://example";
...
ASAPPeer alicePeer = ...;
byte[] serializedData = "VerySimpleExampleData".getBytes();
// send data
alicePeer.sendASAPMessage(YOUR_APP_NAME, YOUR_URI, serializedData);
// message is stored in the peer

Peers can establish a point-to-point connection. We talk about an ASAP Encounter. Peers exchange messages during each encounter. Peers remember their encounter. Message are only sent one time to another peer. This memory is based on the era concept. Developers do not have to deal with this era concept. The following section can be read as just for your information

Era

Era is a non-negative integer value. The initial era is 0 (zero). The era is kept persistent. Era is incremented each time an ASAP encounter is performed and your application sent a new message after a previous encounter.

Example: There might be two persons using your ASAP based application: Alice and Bob. Your application runs e.g. on their mobile phones. Maybe, you application is a kind of messenger.

Let’s also assume, that user Alice has produced a message. Your application would have ask its ASAP peer to send this message. This message is stored in the local ASAP peer.

Now, the ASAP peers on both devices establish a connection (e.g. Bluetooth, an Internet connection via an ASAPHub). Era on Alice side would be increased to 1 (one). Era in Bob side remains unchanged: No new message was created.

Peer on Bobs’ side would receive a message from Alice. It would know that this message was create in Alice era 0. Both peers would remember that encounter. Alice would remember that it sent any message up to era 0.