fix(deps): update dependency flutter_local_notifications to v15 - autoclosed #43
No reviewers
Labels
No labels
bug
dokumentace
dotaz
duplikát
good first issue
help wanted
knihovna
lowprio
pr: funkce
pr: okno
pr: pubspec
vylepšení
wontfix
No milestone
No project
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set.
Reference: hernik/opencanteen#43
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/flutter_local_notifications-15.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
^12.0.3+1
->^15.0.0
Release Notes
MaikuB/flutter_local_notifications (flutter_local_notifications)
v15.1.2
Compare Source
getNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecified. This hotfix has been taken from the 16.0.0-dev.3 prerelease and included in the 14.1.4 hotfix releasev15.1.1
Compare Source
periodicallyShow()
method would fail to have the next subsequent ones scheduled. This issue started occuring in 14.0 where support for inexact notifications was added using theScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being added. This hotfix has been taken from the 16.0.0-dev.2 prerelease and has also been applied to the 14.1.3 hotfix release as wellv15.1.0+1
Compare Source
v15.1.0
Compare Source
v15.0.1
Compare Source
ScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being addedv15.0.0
Compare Source
schedule()
,showDailyAtTime()
andshowWeeklyAtDayAndTime()
methods. Notifications that were scheduled prior to this release should still workTime
classzonedSchedule()
on Linux will now throw anUnimplementedError
to align with how their is a Linux implementation but the method hasn't been implementedScheduledNotifReceiver
instead ofScheduledNotifReceiver
. When logging that exact alarm permissions have been revoked the the tag is nowFLTLocalNotifPlugin
instead ofnotification
initialize()
methodv14.1.4
Compare Source
getNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecified. This hotfix has been taken from the 16.0.0-dev.3 prereleasev14.1.3+1
Compare Source
v14.1.3
Compare Source
periodicallyShow()
method would fail to have the next subsequent ones scheduled. This issue started occuring in 14.0 where support for inexact notifications was added using theScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being added. This hotfix has been taken from the 16.0.0-dev.2 prereleasev14.1.2
Compare Source
ScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being addedv14.1.1
Compare Source
showDailyAtTime()
method. Thanks to the PR from Yuichiro KawanoSystem.out.println()
v14.1.0
Compare Source
alarmClock
as one of theAndroidScheduleMode
options. This is useful for cases where a notification functions as an alarm and may show an alarm icon on the status bar depending on the device Thanks to the PR from Muhammed Ballanv14.0.1
Compare Source
showUserInterface
set to true whilst app is terminated wouldn't dismiss/cancel notificationv14.0.0+2
Compare Source
v14.0.0+1
Compare Source
v14.0.0
Compare Source
id
property of theActiveNotification
class is now nullable to help indicate that the notification may not have been created by the plugin e.g. it was from Firebase Cloud Messaging. Thanks to the PR from frankvollebregtAndroidNotificationCategory
AndroidServiceForegroundType
AndroidServiceStartType
AudioAttributesUsage
Day
InterruptionLevel
LinuxNotificationCategory
LinuxNotificationUrgency
Priority
AndroidScheduleMode
to allow for configuring this if required. TheandroidAllowWhileIdle
argument is now deprecated when using the APIs available for scheduling notifications via theFlutterLocalNotificationsPlugin
APIs and will be removed in the future. Thanks to the PR from Joachim Böhmer. Note that if if a notification was scheduled with exact timing via theAndroidScheduleMode
but the exact alarm permissions had been revoked, an error log message will be written and notification will no longer be scheduled. Do note that theandroidScheduleMode
parameter has a default value ofAndroidScheduleMode.exact
to align with what was the default value ofandroidAllowWhileIdle
before (i.e.false
) where that meant exact timing was to be used but the device being a low-powered idle may cause it to be delayed. When theandroidAllowWhileIdle
parameter is removed in the future,androidScheduleMode
will become a required named parameter to ensure developers explicitly specify the value they wantandroidAllowWhileIdle
is deprecated via theFlutterLocalNotificationsPlugin
APIs,allowWhileIdle
has been removed and completely replaced by ascheduleMode
parameter when whe directly using theAndroidFlutterLocalNotificationsPlugin
APIszonedSchedule()
with a date/time value that is exactly when daylight savings occurs and the APIs from Apple weren't able to resolve what the actual date/time is meant to beAndroidServiceForegroundType
values to align with new additions that are part of Android 14. Thanks to the PR from Rexiosmockito
dev dependencyIOS
as part of the name instead of the newer classes that have theDarwin
prefixv13.0.0
Compare Source
flutter_local_notifications_linux
2.0.0 asffi
2.0.0 requires Dart 2.17 at a minimum and that shipped with Flutter 3.0.0ffi
dependency that Linux implementation of the plugin was already using@mipmap/ic_launcher
resource requires additional release build configuration. Thanks to the PR from Daniel ArndtConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.
fix(deps): update dependency flutter_local_notifications to v15to fix(deps): update dependency flutter_local_notifications to v15 - autoclosed