AppsFlyerSDK / AppsFlyerFramework

AppsFlyer Apple SDK
https://support.appsflyer.com/hc/en-us/articles/207032066-AppsFlyer-SDK-Integration-iOS
Other
166 stars 89 forks source link

AppsFlyerTracker with wrong a signature #105

Closed mendesbarreto closed 1 year ago

mendesbarreto commented 4 years ago

Report

The AppDelegate method to Deeplink on Swift 5 changed the interface declaration to:

// UIApplicationDelegate
func application(_ application: UIApplication,
                     continue userActivity: NSUserActivity,
                     restorationHandler: @escaping ([UIUserActivityRestoring]?) -> ()) -> Bool

and the version of AppsFlyerTracker is different:

// The AppsFlyerTracker
func continue(userActivity: NSUserActivity, restorationHandler: (([Any]?) -> Void)) -> Void))

So the problem is, I could not pass the restorationHandler to AppsFlyer because the closure type is different and I don't know if is a good idea to cast it by my self.

SDK Version

5.0.0

andr-ggn commented 4 years ago

https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/76

mendesbarreto commented 4 years ago

Thank you for your reply.

But I have some points about this #76 .

Realy don't think it's right to pass a NIL. First, because it's not semantic, we have a method signature in AppDelegate that should be the same as AppsFlyer, and in swift, the interface is asking for a not NIL closure value.

I don't know for sure what the what AppsFlyer does with restorationHandler (I could guess), but if the value is on the method signature, I believe there is a reason for that and yet could bring to the lib some unwanted behaviours (like a crash because the method is waiting for a not null value), otherwise, If the param does nothing on the code behind, it should be removed to avoid mistakes.

Thanks

af-fess commented 1 year ago

This issue has been inactive for a while, and will now be closed due to inactivity. If you still believe this is a valid issue, please feel free to reopen it or create a new issue with updated information.