Dartvel sync, presence and offline models

// Every save, destroy and restore of an Article in this process.
Article.changes.listen((DVModelChange<Article> change) {
  DV.log('${change.kind.name} ${change.model.slug} for ${change.tenant}');
});

// The whole list now, and again after each change.
final DVModelWatch watch = await Article.watch((List<Article> articles) {
  DV.log('${articles.length} articles');
});

// Saving is what publishes it. There is no sync() to call: a model that
// has to be told to sync is not realtime.
await article.save();

// Only because this watch was started outside a widget. One started in a
// page goes when the page does.
await watch.cancel();

A watcher only gets changes for the current tenant. Article.allChanges is every tenant's, for a process that serves all of them.

// A change is delivered only to watchers allowed to see the model.
Article.syncPolicy((Article article) => article.published);

DVPresence.startSweeping(); // drops members whose heartbeats stopped

DVPresence.channel('article:hello-world').listen((DVPresenceEvent event) {
  DV.log('${event.member.id} ${event.kind.name}');
});

await DVPresence.join(
  'article:hello-world',
  DVPresenceMember(id: 'user-1', state: <String, Object?>{'name': 'Ada'}),
);
await DVPresence.heartbeat('article:hello-world', 'user-1');

final List<DVPresenceMember> here = DVPresence.members('article:hello-world');
await DVPresence.leave('article:hello-world', 'user-1');

A model you have opted into syncing is read and written the way any other model is. There is nothing to wire up and no object to implement: saving a record is what publishes the change, and watching one is what receives it.

Today that delivery happens inside one process. Carrying it between servers and devices is the framework's job and is not built yet, so a change on one instance does not reach another.

A data model that has to work with no network says so, and says how a write made offline is resolved when it reaches the server.

// A data model that has to work with no network says so, and says how a
// write made offline is resolved when it reaches the server. Nothing else
// is declared: the device keeps its own copy and a queue, and the server
// applies what the device sends, both from this declaration.
@DVModel(offline: DVConflict.lastWriteWins)
class const _Dispatch({
  required final String id,
  required final String reference,
  required final int quantity,
});

That is all you declare. The data model is then saved, deleted and read like any other, with a network or without one.

// Saved on this device at once, with a network or without one. It
// reaches the server when the server can be reached.
const Dispatch dispatch = Dispatch(id: 'd1', reference: 'R-1', quantity: 2);
await dispatch.save();

// Read back from the device, in a tunnel as on Wi-Fi.
final Dispatch? again = await Dispatch.find('d1');

// Where this record stands: pending, syncing, synced, conflicted or
// rejected.
dispatch.syncState.listen((DVSyncState state) {
  DV.log('${dispatch.reference} is ${state.name}');
});

// Deleting is the same: gone from the device now, from the server later.
await dispatch.destroy();

A save returns as soon as the record is on the device. The device keeps its own copy and a queue of every change, in the order they were made: SQLite on phones, desktops and TVs, IndexedDB in a browser. Reads come from that copy, so they answer in a tunnel as they do on Wi-Fi.

You never send the queue. It goes when the app starts, after each save while the server can be reached, and again as soon as the device can reach the server after losing it. A send that fails is tried again later, on its own.

The queue goes in order, and stops at a dropped connection, so a later change never reaches the server before an earlier one.

Signing out sends what it can, then removes the device's copy and queue, so the next person to sign in on that device sees none of it.

Application code does not branch on connectivity: a write is made the same way in a tunnel as on Wi-Fi. It does show it, though, and that reading is a signal.

// What the device can reach, as a signal: a banner is a widget that
// rebuilds, not a listener to remember to dispose.
@DVFunctionalWidget()
@pragma('vm:entry-point')
Widget _connectionBanner(BuildContext context) {
  final DVNetworkStatus status = DV.Platform.network.watch(context);
  if (status != DVNetworkStatus.offline) return const DVBox.list(<Widget>[]);
  return DVBox.list(<Widget>[
    const DVText('Offline. Your changes are saved here and will be sent.'),
    DVText('Since ${DV.Platform.network.since}'),
  ]);
}

canReachTheServer is what most call sites are asking. It is true on a metered connection, and true when nothing has reported: a write's own failure is what proves the server is gone.

since is when it last changed, so an offline banner can say how long. A platform that re-reports the same status does not move it.

The generated backend takes each change a device sends and applies it itself. There is no server code to write for it: what decides is the data model's own declaration and its policy.

Every change is put to the data model's policy first, as create, update or delete, the same question an online change asks. The policy is asked about the record, as the class your policy is written for. A policy that refuses, or cannot answer, refuses the change.

A refusal is remembered, so a device sending a refused change again gets the same answer, even if the policy has changed since.

With lastWriteWins, the later change wins by the time it was made on its device, corrected for that device's clock drift. The order changes arrive in does not decide.

DVConflict.ask is refused offline, because nobody is there to answer. A data model that declares it stops the build, so it cannot fail on somebody's phone instead.

Only the browser reports connectivity. Elsewhere a failed send is what says the server is gone, and the retry is what finds it again.

GETTING STARTED

APP

DATA

BACKEND

OPERATIONS

SHIPPING

REFERENCE

Sync and offline

Watch model changes

Show who is here

Reaching another server or another device

Keep writing while offline

Show what the device can reach

What the server does with a change made offline