La apariencia de UIA no fue tan simple

El protocolo UIAppearance apareció en iOS 5 en 2011, en aquellos tiempos distantes en que Instagram no tenía una aplicación para Android, y el Ned Stark en serie aún no estaba cortado.


Sobre Eddard

Los maestros me enviaron un cuervo con la noticia de que en el momento del lanzamiento de iOS 5, ya habían sido cortados. Pero para no estropear la boda roja u otra cosa, tal vez dejaré todo como está.


Hay suficiente información, tutoriales, artículos sobre este tema, cada desarrollador principiante de iOS sabe cómo y por qué usarlo, por lo que este artículo no trata sobre eso. Me gustaría reflexionar sobre lo que le pasa y por qué Apple no le presta atención.


Como una pequeña introducción, extractos de la documentación , que siempre ha sido, es y debería ser la principal fuente confiable de información.


Puede personalizar la apariencia de las instancias de una clase enviando mensajes de modificación de apariencia al proxy de apariencia de la clase.

Para admitir la personalización de la apariencia, una clase debe cumplir con el protocolo UIAppearanceContainer y los métodos de acceso relevantes deben estar marcados con UI_APPEARANCE_SELECTOR

Para mí, lo entiendo de esta manera: si desea cambiar la apariencia predeterminada para todos los objetos de la clase que implementa UIAppearance , verifique si la propiedad está marcada con UI_APPEARANCE_SELECTOR , y listo. En consecuencia, si la propiedad no es UI_APPEARANCE_SELECTOR , entonces esto no funcionará.


Pero "no tiene éxito" no significa "no puede intentarlo", por lo que sugiero que todos tengan curiosidad por hacer un experimento simple: abra el primer proyecto que obtenga y agregue la siguiente línea a la application:didFinishLaunchingWithOptions: método:


 UIView.appearance().isHidden = true 

Estima lo que sucederá y corre.


Yo, como un aburrido, esperaría posibles opciones:


  • no pasa nada
  • no sucede nada, pero un registro como "isHidden no es UI_APPEARANCE_SELECTOR, estúpido" cae en la consola;
  • La aplicación detecta un error crítico o afirma con un mensaje similar.

Pero no, todo, incluida la ventana principal de la aplicación, se oculta. Por un lado, es incluso lógico: lo que está escrito está hecho. Pero, por otro lado, parece un comportamiento indocumentado y, me parece, un agujero bastante grande como ese.


Todavía podría aceptar el hecho de que si tales trucos pudieran rotarse solo con aquellas propiedades que afectan la apariencia, ¡pero esto se puede hacer con todas las propiedades !


Por ejemplo, agregando al código que otros proyectos usan como una biblioteca de terceros, aquí hay una línea que a veces se llama en un momento aleatorio en el tiempo:


 UITableView.appearance().delegate = nil 

Puede restablecer todos los delegados a todas las tablas que aparecen en la pantalla después de ejecutar este código.


¡Los desarrolladores se divertirán mucho tratando de descubrir qué pasó! ¡Seguramente, puedes encontrar algo aún más divertido!


Realmente espero que Apple no haya pasado por alto tales cosas (no encontré ninguna información sobre este tema), y tales trucos se revelan en algún lugar en la etapa de verificación automática de ensamblaje en AppstoreConnect. Pero para ser sincero, no tengo ganas de comprobarlo.


Tales cosas chicos. Estaré encantado de discutir si alguien también está interesado en el tema.


PD Devuélveme mi 2011!

Source: https://habr.com/ru/post/453126/


All Articles