search

builttoroam / device_calendar

A cross platform plugin for modifying calendars on the user's device
https://pub.dev/packages/device_calendar
BSD 3-Clause "New" or "Revised" License
259 stars 258 forks source link

Support for populating the event editor or the device? #473

Open rich-instride opened 1 year ago

rich-instride commented 1 year ago

When creating a calendar event with add_2_calendar, their plugin populates the device calendar editor (e.g., Google Calendar) with some field values. The user can further modify and then submit or cancel the event. Does device_calendar support populating the calendar event editor for the device? The repo example shows custom editors, but I'd rather use the devices.

thomassth commented 1 year ago

Looks like you're trying to set default values, which is easy enough in the current state.

But neither Google nor Apple allow API control to their calendar apps (and their pickers).

rich-instride commented 1 year ago

Glad to hear it's easy in its current state. What is the API call for setting the default values? I didn't see anything in the device_calendar docs. I'm running the example and it uses custom forms to set the calendar. How do I set the default values from device_calendar?

rich-instride commented 1 year ago

So, I'd like to call createOrUpdateEvent, but rather than it populating the calendar immediately, it populates the calendars event editor. The user then reviews/edits the information and the clicks Save. How would that be done with device_calendar?

IVLIVS-III commented 1 year ago

afaik device_calendar provides no API at the moment to invoke a Device-native sheet to edit calendar events. This plugin aims to provide a cross-platform interface for both Android and iOS. If such a device-native ui-sheet exists on both platforms (which I don't know), a pull request is very welcome to expose this feature as well. If however this feature only exists on one of both platforms we should discuss further if the benefits of exposing platform-specific features outweighs the drawbacks of splitting the API even further.