The app from the last lesson has clean view models, but its data sits in the code. A Kladde that only shows sample appointments isn’t one. In this lesson the data comes from the Kladde’s web API from K2, the app signs in to Entra ID, the appointments are also stored locally in a database, and whatever is entered without a network goes to the API later, even if the API has meanwhile come to know something different.

The scope of this lesson:

Part What you get
API a typed client that fetches the Kladde’s appointments and contacts and creates an appointment
Sign-in MSAL.NET, one token per call, checked by the web API
Storage SQLite for the appointments, network status with Connectivity
Sync save locally first, then send, keep conflicts visible

Where the Kladde stands

At the start, what lesson W2.2.1 built applies: the library Kladde.App.Logic (only net10.0) holds ContactsViewModel, AppointmentsViewModel, NewAppointmentViewModel, the interfaces IKladdeData and INavigator and the sample data SampleKladdeData (built on SampleData), plus the response types ContactResponse and AppointmentResponse. The app Kladde.App shows them on pages, and tests/Kladde.App.Logic.Tests checks them. The library and the tests are in Kladde.slnx, the app isn’t. From K2 you need the web API Kladde.Web with GET /api/contacts, GET /api/appointments and POST /api/appointments, the sign-in through Entra ID with the roles Buero and Leitung (lessons 2.6.2 and 2.6.3) and the rule that an overlap is answered with 409 (lesson 2.3.7 and milestone 2 in module 2.11). If your classes and files are named differently, keep your names and apply the steps.

The parts fit together like this:

AppointmentsViewModel -> IKladdeData (KladdeData)
                           |- IKladdeApi         KladdeApiClient: HttpClient + Bearer-Handler
                           |- IAppointmentStore  SqliteAppointmentStore
                           `- AppointmentSync    INetwork, API and store

One sentence on direction: the view model still sees only IKladdeData. Everything that is new in this lesson and doesn’t need MAUI goes into the library and can therefore be checked without a device. Only what the platform needs goes into the app: the sign-in, the network information and the file location.