Owlery.Maui.Scheduler 0.1.33

Owlery.Maui.Scheduler

A .NET MAUI week-view scheduler control, built from plain MAUI primitives — no XAML, no Blazor, and exactly one package reference of its own.

• Infinite horizontal paging through weeks, three days, or a single day, and a month surface.
• Drag-and-drop rescheduling, including across weeks by holding at the edge.
• A drawn grid — hour lines, configurable sub-hour marks, non-working days and hours, today.
• Semantic colours as ordinary bindable properties, so a MAUI Style or AppThemeBinding is the theme.
• Appointment views are pooled and rebound, never rebuilt.

Getting started

dotnet add package Owlery.Maui.Scheduler

The control needs one line from the host, because MAUI gives a library no way to register a handler for itself:

builder.UseOwleryScheduler();

Then supply appointments and respond to what the user did:

new SchedulerView
{
    ItemsSource = appointments,          // IEnumerable<ISchedulerAppointment>
    AppointmentTemplate = template,
    SlotMinutes = 60,                    // a tap selects a whole hour
    DragSnapMinutes = 15,                // a drag lands on the quarter
}

VisibleDatesChanged is the data-loading hook: it reports the range on screen plus a prefetch window, including on first layout.

Documentation

Repository layout

dotnet test Owlery.Maui.Scheduler.Tests/Owlery.Maui.Scheduler.Tests.csproj
dotnet build Owlery.Maui.Scheduler.Sample/Owlery.Maui.Scheduler.Sample.csproj -f net10.0-ios -t:Run

Releasing

Versions come from Nerdbank.GitVersioning (version.json), so a release on tag v0.1.4 publishes 0.1.4.

Run the Create release tag workflow against a branch or commit. It tags that commit with the version NBGV computes for it and pushes the tag — you never type a version number, so the tag and the package cannot disagree.

Then create a GitHub release on that tag by hand — the GitHub UI, or gh release create <tag> --generate-notes --verify-tag. Publishing that release runs .github/workflows/publish-nuget.yml, which builds every target framework, runs the tests, and pushes the package and symbols to nuget.org.

Creating the release by hand is deliberate. A release created with the built-in GITHUB_TOKEN raises no event, so the publish workflow would never run, and a PAT would mean keeping a RELEASE_TAG_TOKEN secret. Using your own identity raises the event without either. Authentication to nuget.org is Trusted Publishing — the workflow proves its identity with a short-lived OIDC token, so there is no API key stored anywhere. That also means the policy on nuget.org names this workflow file: renaming or moving it breaks publishing until the policy is updated to match.

workflow_dispatch builds and packs without pushing, so the whole pipeline can be exercised before a real release.

License

MIT — see LICENSE.