Most FirstParty users will still need to use methods from FIRDynamicLinks.h
(shouldHandleDynamicLinkFromCustomSchemeURL:/dynamicLinkFromCustomSchemeURL: etc.).
Arguably, including both headers looks odd, hence add the IWYU pragma so that it's sufficient
to only use the FirstParty header.
Recreating PR #5966
Instead of using firebasedynamiclinks-ipv4.googleapis.com and firebasedynamiclinks-ipv6.googleapis.com for doing attribution calls, we are moving towards using firebasedynamiclinks.googleapis.com.
Fixes#5032
-changed ipv4 and ipv6 attribution calls with a single direct url.
-Removed and refactored code to get rid of code to handle consolidated results from ipv4 and ipv6 result.
-Made changes to Test app to show alert dialog when universal linking when app is not in background case and also for fresh start case.
Removing client id usage in api call and respective checks
FDL SDK was using client id passed in FIROptions to make API calls. From backend side, we no longer needs client id to be sent. So removing the client id usage in FDL SDK along with parameter no null checks.
-Removed the usage of Client id from FIROptions.
-Removed non null parameter checks for client id.
-Deprecated 1p API method setUpWithLaunchOptions::apiKey:clientID:urlScheme:userDefaults: and added setUpWithLaunchOptions::apiKey:urlScheme:userDefaults:
-Removed Client id usage in Unit tests.
* Checking the first pasteboard item in ios14
* Cleaned up method and added ifdef
* Renamed variable
* Style
* Refactored method
* Using another url detecting api
* Made sure pasteboardContents is initialized
* Changelog
* Update Changelog
* Removed trailing space
* Fix for internal bug b/154589338
Most of the times, when the app is cold started, we are making api calls to:
https://firebasedynamiclinks-ipv4.googleapis.com/v1https://firebasedynamiclinks-ipv6.googleapis.com/v1
Until we get a successful response. But sometimes, if the device doesn’t have support for v6 endpoint and if the v4 endpoint doesn’t retrieve a valid dynamic link, it will return error. This mostly happens when user directly goes to App Store and installs an app which has fdl sdk integrated.
For dynamic links, we want the app to retrieve the pending dynamic link on the very first start of the app after install so that 3p developers can deeplink to a particular page in the app. If the pending links retrieval failed during the first start, there is no point in retrying the retrieval during next restart since it could result in an un expected deep link for the user when they opens up the app for subsequent restarts (if a valid dynamic link is returned).
Paul Beusterien