Complete Project

Eleven lessons have each isolated a single difficulty. That is necessary for learning, but not enough for knowing how to build: in a real application, these building blocks interact, and it is that interaction that raises the hard questions. Where should the code that decides whether to read from the cache or the network live? How does a form tell the list that an item has changed? What does the user see while a local write is waiting for remote confirmation?

We are going to build Carnet, a synced task manager. The choice is deliberate: it is the smallest domain that simultaneously requires a local database, an API, state shared across screens, a validated form, and offline operation. A prettier demo application that is purely local would teach nothing beyond lesson 4.

The emphasis is on architecture, that is, on the boundaries between layers. Flutter code becomes unmanageable for an almost always identical reason: business logic ends up in build methods, network calls in onPressed handlers, and SQL in widgets. Separating them costs a few extra files at the start and makes it possible to test, change, and understand the code afterward.