Vilken version av Facebook SDK en Flutter-app får, och vad som styr det

Pluginet deklarerar ett versionsintervall per plattform, och ditt bygge löser ut en version inne i det. Tre deklarationer, en per integrationsväg, och de är svaret på frågan:

Alla tre säger samma sak på tre dialekter: valfri 18.x, ingenting från 19. Podspec-filen säger varför i en kommentar på raden ovanför:

Do not specify PATCH version of FBSDKCoreKit. See README file for explanation.

Det är villkoren som levereras i plugin 0.30.5. De ändras bara i en plugin-release, och CHANGELOG noterar det när de gör det.

Det här är ett beslut, inte en slump, och README säger det: pluginet följer major-versionen av den aktuella Facebook SDK:n, för att vara så kompatibelt som möjligt med andra beroenden i ditt projekt.

Följden är den del som överraskar folk, och README säger den rakt ut. Du får "the latest version" fram till nästa major-release, och det kan bli en källa till oväntat beteende om du inte är medveten om det. Nu är du medveten om det.

Alternativet övervägdes och förkastades. Att låsa pluginet till en specifik minor-version av SDK:t orsakar inkompatibiliteter med andra plugins och beroenden i ett konsumentprojekt. Vilken minor vi än valde skulle vara fel för någon, och den personen skulle inte ha någon väg runt det utom att forka. Ett intervall låter din beroendelösare välja en version som uppfyller hela din beroendegraf, inte bara vår.

Så det är en avvägning, sagt ärligt: du får ett plugin som samsas med resten av dina beroenden, och du ger upp att veta exakt vilket SDK-bygge du har utan att slå upp det. Sista avsnittet på den här sidan handlar om hur du slår upp det.

Här är vad ett flytande intervall som bara är låst på major faktiskt ger, och det är det du inte kan läsa ut ur någon av Metas sidor med release notes.

I plugin 0.30.5 täcker Mavens intervall för Android den senaste 18.x-releasen, som är 18.3.0. iOS-låsningarna täcker den senaste 18.x-releasen, som är 18.1.0.

Samma plugin, samma policy skriven på tre sätt, två olika minor-versioner i en och samma app. Det är inte ett fel och inte en avvikelse att rätta till. SDK:erna för Android och iOS är separata projekt med separata releasehistorier, så "senaste 18.x" är helt enkelt ett annat nummer på varje sida.

Tre praktiska följder:

• Läs release notes för varje plattform separat. Det finns inget enda versionsnummer för Facebook SDK som din app kan ha.
• När du rapporterar ett problem, ange båda de utlösta versionerna. Bara en av dem lämnar halva frågan öppen.
• Beter sig dina Android- och iOS-byggen olika, kontrollera de två utlösta versionerna innan du utgår från att skillnaden ligger i din egen kod. Den kan göra det, men det här är billigare att utesluta.

Fyra golv, och alla fyra deklareras i pluginets egna manifest snarare än i dokumentation du måste lita på:

Varför Flutter 3.38

Ingen preferens. Pluginets iOS-sida använder Flutters plugin-API:er för scene delegate, FlutterSceneLifeCycleDelegate och addSceneDelegate, som lades till i Flutter 3.38. Före den releasen finns inte symbolerna. Vad det ger dig beskrivs i guiden om Swift Package Manager.

iOS 13.0, och varför exempelappen inte är kontraktet

13.0 har varit pluginets verkliga minimum sedan 0.26.0, deklarerat i både s.ios.deployment_target i podspec-filen och platforms: [.iOS(.v13)] i Package.swift.

Exempelappens inställning i Xcode-projektet stod på 12.0 fram till 0.30.5, då den höjdes för att stämma. Den hade helt enkelt aldrig uppdaterats. Läste du exempelappen för att räkna ut minimum läste du fel fil. Podspec-filen och paketmanifestet är kontraktet; exemplet är ett prov som ska kunna kompilera.

Android-verktygskedjan, i 0.30.5

Användbart när det är bygget som fallerar och inte händelserna: Kotlin 2.4.10, AGP 8.13.0, Gradle låst till 8.13 för att matcha AGP 8.13.x, compileSdk och targetSdk 36, och minSdk 21. Det är pluginets egna siffror, från android/build.gradle och Gradle-wrappern, och CHANGELOG noterar varje ändring av dem.

En version på den här sidan är inte ett beroendeintervall, och den är skälet till att pluginet sätter någonting alls vid uppstart. Facebook SDK 18.x levereras med en standardversion av Graph API som Meta redan har tagit bort, och standarden skiljer sig per plattform.

Pluginet skriver över den under sin initiering, så de flesta appar behöver ingen konfiguration för det. I plugin 0.30.5 är versionen den sätter v24.0. Behandla pluginets README och CHANGELOG som sanningskälla för det aktuella värdet, eftersom det rör sig i takt med Metas stödda intervall.

Vad en borttagen version faktiskt gör

Den får inte dina anrop att misslyckas. Metas versioneringsguide anger att när en version inte längre är användbar sätts anrop till den att som standard gå till den äldsta nästa version som fortfarande är användbar. En app som lämnats på en borttagen standard fortsätter att fungera, betjänad av en version ingen valde.

Vad som landar på dig är beskedet. Meta mejlar appägare en deadline för borttagning, och den deadlinen kommer från Metas aktuella golv för utvecklarnotiser snarare än från utgångsdatumet för den version du råkar ligga på. Golvet rör sig enligt Metas schema, oberoende av när någon enskild version går ut. Issue #474 på det här pluginet är ett av de mejlen, och hela historien finns i Facebook-händelser syns inte i Events Manager.

Om du behöver en specifik version

Anropa setGraphApiVersion så tidigt som möjligt i uppstarten, före allt som kan utlösa en Graph API-förfrågan. Ditt anrop vinner: pluginet sätter sin standard när det kopplas till motorn, och ditt Dart-anrop körs efter det.

final facebookAppEvents = FacebookAppEvents();

// Valfritt. Pluginet sätter redan en aktuell standard vid initiering.
await facebookAppEvents.setGraphApiVersion('v24.0');

await facebookAppEvents.activateApp();

Härled det inte från den här sidan. Läs det ur filerna där varje verktygskedja skriver ner den version den faktiskt valde.

iOS

Med CocoaPods anger ios/Podfile.lock den utlösta versionen av FBSDKCoreKit. Med Swift Package Manager anger Package.resolved den utlösta versionen av facebook-ios-sdk.

Android

Gradle skriver ut den version det valde för en konfiguration:

cd android
./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep facebook-android-sdk

Beroenderapporten namnger den version Gradle valde ur intervallet, vilket är ett svar och inte en gissning.

Vad som händer vid Facebook SDK 19

[18.0,19.0) och "18.0.0"..<"19.0.0" utesluter båda 19 genom sin konstruktion. En release av Facebook SDK 19 når därför inte din app av sig själv: intervallen måste flyttas först, och det sker i en plugin-release. Så när du planerar en uppgradering över en major-version av Facebook SDK är pluginets CHANGELOG filen som berättar om den finns än. Metas release notes berättar bara att SDK:t existerar.