Quelle est la manière la plus robuste de forcer un UIView à se redessiner?

J'ai un UITableView avec une liste d'articles. La sélection d'un élément pousse un viewController qui procède ensuite aux opérations suivantes. from method viewDidLoad Je déclenche une URLRequest pour les données requises par l'une de mes sous-vues - une sous-classe UIView avec drawRect remplacé. Lorsque les données arrivent du cloud, je commence à construire ma hiérarchie de vues. la sous-classe en question reçoit les données et sa méthode drawRect a maintenant tout ce dont elle a besoin pour le rendu.

Mais.

Parce que je n'appelle pas drawRect explicitement - Cocoa-Touch gère cela - je n'ai aucun moyen d'informer Cocoa-Touch que je veux vraiment, vraiment que cette sous-classe UIView soit rendue. Quand? Ce serait bien maintenant!

J'ai essayé [myView setNeedsDisplay]. Cela fonctionne un peu parfois. Très irrégulier.

Je lutte avec ça depuis des heures et des heures. Quelqu'un pourrait-il s'il vous plaît me fournir une approche solide et garantie pour forcer un nouveau rendu UIView.

Voici l'extrait de code qui fournit des données à la vue:

// 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];

Salut, Doug

Le moyen sûr et solide de forcer un UIViewà refaire le rendu est [myView setNeedsDisplay]. Si vous rencontrez des problèmes avec cela, vous rencontrez probablement l'un de ces problèmes:

• Vous l'appelez avant d'avoir réellement les données, ou vous mettez -drawRect:quelque chose en cache.

• Vous vous attendez à ce que la vue se dessine au moment où vous appelez cette méthode. Il n'y a intentionnellement aucun moyen d'exiger «dessiner maintenant cette seconde» en utilisant le système de dessin Cocoa. Cela perturberait l'ensemble du système de composition de vues, détruirait les performances et créerait probablement toutes sortes d'artefacts. Il n'y a que des moyens de dire "cela doit être dessiné lors du prochain cycle de tirage".

Si ce dont vous avez besoin est "un peu de logique, dessiner, un peu plus de logique", alors vous devez mettre le "un peu plus de logique" dans une méthode séparée et l'invoquer -performSelector:withObject:afterDelay:avec un délai de 0. Cela mettra "un peu plus de logique" après le prochain cycle de tirage. Voir cette question pour un exemple de ce type de code et un cas où cela pourrait être nécessaire (bien qu'il soit généralement préférable de rechercher d'autres solutions si possible car cela complique le code).

Si vous ne pensez pas que les choses se dessinent, mettez un point d'arrêt -drawRect:et voyez quand vous êtes appelé. Si vous appelez -setNeedsDisplay, mais que vous n'êtes -drawRect:pas appelé dans la boucle d'événements suivante, fouillez dans votre hiérarchie de vues et assurez-vous que vous n'essayez pas de déjouer quelque part. L'excès d'intelligence est la première cause de mauvais dessin selon mon expérience. Lorsque vous pensez savoir comment tromper le système pour qu'il fasse ce que vous voulez, vous le faites généralement faire exactement ce que vous ne voulez pas.

J'ai eu un problème avec un grand délai entre l'appel de setNeedsDisplay et drawRect: (5 secondes). Il s'est avéré que j'ai appelé setNeedsDisplay dans un thread différent du thread principal. Après avoir déplacé cet appel vers le thread principal, le délai a disparu.

J'espère que cela aidera.

La manière garantie de remboursement, en béton armé solide pour forcer une vue à dessiner de manière synchrone (avant de revenir au code appelant) est de configurer les CALayerinteractions de la avec votre UIViewsous - classe.

Dans votre sous-classe UIView, créez une displayNow()méthode qui indique au calque de « définir le cap pour l'affichage » puis de « faire en sorte »:

_Rapide

/// 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()
}

_{Objectif c}

/// 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];
}

Implémentez également une draw(_: CALayer, in: CGContext)méthode qui appellera votre méthode de dessin privée / interne (qui fonctionne puisque tout UIViewest a CALayerDelegate) :

_Rapide

/// 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()
}

_{Objectif c}

/// 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();
}

Et créez votre internalDraw(_: CGRect)méthode personnalisée , avec une sécurité intégrée draw(_: CGRect):

_Rapide

/// 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)
}

_{Objectif c}

/// 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];
}

Et maintenant, il suffit d'appeler myView.displayNow()chaque fois que vous en avez vraiment besoin pour dessiner (par exemple à partir d'un CADisplayLinkrappel) . Notre displayNow()méthode indiquera CALayerà displayIfNeeded(), qui rappellera de manière synchrone notre draw(_:,in:)et effectuera le dessin internalDraw(_:), mettant à jour le visuel avec ce qui est dessiné dans le contexte avant de continuer.

Cette approche est similaire à celle de @ RobNapier ci-dessus, mais présente l'avantage d'appeler displayIfNeeded()en plus de setNeedsDisplay(), ce qui la rend synchrone.

Cela est possible parce que CALayers exposent plus de fonctionnalités de dessin que ne le font UIView- les couches sont de niveau inférieur aux vues et conçues explicitement dans le but de dessiner hautement configurable dans la mise en page et (comme beaucoup de choses dans Cocoa) sont conçues pour être utilisées de manière flexible ( en tant que classe parente, ou en tant que délégant, ou en tant que pont vers d'autres systèmes de dessin, ou simplement seuls). Une bonne utilisation du CALayerDelegateprotocole rend tout cela possible.

Pour plus d'informations sur la configurabilité de CALayers, reportez-vous à la section Configuration des objets de couche du Guide de programmation de l'animation de base .

J'ai eu le même problème et toutes les solutions de SO ou de Google ne fonctionnaient pas pour moi. Habituellement, setNeedsDisplaycela fonctionne, mais quand ce n'est pas le cas ...
J'ai essayé d'appeler setNeedsDisplayla vue de toutes les manières possibles à partir de tous les threads et trucs possibles - toujours sans succès. Nous savons, comme Rob l'a dit, que

"cela doit être dessiné dans le prochain cycle de tirage."

Mais pour une raison quelconque, il ne dessinerait pas cette fois. Et la seule solution que j'ai trouvée est de l'appeler manuellement après un certain temps, pour laisser passer tout ce qui bloque le tirage au sort, comme ceci:

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];
});

C'est une bonne solution si vous n'avez pas besoin que la vue soit redessinée très souvent. Sinon, si vous faites des choses en mouvement (action), il n'y a généralement aucun problème avec le simple appel setNeedsDisplay.

J'espère que cela aidera quelqu'un qui est perdu là-bas, comme moi.

Eh bien, je sais que cela pourrait être un grand changement ou même pas adapté à votre projet, mais avez-vous envisagé de ne pas effectuer le push tant que vous n'avez pas déjà les données ? De cette façon, vous n'avez besoin de dessiner la vue qu'une seule fois et l'expérience utilisateur sera également meilleure - le push se déplacera déjà chargé.

La façon dont vous faites cela consiste à UITableView didSelectRowAtIndexPathdemander les données de manière asynchrone. Une fois que vous recevez la réponse, vous effectuez manuellement la transition et transmettez les données à votre viewController dans prepareForSegue. En attendant, vous voudrez peut-être afficher un indicateur d'activité, pour un simple indicateur de chargement, vérifiez https://github.com/jdg/MBProgressHUD