docs(spec): especificar la simetría de los providers de iOS (breaking, sin implementar) - #22
Closed
rndevelo wants to merge 3 commits into
Closed
Conversation
Convertir GoogleSignInProviderIOS en object cierra la causa que el 003 parcheó: es el único de los seis providers con forma distinta, y de ahí salió la documentación falsa que se copió a los otros cinco. Queda escrito y sin implementar. Rompe a los hosts Swift ya integrados, así que necesita ir coordinado con el bump del pin en Fledge, y arrastra una decisión abierta sobre getClientId(). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E41idMYhfgBSz2EeuNUn5Q
La línea 609 usaba .companion y la 633 .Companion.shared para el mismo objeto, con 24 líneas de diferencia. Las dos compilan; tener las dos es lo que enseña al lector que hay dos contratos. Va aparte del spec 011 a propósito: si el 011 se queda esperando a Fledge, esto se puede cherry-pickear a develop por su cuenta. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E41idMYhfgBSz2EeuNUn5Q
…e Swift Cierra la causa que el spec 003 solo pudo parchear. Google era el unico de los seis providers de iOS con forma de `class` + `companion object`, porque recibia GoogleSignInConfig en el constructor. Kotlin/Native exportaba ese companion por su cuenta, asi que el mismo seam tenia dos escrituras validas en Swift, y el README acabo publicando ejemplos con la equivocada. Ahora es un `object` como los otros cinco y la config viaja en signIn(config), igual que AppleSignInProviderIOS.signIn(scopes). Verificado en el header de Objective-C del framework, no solo por grep: ComposeAppGoogleSignInProviderIOSCompanion desaparece y la clase pasa a exponer `getter=shared`, identica a los providers que ya eran object. getClientId() se elimina: quien pudiera llamarla ya tiene en la mano la GoogleSignInConfig de la que leia. Cero call sites en toda la organizacion. getTopViewController() y onSignInResult() se quedan con el @deprecated que les puso el spec 010. De paso, dos cosas que la verificacion saco a la luz: - El KDoc de AppleSignInProviderIOS explicaba que `.companion` existe "para el companion object de una clase, como GoogleSignInProviderIOS". Ya no es cierto. - CLAUDE.md documentaba `:custom-login:linkDebugFrameworkIosSimulatorArm64`, que no existe: la libreria no declara binaries.framework propio, se exporta a traves del ComposeApp del demo. El task correcto vive en :composeApp. BREAKING CHANGE: los hosts Swift pasan de GoogleSignInProviderIOS.Companion.shared.* a GoogleSignInProviderIOS.shared.* Sale en 2.0.0, junto al renombrado custom-login -> baselogin, para que los consumidores migren una sola vez. Comprobado que hoy no rompe a nadie: ni Fledge ni Paparcar nombran este provider en Kotlin ni en Swift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sale de #21. Draft a propósito: es un spec sin implementar y declara un breaking change.
Qué propone
GoogleSignInProviderIOSes el único de los seis providers de iOS que esclass + companion objecten vez de
object, así que se alcanza como.Companion.sharedmientras los otros cinco son.shared. Como fue el primero que existió, alguien copió su bloque de ejemplo a los otros cinco: deahí salió la documentación falsa que el #14 parcheó.
El 003 arregló los síntomas. Esto cierra la causa: una sola forma,
X.shared, para los seis.Por qué está parado
Rompe a cualquier host Swift ya integrado, Fledge incluido. Lo que lo hace aceptable es que falla
en compilación, no en runtime — el host se entera al bumpear el pin, no un mes después con un
botón muerto. Aun así necesita:
apptolast/Fledge, un commit aquí y dos líneas de Swift allí.getClientId(), que depende del constructor que se vacía. La propuesta esquitarla; la alternativa es
getClientId(config:). Se decide en/plan.Lo que sí es mergeable ya
El segundo commit arregla el README, que hoy usa las dos formas para el mismo objeto con 24 líneas
de diferencia (líneas 609 y 633). Va aparte justo para poder cherry-pickearlo a
developsi el011 se queda esperando a Fledge.
Verificado en Windows:
:custom-login:ktlintCheck+:custom-login:testDebugUnitTest(254 tests, 0 fallos). El Swift de esta rama no se ha compilado nunca: pendiente de Mac.🤖 Generated with Claude Code
https://claude.ai/code/session_01E41idMYhfgBSz2EeuNUn5Q