¿Cuál es la forma más sólida de forzar a que una UIView se vuelva a dibujar?

Tengo un UITableView con una lista de elementos. Seleccionar un elemento empuja un viewController que luego procede a hacer lo siguiente. desde el método viewDidLoad, disparo una URLRequest para los datos que requiere una de mis subvistas: una subclase UIView con drawRect anulado. Cuando los datos llegan de la nube, empiezo a construir mi jerarquía de vistas. la subclase en cuestión recibe los datos y su método drawRect ahora tiene todo lo que necesita para renderizar.

Pero.

Debido a que no llamo a drawRect explícitamente, Cocoa-Touch se encarga de eso, no tengo forma de informar a Cocoa-Touch que realmente quiero que se procese esta subclase de UIView. ¿Cuando? ¡Ahora estaría bien!

He probado [myView setNeedsDisplay]. Esto funciona a veces. Muy irregular.

He estado luchando con esto durante horas y horas. ¿Podría alguien que me brinde un enfoque sólido y garantizado para forzar una re-renderización de UIView?

Este es el fragmento de código que envía datos a la vista:

// Create the subview
self.chromosomeBlockView = [[[ChromosomeBlockView alloc] initWithFrame:frame] autorelease];

// Set some properties
self.chromosomeBlockView.sequenceString     = self.sequenceString;
self.chromosomeBlockView.nucleotideBases    = self.nucleotideLettersDictionary;

// Insert the view in the view hierarchy
[self.containerView          addSubview:self.chromosomeBlockView];
[self.containerView bringSubviewToFront:self.chromosomeBlockView];

// A vain attempt to convince Cocoa-Touch that this view is worthy of being displayed ;-)
[self.chromosomeBlockView setNeedsDisplay];

Saludos, Doug

La forma garantizada y sólida como una roca de forzar a un UIViewrenderizado es [myView setNeedsDisplay]. Si tiene problemas con eso, es probable que se encuentre con uno de estos problemas:

• Lo está llamando antes de tener los datos, o -drawRect:está sobrecargando algo.

• Espera que la vista se dibuje en el momento en que llama a este método. No hay forma intencional de exigir "dibujar ahora mismo en este mismo segundo" utilizando el sistema de dibujo Cocoa. Eso interrumpiría todo el sistema de composición de vistas, arruinaría el rendimiento y probablemente crearía todo tipo de artefactos. Solo hay formas de decir "esto debe dibujarse en el próximo ciclo de sorteo".

Si lo que necesita es "algo de lógica, dibujo, algo más de lógica", entonces debe poner "algo más de lógica" en un método separado e invocarlo -performSelector:withObject:afterDelay:con un retraso de 0. Eso pondrá "algo más de lógica" después el próximo ciclo de sorteo. Consulte esta pregunta para ver un ejemplo de ese tipo de código y un caso en el que podría ser necesario (aunque generalmente es mejor buscar otras soluciones si es posible, ya que complica el código).

Si cree que las cosas no se están dibujando, coloque un punto de interrupción -drawRect:y vea cuándo lo llaman. Si está llamando -setNeedsDisplay, pero -drawRect:no recibe la llamada en el siguiente ciclo de eventos, busque en la jerarquía de su vista y asegúrese de que no está tratando de ser más astuto que en alguna parte. En mi experiencia, el exceso de inteligencia es la causa número uno de los malos dibujos. Cuando cree que sabe mejor cómo engañar al sistema para que haga lo que quiere, normalmente consigue que haga exactamente lo que no quiere.

Tuve un problema con un gran retraso entre llamar a setNeedsDisplay y drawRect: (5 segundos). Resultó que llamé setNeedsDisplay en un hilo diferente al hilo principal. Después de mover esta llamada al hilo principal, el retraso desapareció.

Espero que esto sea de alguna ayuda.

La forma de devolución de dinero garantizada, de hormigón armado y sólido de forzar a que una vista se dibuje sincrónicamente (antes de volver al código de llamada) es configurar las CALayerinteracciones de the con su UIViewsubclase.

En su subclase UIView, cree un displayNow()método que le diga a la capa que " establezca el rumbo para la visualización " y luego "lo haga así ":

_Rápido

/// Redraws the view's contents immediately.
/// Serves the same purpose as the display method in GLKView.
public func displayNow()
{
    let layer = self.layer
    layer.setNeedsDisplay()
    layer.displayIfNeeded()
}

_{C objetivo}

/// Redraws the view's contents immediately.
/// Serves the same purpose as the display method in GLKView.
- (void)displayNow
{
    CALayer *layer = self.layer;
    [layer setNeedsDisplay];
    [layer displayIfNeeded];
}

También implemente un draw(_: CALayer, in: CGContext)método que llamará a su método de dibujo privado / interno (que funciona ya que cada UIViewes a CALayerDelegate) :

_Rápido

/// Called by our CALayer when it wants us to draw
///     (in compliance with the CALayerDelegate protocol).
override func draw(_ layer: CALayer, in context: CGContext)
{
    UIGraphicsPushContext(context)
    internalDraw(self.bounds)
    UIGraphicsPopContext()
}

_{C objetivo}

/// Called by our CALayer when it wants us to draw
///     (in compliance with the CALayerDelegate protocol).
- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)context
{
    UIGraphicsPushContext(context);
    [self internalDrawWithRect:self.bounds];
    UIGraphicsPopContext();
}

Y cree su internalDraw(_: CGRect)método personalizado , junto con a prueba de fallas draw(_: CGRect):

_Rápido

/// Internal drawing method; naming's up to you.
func internalDraw(_ rect: CGRect)
{
    // @FILLIN: Custom drawing code goes here.
    //  (Use `UIGraphicsGetCurrentContext()` where necessary.)
}

/// For compatibility, if something besides our display method asks for draw.
override func draw(_ rect: CGRect) {
    internalDraw(rect)
}

_{C objetivo}

/// Internal drawing method; naming's up to you.
- (void)internalDrawWithRect:(CGRect)rect
{
    // @FILLIN: Custom drawing code goes here.
    //  (Use `UIGraphicsGetCurrentContext()` where necessary.)
}

/// For compatibility, if something besides our display method asks for draw.
- (void)drawRect:(CGRect)rect {
    [self internalDrawWithRect:rect];
}

Y ahora solo llame myView.displayNow()cuando realmente lo necesite para dibujar (como desde una CADisplayLinkdevolución de llamada) . Nuestro displayNow()método le dirá CALayera displayIfNeeded(), que llamará de forma sincrónica a nuestro draw(_:,in:)y hará el dibujo internalDraw(_:), actualizando lo visual con lo que se dibuja en el contexto antes de continuar.

Este enfoque es similar al de @ RobNapier anterior, pero tiene la ventaja de llamar displayIfNeeded()además de setNeedsDisplay(), lo que lo hace sincrónico.

Esto es posible porque los CALayers exponen más funciones de dibujo que los UIViews: las capas tienen un nivel más bajo que las vistas y están diseñadas explícitamente con el propósito de un dibujo altamente configurable dentro del diseño y (como muchas cosas en Cocoa) están diseñadas para usarse de manera flexible ( como clase principal, o como delegador, o como puente a otros sistemas de dibujo, o simplemente por sí mismos). El uso adecuado del CALayerDelegateprotocolo hace que todo esto sea posible.

CALayerPuede encontrar más información sobre la capacidad de configuración de s en la sección Configuración de objetos de capa de la Guía de programación de animación principal .

Tuve el mismo problema y todas las soluciones de SO o Google no funcionaron para mí. Por lo general, setNeedsDisplayfunciona, pero cuando no ...
Intenté llamar setNeedsDisplaya la vista de todas las formas posibles desde todos los hilos posibles y todo eso, pero todavía no tuve éxito. Sabemos, como dijo Rob, que

"esto debe dibujarse en el próximo ciclo de sorteo".

Pero por alguna razón no dibujaría esta vez. Y la única solución que he encontrado es llamarlo manualmente después de un tiempo, para dejar que todo lo que bloquee el sorteo pase, así:

dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, 
                                        (int64_t)(0.005 * NSEC_PER_SEC));
dispatch_after(popTime, dispatch_get_main_queue(), ^(void) {
    [viewToRefresh setNeedsDisplay];
});

Es una buena solución si no necesita que la vista vuelva a dibujar con mucha frecuencia. De lo contrario, si está haciendo algo en movimiento (acción), generalmente no hay problemas con solo llamar setNeedsDisplay.

Espero que ayude a alguien que está perdido allí, como yo.

Bueno, sé que esto podría ser un gran cambio o incluso no ser adecuado para su proyecto, pero ¿consideró no realizar el empuje hasta que ya tenga los datos ? De esa manera, solo necesita dibujar la vista una vez y la experiencia del usuario también será mejor: el empuje se moverá ya cargado.

La forma en que lo hace es en la UITableView didSelectRowAtIndexPathque solicita los datos de forma asincrónica. Una vez que recibe la respuesta, realiza manualmente la transición y pasa los datos a su viewController en formato prepareForSegue. Mientras tanto, es posible que desee mostrar algún indicador de actividad, para verificar el indicador de carga simple https://github.com/jdg/MBProgressHUD