Skip to main content

Memory adapter

FdcMemoryDataAdapter stores rows in memory and supports the normal dataset query surface, including filtering, sorting, searching, paging, total counts, aggregates, and selected-key filtering.

final adapter = FdcMemoryDataAdapter(
  rows: const [
    {
      'id': 1,
      'company': 'Cascade Coffee',
      'city': 'Portland',
      'state': 'OR',
    },
    {
      'id': 2,
      'company': 'Lakeview Market',
      'city': 'Chicago',
      'state': 'IL',
    },
  ],
);

final customers = FdcDataSet(
  fields: const [
    FdcIntegerField(name: 'id', isKey: true),
    FdcStringField(name: 'company', size: 120),
    FdcStringField(name: 'city', size: 80),
    FdcStringField(name: 'state', size: 2),
  ],
  adapter: adapter,
);

await customers.open();

Updating the source rows​

The adapter exposes a defensive copy through rows and can replace its complete source with replaceRows():

adapter.replaceRows(updatedRows);
await customers.open();

Replacing adapter rows does not implicitly reopen the dataset. Reopen when the visible dataset should reflect the new source.

Local query behavior​

Dataset filters and sorts are evaluated against the memory rows. Paging still follows the same dataset contract, which makes the memory adapter useful for testing screens before connecting a remote or SQLite backend.

Selection-aware queries​

The memory adapter supports selected-key filtering, so paged selection-aware queries use the same dataset contract as backend adapters:

await customers.filter
    .selected(true)
    .apply();

This makes it useful for developing and testing paged selection workflows before connecting a remote backend.

Total counts and aggregates​

The adapter supports total-count reporting and aggregate queries over the complete effective in-memory query result. This allows paging navigators and summary rows to exercise the same contracts used by production paged adapters.

Editing​

The memory adapter is writable. Dataset apply operations update its internal source rows, so it is suitable for complete local CRUD examples and automated tests.

Large local row sets​

For smaller sources, local query work stays simple and avoids unnecessary transfer overhead. For sufficiently large supported operations, FDC can use background-isolate execution policies while preserving the same public API.

Dataset execution tuning is configured through FdcDataSetOperationOptions; see Performance Guidelines.

Development and test fake​

FdcMemoryDataAdapter is also a practical backend substitute for screen development and tests. It can exercise:

  • filtering and sorting,
  • search,
  • standard and infinite paging contracts,
  • total counts,
  • aggregates,
  • selected-key filtering,
  • writable apply flows.

Because the public dataset interaction stays the same, a screen can move from memory-backed development data to a remote or SQLite adapter without redesigning grid/editor binding.