You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 26, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on May 26, 2026. It is now read-only.
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.
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?
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.
Activity
LegacyAndroidEventBuilder2event row builder logic into separate builders #64LegacyAndroidEventBuilder2#66sunkup commentedon Sep 17, 2025
In the canceled PR you linked the ical4j
VEventis the direct input and mapped toEntity. For my understanding, why should nowAssociatedEventsbecome the future input?rfc2822 commentedon Sep 17, 2025
True, i think it's
VEvent. We just have to handleAssociatedEvents(pre-processed VEvents: main + exceptions) instead ofEvent(that currently holds the main event + exceptions) in the main builder.So the builder will be called with
event: VEventandmain: VEvent. And all VEvents are taken fromAssociatedEvents.EventtoVEvent#69EventtoVEvent#69rfc2822 commentedon Sep 22, 2025
Done. Extracted new issue #48.