Mal entendiendo procesos asincrónicos
Esto es muy común cuando se reciben datos de una API del lado del servidor. Por lo general, verá el método de visualización para mostrar los datos colocados justo después de la llamada asincrónica. No funcionará: la llamada asíncrona tardará más en completarse, y cuando lo haga, el método de vista ya ha sido llamado. Los bloques de finalización y los cierres rápidos hoy en día hacen que sea más fácil evitar este tipo de error, pero aún veo mucha confusión por parte de los programadores junior.
Operaciones de IU en un subproceso diferente de la cola principal
- ¿Cómo podría aprender a desarrollar aplicaciones iOS en una Macbook 2007?
- ¿Cuál sostendrá más tiempo, Android o iOS?
- ¿Está disponible Scrivener para iOS?
- ¿Cuál es el significado de poder agregar reconocedores de gestos directamente a una UIView donde el mecanismo de acción del objetivo se define en UIControl?
- Como el iPad Air 2 tiene 2GB de RAM, ¿todos los iPhone6 / 6 + estarán desactualizados solo un año después de su presentación?
UIKit no es seguro para subprocesos. Algunos programadores no lo saben. Pero incluso cuando lo saben, es muy común que pierdan la noción de en qué hilo están operando, especialmente cuando hacen llamadas asincrónicas. Terminan realizando operaciones de IU en diferentes subprocesos, lo que conduce a un comportamiento inesperado.
Controladores de vista masiva
Por lo general, incluirán la mayor parte de la lógica empresarial en el Controlador y tendrán Modelos y Vistas muy delgados. Este es un gran error arquitectónico que solo empeora a medida que el proyecto evoluciona.
Los modelos no solo están ahí para representar el estado, sino también para tener lógica. Una lógica que en realidad se puede reutilizar en muchos Controladores diferentes cuando se opera con esos modelos.
Las vistas también deben tener una lógica relacionada con la vista definida en sí mismas y no manejada por el controlador. Un ejemplo típico de lo que no se debe hacer son UITableViewCells personalizadas, donde verá docenas de líneas de código para configurar la celda … en el Controlador.
Reutilización incorrecta de UITableViewCell y UICollectionViewCell
La mayoría de las veces, estos objetos se reutilizan al desplazarse: significa no crear nuevos, sino reutilizar los ya asignados en la memoria y configurarlos para mostrar los datos adecuados. Los nuevos desarrolladores a menudo no obtienen esta parte de reutilización correctamente. Muchas veces las personas se olvidan de, por ejemplo, limpiar algunas variables cuando no hay datos para ellas, lo que hace que algunas celdas muestren información incorrecta.
Comparación de objetos en Objective-C
Este es un error muy frecuente al comparar objetos (principalmente ocurre con NSStrinf y NSDate) usando el operador ==. Lo que está haciendo este operador es la comparación de punteros: comparar la dirección de memoria de los dos objetos. No está haciendo una comparación semántica: comparar si dos cadenas tienen los mismos caracteres. Para la comparación semántica, isEqual se implementa en la clase NSString.
Introducir ciclos de retención
Hay dos escenarios comunes donde esto sucede:
- Delegados Por lo general, sucederá que un ParentViewController esté configurado como delegado de su ChildViewController. Al definir el delegado en ChildViewController, la mayoría lo configurará como fuerte, lo que provocará ciclos de retención porque ahora ambos controladores se retienen entre sí.
- Bloques / Cierres: Asignar un bloque como una propiedad en la clase y también hacer que este bloque llame a la clase por sí mismo. La solución típica es referirse a una referencia débil de uno mismo dentro del código de bloque.
Solo pruebas en el simulador
Es una práctica realmente mala pensar que porque funciona en el simulador, ya está hecho. Muchas cosas diferentes pueden variar en el comportamiento del simulador al dispositivo. Pasa del código roto debido a diferentes arcos de memoria (32 frente a 64) a problemas de rendimiento (el simulador es mucho más rápido que un dispositivo real).
