Skip to content
This repository was archived by the owner on May 26, 2026. It is now read-only.
This repository was archived by the owner on May 26, 2026. It is now read-only.

Refactor LegacyAndroidEventBuilder2 #62

Closed
3 of 3 issues completed
Closed

Description

@rfc2822

One core task of the synctools rewrite project is to refactor the LegacyAndroidEventBuilder2 to meet the following goals:

  • Only operation: mapping input data class (AssociatedEvents) → output data class (EventAndExceptions). (No database operations in the mapper.)
  • At the end, every (target) field should have its own mapping class. So for instance a TitleBuilder that is only responsible for building the Events.TITLE field. (See New event builders #50 and Add new event Entity builder logic that is used beside legacy builder #51.)
  • For sub-rows like attendees, there should probably be one builder for the Attendee and then again one builder class for every field of the Attendee row.
  • Because the only operation is mapping, we can have detailed tests with Roboelectric. And because every field has its own class, we can provide all test cases in the corresponding test class without mixing it with other fields.
  • Every field should support everything that's possible with the Android calendar provider. Most fields already have a good functional coverage, but there's still room for improvements (for instance with attendees).

Inputs are:

  • the data to map: should be passed to the mapping function (like function build(AssociatedEvents): Entity) and
  • context data: should be passed to the constructor of the mapper or the respective field mappers. For instance, mapping requires the eTag or syncId to fill the appropriate fields. These are not coming from the iCalendar itself, but from the sync process → context data → passed in constructor.

Output is always the complete EventAndExceptions data class.

Optimizing field builders (for instance improving RRULE and timezone processing) should be done in separate issues.

Activity

  1. self-assigned this
    on Sep 17, 2025
  2. added theissue type on Sep 17, 2025
  3. sunkup commented on Sep 17, 2025

    @sunkup
    Member

    In the canceled PR you linked the ical4j VEvent is the direct input and mapped to Entity. For my understanding, why should now AssociatedEvents become the future input?

  4. rfc2822 commented on Sep 17, 2025

    @rfc2822
    MemberAuthor

    For my understanding, why should now AssociatedEvents become the future input?

    True, i think it's VEvent. We just have to handle AssociatedEvents (pre-processed VEvents: main + exceptions) instead of Event (that currently holds the main event + exceptions) in the main builder.

    So the builder will be called with event: VEvent and main: VEvent. And all VEvents are taken from AssociatedEvents.

  5. rfc2822 commented on Sep 22, 2025

    @rfc2822
    MemberAuthor

    Done. Extracted new issue #48.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

refactoringQuality improvement of existing functions

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions