Intenté implementar anuncios nativos de Google adMob en mi aplicación para iOS y seguí el tutorial oficial de admob: https://developers.google.com/admob/ios/native/advanced

Ya sea que agregué el marco de admob requerido manualmente o por CocoaPods, el constructor de interfaces no detectó todas las clases en los marcos de admob, por lo que no pude configurar la clase personalizada de UIView en las clases de vista de admob deseadas. Pero, extrañamente, pude usar todas las clases relacionadas con admob después de que se importó el marco en mis archivos rápidos. Vea la siguiente captura de pantalla:

enter image description here

enter image description here

Encontré un proyecto de github, que no hizo más que implicar el anuncio nativo de admob mediante Cocoapoding el marco de admob (enlace del proyecto). Descargué su código fuente y, curiosamente, las clases de marco de admob pueden ser detectadas por la cara de la interfaz en este proyecto.

enter image description here

He estado rascándome la cabeza durante un par de días y buscando la solución sin suerte. Por favor, ayúdeme si tiene una idea de por qué sucedió esto y su ayuda es muy apreciada.

2
marcel 24 feb. 2021 a las 07:32

3 respuestas

La mejor respuesta

TL; DR

Cambie la versión del pod de CocoaPods a 7.67.0. (-:

Podfile

pod 'Google-Mobile-Ads-SDK', '7.67.0'

Explicación

Esto se debe a que GoogleMobileAds.framework se convirtió en GoogleMobileAds.xcframework en 7.68.0+ - fuente. Esto significa que el tiempo de ejecución de Objective C difiere entre el marco (iOS 9) y el objetivo principal (iOS 14.0+). XCFramework s son un tipo especial de marco binario , por lo que editar la versión de iOS manualmente después de que ya se haya compilado no hará ninguna diferencia y, de hecho, incluso si especifica un iOS versión en tu Podfile no hará ninguna diferencia.

El código principal tiene un tiempo de ejecución de Objective-C diferente y más rápido bajo el capó, por lo que rastrea las clases usando diferentes estructuras de datos para XCFramework. Por ejemplo, si se define una categoría en el marco, se almacenará en la memoria de lectura y escritura incluso si no se utiliza el nuevo método anulado (en tiempo de ejecución). Por otro lado, el tiempo de ejecución de Objective-C en iOS 14.0+ no carga estos métodos hasta que se utilizan para ahorrar RAM. Este es un cambio importante para las versiones antiguas de iOS porque las estructuras de datos antiguas utilizadas para indexar estas clases ya no incluyen los métodos de categoría (en la misma área de almacenamiento) y la lógica dependiente (que lee estas estructuras de datos) en el marco ya no funcionará. El método swizzling se maneja de manera diferente y esto es lo que GoogleUtilities también hace (una dependencia de GoogleMobileAds), por lo que esto puede causar problemas. Entonces, incluso si el Autocompletar IB no funciona (no es un gran problema), la clase no se encontrará dinámicamente en tiempo de ejecución. No he mencionado cambios en los cambios de representación de method list bajo el capó en el nuevo tiempo de ejecución, ya que eso está fuera del alcance de esta pregunta, pero las listas de métodos antiguos aún se podrán usar en el tiempo de ejecución ( cambio sin interrupciones < / fuerte>).

Para solucionar esto, solo use la versión 7.67.0 en su Podfile por ahora. No puede hacer nada más al respecto como usuario final del marco, ya que podspec especifica el tipo de marco como vendored_framework y esto solo es editable dentro del código fuente del marco. Intenté deshabilitar use_frameworks pero eso no se compila. Si puede editar el podspec para sus propios marcos, cambiar a un marco estático es una solución viable (con salvedades). El marco se vincula en el momento de la compilación en lugar del tiempo de carga para los marcos estáticos, por lo que debería poder ver la clase del marco en IB, pero luego debe hacer que los pods dependientes del marco también sean estáticos (más trabajo). El equivalente más fácil es simplemente degradar el pod o deshabilitar use_frameworks en el Podfile. Sin embargo, los marcos tienen un rendimiento más rápido (tiempo de vinculación) y generalmente son los preferidos, por lo que están habilitados de forma predeterminada para CocoaPods.

También habría sugerido crear un nuevo problema de GitHub para este error, pero parece que el SDK no es de código abierto. Quizás este error sea resuelto por Apple en el futuro o por Google una vez que se den cuenta, pero esto es una solución por ahora.

1
Pranav Kasetti 4 mar. 2021 a las 23:43

Intente editar el XML de su Storyboard para solucionar este problema.

  • Haga clic con el botón derecho en su guión gráfico o creador de interfaces.
  • Seleccione ver controlador o vista y vaya al panel Navegador de proyectos y seleccione la opción de menú Abrir como-> Código fuente.
  • agregue el atributo customClass = "GADUnifiedNativeAdvView"

Guarde el guión gráfico o visualice.

Vuelva a hacer clic con el botón derecho en la entrada de su guión gráfico / vista en el panel Navegador de proyectos y seleccione Abrir como-> Generador de interfaces

Con suerte, verá el nombre de la clase personalizada.

0
pkc456 1 mar. 2021 a las 17:34

1: instalación de pod: instalación limpia

2: abre Xcode y shit-command-k

3: cierre Xcode y vuelva a abrir

4: tome café y espere xcode precompilación completa

0
hasayakey 5 mar. 2021 a las 11:21