quelle est la difference entre Delegate et Notification?
quelle est la difference entre Delegate et Notification?
j'ai compris comme délégué et protocole,
@protocol classADelegate
-(void)DelegateMethod;
@end
classB <classADelegate>{
classA *ObjOfclassA=[[classA alloc]init];
ObjOfclassA.delegate=self;
//while Push later, here we have taken the pointer of classB(self) to classA and stored in delegate variable of classA. so from classA we can call the function in classB
Push:classA from here.
-(void)DelegateMethod{
nslog(@"i am rithik from India");
}
}
classA{
id <classADelegate> delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
Mon doute est
1 pourquoi n'utilisons-nous pas classA comme ça
classA{
**classB** <classADelegate> delegate;
[self.delegate DelegateMethod];
}
quelle est la raison d'utiliser " id " et quelle est la différence entre eux?
2 nous avons appelé la méthode de la fonction DelegateMethod de la classeB, issue de la définition du protocole.
au lieu de cela, nous pouvons directement appeler cette méthode en définissant cette méthode d'instance de classB.parce que nous avons le pointeur pour classB dans la variable déléguée de classA.
comme ça.
classB{
-(void)DelegateMethod;
}
puis appeler cela
classA{
classB delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
donc de ce qui précède nous avons évité le protocole et la variable id .
mais je savais que beaucoup d’entre nous utilisaient délégué et protocole. ici, je suis venu pour connaître les avantages tout en utilisant délégué et protocole
ici, à quoi sert l’implémentation de protocole pour la méthode de la fonction DelegateMethod.
à la place, par exemple, définition.
quelle est l'utilisation de ceux-ci par @protocol.
s'il vous plait, si vous me guidez dans la bonne direction ...
je suis nouveau sur iphone developement.
en ce moment je savais comment créer un délégué .mais quand je suis venu étudier à propos de la NSNotification
c'est aussi faire le travail presque juste comme délégué.
alors, quand devrais-je utiliser le Delgate ou NSnotification.
Merci
Réponse courte: Vous pouvez penser aux délégués comme à un appel téléphonique. Vous appelez votre ami et vous souhaitez spécifiquement lui parler. Vous pouvez dire quelque chose et ils peuvent répondre. Vous pouvez parler jusqu'à ce que vous raccrochez. Les délégués, de la même manière, créent un lien entre deux objets, et vous n'avez pas besoin de savoir quel type sera le délégué, il doit simplement implémenter le protocole. Par ailleurs, les notifications NS sont similaires à une station de radio. Ils diffusent leur message à quiconque est prêt à écouter. La station de radio ne peut pas recevoir les commentaires de ses auditeurs (sauf si elle dispose d'un téléphone ou d'un délégué). Les auditeurs peuvent ignorer le message ou faire quelque chose avec. NSNotifications vous permet d'envoyer un message à n'importe quel objet, mais vous n'aurez pas de lien entre eux pour communiquer en arrière. Si vous avez besoin de cette communication, vous devriez probablement implémenter un délégué. Sinon, NSNotifications est plus simple et plus facile à utiliser, mais peut vous causer des ennuis.
Longue réponse:
Les délégués sont généralement un moyen plus approprié de gérer les choses, surtout si vous créez un cadre que les autres peuvent utiliser. Vous gagnez en temps de compilation en vérifiant les méthodes requises lorsque vous utilisez des protocoles avec vos délégués, de sorte que vous sachiez à quel moment compiler si vous manquez des méthodes. Avec NSNotificationCenter, vous n’avez aucune garantie de ce type.
NSNotificationCenter est sorte de "hack-ish" et est fréquemment utilisé par les programmeurs novices qui can conduisent à une architecture médiocre. Souvent, ces deux fonctionnalités sont interchangeables, mais davantage de développeurs "hardcore" risquent de se moquer de l'utilisation de NSNotificationCenter.
Q: quelle est la raison d'utiliser "id" et quelle est leur différence?
A: Utiliser id vous permet d'envoyer n'importe quel objet à la méthode en tant que paramètre. Notez que vous ne pouvez pas envoyer de primitives telles que bools, floats, doubles, ints, etc. sauf si elles sont encapsulées dans leurs enveloppes d'objet respectives.
classB{
-(void)DelegateMethod;
}
puis appeler cela
classA{
classB delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
L'exemple ci-dessus que vous avez fourni nécessiterait que le délégué de classA soit toujours du type classB, ce qui n'est pas avantageux. Au lieu d'utiliser des délégués dans ce scénario, vous utiliseriez probablement simplement une variable faisant référence à votre autre classe, par exemple myClassB. La beauté des délégués réside dans le fait que vous pouvez passer autour de n'importe quel objet et que le code fonctionne simplement tant qu'ils implémentent les méthodes requises (ce que le compilateur garantit, tant qu'il est marqué comme type de délégué correct).
Un délégué utilise des protocoles et crée une relation has-a entre les deux classes. Un des autres avantages des délégués est que vous pouvez renvoyer quelque chose à la classe propriétaire.
Les notifications, par contre, sont davantage axées sur la communication point à multipoint. Un exemple d'utilisation de NSNotification pourrait être dans une application de contrôleur de barre d'onglets, dans laquelle vous devrez peut-être informer plusieurs contrôleurs de vue d'un événement particulier afin qu'ils puissent actualiser les données, etc. ça n'aurait pas de sens s'ils le faisaient.
Maintenant, à vos autres questions:
Pourquoi utilisons-nous id?
Dans votre classe, vous voulez un handle sur un objet de type indéterminé type , mais qui implémente le protocole que vous définissez. Prenez UIWebView, par exemple. Il peut exister des types de classes infinitésimaux pouvant être délégués, par conséquent, il ne doit pas nommer un type de classe spécifique, mais spécifier que la classe doit implémenter le protocole UIWebViewDelegate. Cela réduit le couplage à un minimum absolu et crée une application très cohérente dans laquelle vous créez une interaction basée sur behavior , not state.
Alors, passons en exemple:
@protocol ClassADelegate
- (NSString*) determineValue;
@end
@interface ClassA : NSObject
{
id<ClassADelegate> delegate;
}
// Make sure you are using assign, not retain or copy
@property (nonatomic, assign) id<ClassADelegate> delegate;
@end
L'implémentation de ClassA:
import "ClassA.h"
@implementation ClassA
@synthesize delegate;
- (void) somePrivateMethod
{
if (self.delegate && [self.delegate implementsProtocol:@protocol(ClassADelegate)])
{
NSString* value = [self.delegate determineValue];
// Do other work
}
}
- (void) dealloc
{
delegate = nil;
}
@end
Dans l'en-tête, nous déclarons que la classe implémentera le protocole ClassADelegate:
#import "ClassA.h"
@interface ClassB : NSObject <ClassADelegate>
{
}
- (void) someMethod;
@end
Dans l'implémentation de ClassB, nous créons une instance de ClassA et définissons B en tant que délégué de A:
#import "ClassB.h"
@implementation ClassB
- (void) someMethod
{
ClassA* aClass = [[ClassA alloc] init];
aClass.delegate = self;
// Other work and memory clean up of A.
// Some logic occurs in A where it calls the delegate (self) which will
// call the `determineValue` method of this class.
}
// Here's the delegate method we implement
- (NSString*) determineValue
{
return @"I did some work!";
}
@end
Le délégué passe un message d'un objet à un autre. C'est comme une communication un à un alors que la notification est comme faire passer un message à plusieurs objets en même temps. Tous les autres objets qui se sont abonnés à cette notification ou des observateurs agissant pour cette notification peuvent ou ne peuvent pas répondre à cet événement. Les notifications sont plus faciles, mais vous pouvez avoir des problèmes en utilisant une architecture de mauvaise qualité. Les délégués sont plus fréquemment utilisés et sont utilisés à l'aide de protocoles.
Nous pouvons utiliser les notifications pour diverses raisons. Par exemple , vous pouvez émettre une notification pour modifier la manière dont les éléments de l'interface utilisateur affichent les informations en fonction d'un certain événement ailleurs dans le programme. Vous pouvez également utiliser les notifications pour vous assurer que les objets d'un document enregistrent leur état avant la fermeture de la fenêtre du document.
L'objectif général des notifications est d'informer les autres objets des événements du programme afin qu'ils puissent répondre de manière appropriée. Cependant, les objets recevant des notifications ne peuvent réagir que lorsque l'événement s'est produit. C'est une différence significative par rapport à la délégation.
Le délégué a la possibilité de rejeter ou de modifier l'opération proposée par l'objet délégué. L'observation d'objets, par contre, ne peut pas affecter directement une opération imminente.
Nous pouvons simplement dire,
Délégués:
Un par un
Notification:
Un à plusieurs
Déclarer délégué
@protocol DelegateName
@required
- (void)method:(NSString *)param;
@optional
- (void)methodOptional:(NSString *)param;
@end
Et déclarer une propriété pour Protocol
@property id <DelegateName> delegate;
Vous pouvez utiliser
myObject.delegate = <# some object conforming to DelegateName #>;
NSNotification declaration
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(notificationHappened:)
name:MyCustomNotificationName
object:nil];
Puis mettre en œuvre
- (void)notificationHappened:(NSNotification *)notification {
// do work here
}
Vous pouvez poster une notification de n'importe où en utilisant,
[[NSNotificationCenter defaultCenter] postNotificationName:MyCustomNotificationName
object:self
userInfo:nil];
appelez removeObserver: lorsque vous avez terminé.