Introduce mapping classes

[rfc2822]

Depends on #36

This PR extracts Event builder (build…) and processor (populate…) logic to dedicated classes, without changing the logic itself.

• Move builder/processor logic to separate classes.
• Move tests.

The interesting part happens in AndroidEvent. The populate/build methods are only slightly adapted, for instance by introducing a to: Event argument for populate. The logic of building/populated has not been touched.

The huge number of lines comes from moving the methods and the tests.

PS: Changed some tests to become more independent of each other, for instance by using the class name in test accounts.

[Copilot]

Pull Request Overview

This PR extracts the event build and populate logic out of AndroidEvent into two focused mapping classes, improving separation of concerns without altering existing behavior.

• Introduce AndroidEventProcessor for reading Android provider rows into Event.
• Introduce AndroidEventBuilder for writing an Event back to Android provider rows.
• Refactor AndroidEvent to delegate to these new classes and remove inline mapping code; update package and imports in AttendeeMappings.

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
AttendeeMappings.kt	Updated package, docs, and simplified getParameter calls.
AndroidEventProcessor.kt	Added new class handling populate logic from provider rows.
AndroidEventBuilder.kt	Added new class handling build logic into provider rows.
AndroidEvent.kt	Refactored to delegate to builder/processor classes, removed inline mapping code.
AttendeeMappingsTest.kt	Updated package declaration and reformatted assertions.
AndroidEventProcessorTest.kt	Moved tests to new mapping package; no logic changes.

Comments suppressed due to low confidence (3)

lib/src/main/kotlin/at/bitfire/synctools/mapping/calendar/AndroidEventBuilder.kt:1

• [nitpick] There are thorough tests for AndroidEventProcessor, but no dedicated unit tests for AndroidEventBuilder. Adding coverage for builder code paths—especially around recurrence rules, exceptions, and extended properties—would help ensure correctness during future refactors.

/*

lib/src/main/kotlin/at/bitfire/synctools/mapping/calendar/AttendeeMappings.kt:20

• [nitpick] The reference [Attendees] can be ambiguous in generated docs. Consider using a fully qualified link, e.g. [CalendarContract.Attendees], or importing it explicitly so readers know exactly which API is being mapped.

 * Defines mappings between Android [Attendees] and iCalendar parameters.

lib/src/main/kotlin/at/bitfire/synctools/mapping/calendar/AndroidEventBuilder.kt:304

• This mutates the original event.rDates list, which may cause unexpected side effects if the same Event instance is reused. Consider operating on a copy of the recurrence list or using a local temporary list before building the Android row.

                    event.rDates.addFirst(RDate(listWithDtStart))

[sunkup]

Hmm. Why are 12 tests failing when there has been no logic changes, but only rearrangements and slight additions? Since you requested the review with failing tests, will the tests be fixed in a new PR then? I think we should keep everything in a working state. Or is that not possible?

[rfc2822]

Why are 12 tests failing when there has been no logic changes, but only rearrangements and slight additions?

Looks like it was caused by the shared time zone registry in DateUtils. Should be fixed by #36 (which is already merged into this PR).

[sunkup]

Did the force push remove the previous commits from ths PR? The top comment talks about changes that are not present (anymore)? Or have those changes been merged into the main branch already?

[github-actions]

This PR/issue depends on:

• Don't use global TimeZoneRegistry #36

[github-actions]

This PR/issue depends on:

• Don't use global TimeZoneRegistry #36

[sunkup]

Looks ok