Closed mnespor closed 1 year ago
Working on it.
How are you going to do the tracking call? I assume native, but havent really thought about how to do that in a non native way. Ill also think about how you can put in the restore call into your flutter app while I am doing the update.
I have this branch - https://github.com/urbanairship/airship-flutter/pull/147
For live activities, you need to do a restore call and a track call when you start one. The track call is straightforward, but the restore call not so much since we call takeOff for the plugin. I think the best bet for you is to use this snippet in application:didFinishLaunching
NotificationCenter.default.addObserver(
forName: Airship.airshipReadyNotification,
object: nil,
queue: nil
) { _ in
if #available(iOS 16.1, *) {
Task {
await Airship.channel.restoreLiveActivityTracking {
restorer in
// update this to match your types
await restorer.restore(
forType: Activity<DeliveryAttributes>.self
)
}
}
}
}
That will allow you to integrate into AIrship without worrying about where takeOff is called.
6.2.0 is out with the update
Thanks @rlepinski! My problem was that the (mainly non-Flutter) project contained a single Flutter view, locking us into 16.9. I don't have any particular concerns about the live activity API yet.
Preliminary Info
Can a new version of airship_flutter that depends on Airship iOS @16.10 be released?
What Airship dependencies are you using?
airship_flutter 6.1.0
What are the versions of any relevant development tools you are using?
Xcode 14.0.1
Report
What unexpected behavior are you seeing?
I can't use the Live Activities features in an app that has a Flutter component.
What is the expected behavior?
Either of these two behaviors:
airship_flutter
that automatically installsAirship/Core
at 16.10 or higher, or'Airship/Core', '16.10.3'
inPodfile
andairship_flutter: ^6.1.0
inpubspec.yaml
What are the steps to reproduce the unexpected behavior?
Thanks!