デリゲートがどのように機能するかを知っており、それらをどのように使用できるかを知っています。
しかし、どうすればそれらを作成できますか?
デリゲートがどのように機能するかを知っており、それらをどのように使用できるかを知っています。
しかし、どうすればそれらを作成できますか?
delegate
Objective-C デリゲートは、別のオブジェクトのプロパティに割り当てられたオブジェクトです。これを作成するには、目的のデリゲート メソッドを実装するクラスを定義し、そのクラスをデリゲート プロトコルの実装としてマークします。
たとえば、UIWebView
. デリゲートのメソッドを実装したい場合は、次のwebViewDidStartLoad:
ようなクラスを作成できます。
@interface MyClass<UIWebViewDelegate>
// ...
@end
@implementation MyClass
- (void)webViewDidStartLoad:(UIWebView *)webView {
// ...
}
@end
次に、MyClass のインスタンスを作成し、それを Web ビューのデリゲートとして割り当てることができます。
MyClass *instanceOfMyClass = [[MyClass alloc] init];
myWebView.delegate = instanceOfMyClass;
側ではUIWebView
、おそらくこれに似たコードをwebViewDidStartLoad:
使用して、デリゲートがメッセージに応答するかどうかを確認し、必要に応じてrespondsToSelector:
送信します。
if([self.delegate respondsToSelector:@selector(webViewDidStartLoad:)]) {
[self.delegate webViewDidStartLoad:self];
}
オブジェクトのデリゲートはそのオブジェクトへの強い参照を保持することが多いため、保持ループを回避するために、通常、デリゲート プロパティ自体がweak
(ARC で) または(ARC より前に) 宣言されます。assign
(たとえば、View Controller は、多くの場合、含まれるビューのデリゲートです。)
独自のデリゲートを定義するには、プロトコルに関する Apple ドキュメントで説明されているように、メソッドをどこかで宣言する必要があります。通常、正式なプロトコルを宣言します。UIWebView.h から言い換えると、宣言は次のようになります。
@protocol UIWebViewDelegate <NSObject>
@optional
- (void)webViewDidStartLoad:(UIWebView *)webView;
// ... other methods here
@end
この場合、デリゲートの特別な型を作成するため、これはインターフェイスまたは抽象基本クラスに似ていますUIWebViewDelegate
。デリゲートの実装者は、このプロトコルを採用する必要があります。
@interface MyClass <UIWebViewDelegate>
// ...
@end
そして、プロトコルにメソッドを実装します。(ほとんどのデリゲート メソッドと同様に)プロトコルで宣言されているメソッドについては、特定のメソッドを呼び出す前@optional
に確認する必要があります。-respondsToSelector:
デリゲート メソッドは、通常、デリゲート クラス名で始まる名前が付けられ、デリゲート オブジェクトを最初のパラメーターとして受け取ります。また、しばしば will-、should-、または did- フォームを使用します。したがって、たとえば (パラメーターを使用しないwebViewDidStartLoad:
) ではなく (最初のパラメーターは Web ビューです) loadStarted
。
メッセージを送信するたびにデリゲートがセレクターに応答するかどうかを確認する代わりに、デリゲートが設定されているときにその情報をキャッシュできます。これを行う非常にクリーンな方法の 1 つは、次のようにビットフィールドを使用することです。
@protocol SomethingDelegate <NSObject>
@optional
- (void)something:(id)something didFinishLoadingItem:(id)item;
- (void)something:(id)something didFailWithError:(NSError *)error;
@end
@interface Something : NSObject
@property (nonatomic, weak) id <SomethingDelegate> delegate;
@end
@implementation Something {
struct {
unsigned int didFinishLoadingItem:1;
unsigned int didFailWithError:1;
} delegateRespondsTo;
}
@synthesize delegate;
- (void)setDelegate:(id <SomethingDelegate>)aDelegate {
if (delegate != aDelegate) {
delegate = aDelegate;
delegateRespondsTo.didFinishLoadingItem = [delegate respondsToSelector:@selector(something:didFinishLoadingItem:)];
delegateRespondsTo.didFailWithError = [delegate respondsToSelector:@selector(something:didFailWithError:)];
}
}
@end
次に、本体で、デリゲートがメッセージを何度delegateRespondsTo
も送信するのではなく、構造体にアクセスすることによって処理することを確認できます-respondsToSelector:
。
プロトコルが存在する前は、デリゲートが実装できるメソッドを宣言するためにカテゴリを使用するのが一般的でした。NSObject
たとえば、CALayer
まだこれを行います:
@interface NSObject(CALayerDelegate)
- (void)displayLayer:(CALayer *)layer;
// ... other methods here
@end
これにより、任意のオブジェクトが を実装する可能性があることがコンパイラに伝えられますdisplayLayer:
。
次に、上記と同じ-respondsToSelector:
方法でこのメソッドを呼び出します。デリゲートはこのメソッドを実装し、delegate
プロパティを割り当てます。それだけです (プロトコルに準拠していることを宣言する必要はありません)。この方法は Apple のライブラリでは一般的ですが、新しいコードでは上記のより最新のプロトコル アプローチを使用する必要があります。これは、このアプローチが汚染NSObject
され (オートコンプリートの有用性が低下し)、コンパイラがタイプミスや同様のエラーについて警告するのが難しくなるためです。
承認された回答は素晴らしいですが、1 分間の回答を探している場合は、これを試してください。
MyClass.h ファイルは次のようになります (コメント付きのデリゲート行を追加してください!)
#import <BlaClass/BlaClass.h>
@class MyClass; //define class, so protocol can see MyClass
@protocol MyClassDelegate <NSObject> //define delegate protocol
- (void) myClassDelegateMethod: (MyClass *) sender; //define delegate method to be implemented within another class
@end //end protocol
@interface MyClass : NSObject {
}
@property (nonatomic, weak) id <MyClassDelegate> delegate; //define MyClassDelegate as delegate
@end
MyClass.m ファイルは次のようになります。
#import "MyClass.h"
@implementation MyClass
@synthesize delegate; //synthesise MyClassDelegate delegate
- (void) myMethodToDoStuff {
[self.delegate myClassDelegateMethod:self]; //this will call the method implemented in your other class
}
@end
別のクラス (この場合は MyVC と呼ばれる UIViewController) MyVC.h でデリゲートを使用するには:
#import "MyClass.h"
@interface MyVC:UIViewController <MyClassDelegate> { //make it a delegate for MyClassDelegate
}
MyVC.m:
myClass.delegate = self; //set its delegate to self somewhere
デリゲート メソッドを実装する
- (void) myClassDelegateMethod: (MyClass *) sender {
NSLog(@"Delegates are great!");
}
正式なプロトコル メソッドを使用してデリゲート サポートを作成する場合、次のようなものを追加することで、適切な型チェック (コンパイル時ではなく実行時) を確実に実行できることがわかりました。
if (![delegate conformsToProtocol:@protocol(MyDelegate)]) {
[NSException raise:@"MyDelegate Exception"
format:@"Parameter does not conform to MyDelegate protocol at line %d", (int)__LINE__];
}
デリゲート アクセサー (setDelegate) コードで。これにより、ミスを最小限に抑えることができます。
たぶん、これはあなたが欠けているものに沿ったものです:
C++ のような観点から来ている場合、デリゲートは少し慣れる必要がありますが、基本的には「機能する」だけです。
それが機能する方法は、作成したオブジェクトをデリゲートとして NSWindow に設定することですが、オブジェクトには、可能な多くのデリゲート メソッドのうちの 1 つまたはいくつかの実装 (メソッド) しかありません。何かが起こり、NSWindow
あなたのオブジェクトを呼び出したい - オブジェクトがそのメソッドを呼び出したいかどうかを判断するためにObjective-cのrespondsToSelector
メソッドを使用し、それを呼び出します。これが Objective-C の仕組みです。メソッドはオンデマンドで検索されます。
独自のオブジェクトでこれを行うのはまったく簡単です。特別なことは何もありません。たとえばNSArray
、27 個のオブジェクトのうち、すべての異なる種類のオブジェクトを使用できます。そのうちの 18 個だけがメソッドを持って-(void)setToBue;
います。残りの 9 個は持っていません。必要な 18 人全員を呼び出すsetToBlue
には、次のようにします。
for (id anObject in myArray)
{
if ([anObject respondsToSelector:@selector(@"setToBlue")])
[anObject setToBlue];
}
デリゲートに関するもう 1 つの点は、それらが保持されないことです。そのため、常にメソッドでデリゲートを設定する必要がありnil
ますMyClass dealloc
。
お願いします!デリゲートが iOS でどのように機能するかを理解するには、以下の簡単なステップバイステップのチュートリアルを確認してください。
2 つの ViewController を作成しました (あるデータから別のデータを送信するため)。
デリゲートを理解すれば、これらすべての答えは非常に理にかなっていると思います。個人的に、私は C/C++ の土地から来て、その前は Fortran などの手続き型言語だったので、C++ パラダイムで同様の類似物を見つけるための私の 2 分間の考察を次に示します。
C++/Java プログラマーにデリゲートについて説明する場合、私はこう言います。
デリゲートとは これらは、別のクラス内のクラスへの静的ポインターです。ポインターを割り当てたら、そのクラスの関数/メソッドを呼び出すことができます。したがって、クラスの一部の関数は別のクラスに「委譲」されます (C++ の世界では、クラス オブジェクト ポインターによるポインター)。
プロトコルとは?概念的には、デリゲート クラスとして割り当てるクラスのヘッダー ファイルと同様の目的を果たします。プロトコルは、ポインタがクラス内でデリゲートとして設定されたクラスに実装する必要があるメソッドを定義する明示的な方法です。
C++で同様のことを行うにはどうすればよいですか? C++ でこれを行おうとすると、クラス定義でクラス (オブジェクト) へのポインターを定義し、それらを他のクラスに結び付けて、基本クラスへのデリゲートとして追加の関数を提供します。しかし、この配線はコード内で維持する必要があり、扱いにくく、エラーが発生しやすくなります。Objective C は、プログラマーがこの規定を維持するのが得意ではないことを前提としており、クリーンな実装を強制するためにコンパイラーの制限を提供しています。
デリゲートは、別のクラスのために何らかの作業を行う単なるクラスです。これが Swift でどのように行われるかを示すややばかげた (しかし、うまくいけば啓発的な) Playground の例については、次のコードを読んでください。
// A protocol is just a list of methods (and/or properties) that must
// be used by any class that adopts the protocol.
protocol OlderSiblingDelegate: class {
// This protocol only defines one required method
func getYourNiceOlderSiblingAGlassOfWater() -> String
}
class BossyBigBrother {
// The delegate is the BossyBigBrother's slave. This position can
// be assigned later to whoever is available (and conforms to the
// protocol).
weak var delegate: OlderSiblingDelegate?
func tellSomebodyToGetMeSomeWater() -> String? {
// The delegate is optional because there might not be anyone
// nearby to boss around.
return delegate?.getYourNiceOlderSiblingAGlassOfWater()
}
}
// PoorLittleSister conforms to the OlderSiblingDelegate protocol
class PoorLittleSister: OlderSiblingDelegate {
// This method is repquired by the protocol, but the protocol said
// nothing about how it needs to be implemented.
func getYourNiceOlderSiblingAGlassOfWater() -> String {
return "Go get it yourself!"
}
}
// initialize the classes
let bigBro = BossyBigBrother()
let lilSis = PoorLittleSister()
// Set the delegate
// bigBro could boss around anyone who conforms to the
// OlderSiblingDelegate protocol, but since lilSis is here,
// she is the unlucky choice.
bigBro.delegate = lilSis
// Because the delegate is set, there is a class to do bigBro's work for him.
// bigBro tells lilSis to get him some water.
if let replyFromLilSis = bigBro.tellSomebodyToGetMeSomeWater() {
print(replyFromLilSis) // "Go get it yourself!"
}
実際には、デリゲートは次のような状況でよく使用されます。
デリゲート クラスが必要なプロトコルに準拠していることを除いて、クラスは事前にお互いについて何も知る必要はありません。
以下の 2 つの記事を読むことを強くお勧めします。それらは、ドキュメントよりもデリゲートをよりよく理解するのに役立ちました。
わかりました、これは実際には質問に対する答えではありませんが、独自のデリゲートを作成する方法を探している場合は、はるかに単純なものがより良い答えになる可能性があります.
デリゲートはめったに必要ないため、ほとんど実装していません。デリゲート オブジェクトに対して 1 つのデリゲートのみを持つことができます。したがって、一方向の通信/データの受け渡しのためにデリゲートが必要な場合は、通知を使用するよりもはるかに優れています。
NSNotification は複数の受信者にオブジェクトを渡すことができ、非常に使いやすいです。それはこのように動作します:
MyClass.m ファイルは次のようになります。
#import "MyClass.h"
@implementation MyClass
- (void) myMethodToDoStuff {
//this will post a notification with myClassData (NSArray in this case) in its userInfo dict and self as an object
[[NSNotificationCenter defaultCenter] postNotificationName:@"myClassUpdatedData"
object:self
userInfo:[NSDictionary dictionaryWithObject:selectedLocation[@"myClassData"] forKey:@"myClassData"]];
}
@end
通知を別のクラスで使用するには: クラスをオブザーバーとして追加します。
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(otherClassUpdatedItsData:) name:@"myClassUpdatedData" object:nil];
セレクターを実装します。
- (void) otherClassUpdatedItsData:(NSNotification *)note {
NSLog(@"*** Other class updated its data ***");
MyClass *otherClass = [note object]; //the object itself, you can call back any selector if you want
NSArray *otherClassData = [note userInfo][@"myClassData"]; //get myClass data object and do whatever you want with it
}
オブザーバーとしてクラスを削除することを忘れないでください
- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
}
開発したクラスがあり、何らかのイベントが発生したときに通知できるようにデリゲート プロパティを宣言するとします。
@class myClass;
@protocol myClassDelegate <NSObject>
-(void)myClass:(MyClass*)myObject requiredEventHandlerWithParameter:(ParamType*)param;
@optional
-(void)myClass:(MyClass*)myObject optionalEventHandlerWithParameter:(ParamType*)param;
@end
@interface MyClass : NSObject
@property(nonatomic,weak)id< MyClassDelegate> delegate;
@end
MyClass
したがって、ヘッダー ファイル (または別のヘッダー ファイル) でプロトコルを宣言し、デリゲートが実装する必要がある/実装する必要がある必須/オプションのイベント ハンドラーを宣言し、 MyClass
( id< MyClassDelegate>
) 型のプロパティを宣言します。これは、準拠する目的の c クラスを意味します。 protocol MyClassDelegate
、デリゲート プロパティが weak として宣言されていることに気付くでしょう。これは保持サイクルを防ぐために非常に重要です (ほとんどの場合、デリゲートはMyClass
インスタンスを保持するため、デリゲートを保持として宣言すると、両方が互いに保持され、どちらも保持されません)それらのいずれかがリリースされます)。
また、プロトコル メソッドがインスタンスをパラメーターとしてデリゲートに渡すことにも気付くでしょうMyClass
。これは、デリゲートがインスタンスでいくつかのメソッドを呼び出したい場合のベスト プラクティスであり、複数のインスタンスがある場合のように、デリゲートが複数のインスタンスに対してMyClass
自身を宣言する場合にも役立ちます。インスタンスは、それらすべてに対してとして宣言されます。MyClassDelegate
MyClass
UITableView's
ViewController
UITableViewDelegate
そしてあなたの内部MyClass
では、次のように宣言されたイベントでデリゲートに通知します:
if([_delegate respondsToSelector:@selector(myClass: requiredEventHandlerWithParameter:)])
{
[_delegate myClass:self requiredEventHandlerWithParameter:(ParamType*)param];
}
デリゲートがそれを実装せず、アプリがクラッシュする場合に備えて、呼び出しようとしているプロトコル メソッドにデリゲートが応答するかどうかを最初に確認します (プロトコル メソッドが必要な場合でも)。
独自のデリゲートを作成するには、まずプロトコルを作成し、実装せずに必要なメソッドを宣言する必要があります。次に、デリゲートまたはデリゲート メソッドを実装するヘッダー クラスにこのプロトコルを実装します。
プロトコルは次のように宣言する必要があります。
@protocol ServiceResponceDelegate <NSObject>
- (void) serviceDidFailWithRequestType:(NSString*)error;
- (void) serviceDidFinishedSucessfully:(NSString*)success;
@end
これは、何らかのタスクを実行する必要があるサービス クラスです。デリゲートの定義方法とデリゲートの設定方法を示します。タスクが完了した後の実装クラスでは、デリゲートのメソッドが呼び出されます。
@interface ServiceClass : NSObject
{
id <ServiceResponceDelegate> _delegate;
}
- (void) setDelegate:(id)delegate;
- (void) someTask;
@end
@implementation ServiceClass
- (void) setDelegate:(id)delegate
{
_delegate = delegate;
}
- (void) someTask
{
/*
perform task
*/
if (!success)
{
[_delegate serviceDidFailWithRequestType:@”task failed”];
}
else
{
[_delegate serviceDidFinishedSucessfully:@”task success”];
}
}
@end
これは、デリゲートをそれ自体に設定することによってサービス クラスが呼び出されるメイン ビュー クラスです。また、プロトコルはヘッダークラスに実装されています。
@interface viewController: UIViewController <ServiceResponceDelegate>
{
ServiceClass* _service;
}
- (void) go;
@end
@implementation viewController
//
//some methods
//
- (void) go
{
_service = [[ServiceClass alloc] init];
[_service setDelegate:self];
[_service someTask];
}
それだけです。このクラスにデリゲート メソッドを実装することで、操作/タスクが完了すると制御が戻ります。
デリゲートを作成する簡単な方法を次に示します。
.h ファイルにプロトコルを作成します。@class に続いて UIViewController の名前を使用して、プロトコルの前に定義されていることを確認してください< As the protocol I am going to use is UIViewController class>.
ステップ: 1: UIViewController クラスのサブクラスとなる "YourViewController" という名前の新しいクラス Protocol を作成し、このクラスを 2 番目の ViewController に割り当てます。
ステップ: 2:「YourViewController」ファイルに移動し、以下のように変更します。
#import <UIKit/UIkit.h>
@class YourViewController;
@protocol YourViewController Delegate <NSObject>
@optional
-(void)defineDelegateMethodName: (YourViewController *) controller;
@required
-(BOOL)delegateMethodReturningBool: (YourViewController *) controller;
@end
@interface YourViewController : UIViewController
//Since the property for the protocol could be of any class, then it will be marked as a type of id.
@property (nonatomic, weak) id< YourViewController Delegate> delegate;
@end
プロトコルの動作で定義されたメソッドは、プロトコル定義の一部として @optional および @required で制御できます。
ステップ : 3 : デリゲートの実装
#import "delegate.h"
@interface YourDelegateUser ()
<YourViewControllerDelegate>
@end
@implementation YourDelegateUser
- (void) variousFoo {
YourViewController *controller = [[YourViewController alloc] init];
controller.delegate = self;
}
-(void)defineDelegateMethodName: (YourViewController *) controller {
// handle the delegate being called here
}
-(BOOL)delegateMethodReturningBool: (YourViewController *) controller {
// handle the delegate being called here
return YES;
}
@end
//メソッドを呼び出す前にメソッドが定義されているかどうかをテストします
- (void) someMethodToCallDelegate {
if ([[self delegate] respondsToSelector:@selector(defineDelegateMethodName:)]) {
[self.delegate delegateMethodName:self];
}
}
免責事項: これSwift
はdelegate
.
では、デリゲートとは何ですか? …ソフトウェア開発では、特定のコンテキスト内で一般的に発生する問題を解決するのに役立つ一般的な再利用可能なソリューション アーキテクチャがあります。これらの「テンプレート」は、いわばデザイン パターンとして最もよく知られています。デリゲートは、特定のイベントが発生したときに、あるオブジェクトが別のオブジェクトにメッセージを送信できるようにする設計パターンです。オブジェクト A がオブジェクト B を呼び出してアクションを実行するとします。アクションが完了すると、オブジェクト A は B がタスクを完了したことを認識し、必要なアクションを実行する必要があります。これはデリゲートの助けを借りて達成できます。
より良い説明のために、クラス間でデータを渡すカスタム デリゲートを作成する方法を紹介します。単純なアプリケーションで Swift を使用し、このスターター プロジェクトをダウンロードまたは複製して実行します。
と の 2 つのクラスを持つアプリを確認できViewController A
ますViewController B
。B には 2 つのビューがあり、タップすると の背景色が変わりますが、ViewController
複雑すぎませんか? さて、クラス B のビューがタップされたときにクラス A の背景色も変更する簡単な方法を考えてみましょう。
問題は、このビューがクラス B の一部であり、クラス A について何も知らないことです。そのため、この 2 つのクラス間で通信する方法を見つける必要があり、委任が優れているところです。必要なときにチート シートとして使用できるように、実装を 6 つのステップに分けました。
ステップ 1: ClassBVC ファイルでプラグマ マーク ステップ 1 を探し、これを追加します。
//MARK: step 1 Add Protocol here.
protocol ClassBVCDelegate: class {
func changeBackgroundColor(_ color: UIColor?)
}
最初のステップは を作成することprotocol
です。この場合、クラス B でプロトコルを作成します。プロトコル内で、実装の要件に基づいて必要な数の関数を作成できます。この場合、オプションUIColor
を引数として受け入れる単純な関数が 1 つだけあります。delegate
クラス名の末尾に単語(この場合はClassBVCDelegate
.
ステップ 2: プラグマ マーク ステップ 2 を探して、ClassVBC
これを追加します。
//MARK: step 2 Create a delegate property here.
weak var delegate: ClassBVCDelegate?
ここでは、クラスのデリゲート プロパティを作成するだけです。このプロパティはprotocol
型を採用する必要があり、オプションにする必要があります。また、プロパティの前に weak キーワードを追加して、保持サイクルと潜在的なメモリ リークを回避する必要があります。それが何を意味するのかわからなくても、今は心配する必要はありません。このキーワードを追加することを忘れないでください。
ステップ 3: handleTap 内のプラグマ マーク ステップ 3 を探しmethod
、ClassBVC
これを追加します。
//MARK: step 3 Add the delegate method call here.
delegate?.changeBackgroundColor(tapGesture.view?.backgroundColor)
知っておくべきことの 1 つは、アプリを実行して任意のビューをタップすると、新しい動作は表示されず、それは正しいことですが、指摘したいことは、デリゲートが呼び出されたときにアプリがクラッシュしないことです。これは、オプションの値として作成するためであり、デリゲートがまだ存在していなくてもクラッシュしないのはそのためです。ClassAVC
それでは、ファイルに移動して、委任されたものにしましょう。
ステップ 4: handleTap メソッド内でプラグマ マーク ステップ 4 を探し、ClassAVC
これを次のようにクラス タイプの隣に追加します。
//MARK: step 4 conform the protocol here.
class ClassAVC: UIViewController, ClassBVCDelegate {
}
ClassAVC がClassBVCDelegate
プロトコルを採用したので、コンパイラが次のようなエラーを表示していることがわかります。クラス A がプロトコルを採用することは、クラス B との契約に署名するようなものであり、この契約には「私を採用するクラスは、私の関数を使用しなければならない!」と書かれています。</p>
簡単なメモ: バックグラウンドから来てObjective-C
いる場合は、おそらくそのエラーを黙ってそのメソッドをオプションにすることもできると考えているでしょうが、驚いたことに、そしておそらくあなたのSwift
言語はオプションprotocols
をサポートしていません。または、実装で@objcprotocol
キーワードを使用しますprotocol
。
個人的には、さまざまなオプションのメソッドを使用してプロトコルを作成する必要がある場合は、それを別の に分割することを好みますprotocols
。そのようにして、オブジェクトに 1 つの責任を与えるという概念に従いますが、特定の実装に基づいて異なる場合があります。
オプションのメソッドに関する良い記事はこちらです。
ステップ 5: セグエの準備メソッド内でプラグマ マークのステップ 5 を探し、これを追加します。
//MARK: step 5 create a reference of Class B and bind them through the `prepareforsegue` method.
if let nav = segue.destination as? UINavigationController, let classBVC = nav.topViewController as? ClassBVC {
classBVC.delegate = self
}
ここでは、インスタンスを作成してClassBVC
そのデリゲートを self に割り当てているだけですが、ここでの self とは何でしょう? まあ、自己はClassAVC
委譲されたものです!
ステップ 6: 最後に、プラグマのステップ 6 を探して、ClassAVC
の関数を使用しましょう。func changeBackgroundColorprotocol
と入力し始めると、自動補完されていることがわかります。その中に任意の実装を追加できます。この例では、背景色を変更してこれを追加します。
//MARK: step 6 finally use the method of the contract
func changeBackgroundColor(_ color: UIColor?) {
view.backgroundColor = color
}
今すぐアプリを実行してください!
Delegates
過去に委任を使用した場合、委任を作成すると、それらの周りtableview
の多くのクラスや他の多くの作業も行われ、これらの主要な問題が解決されます。UIKIT
frameworks
おめでとうございます。カスタム デリゲートを実装したばかりです。おそらく、これだけで大変なことを考えていることでしょう。委任は、開発者になりたい場合に理解しておくべき非常に重要な設計パターンiOS
であり、オブジェクト間に 1 対 1 の関係があることを常に念頭に置いてください。
ここで元のチュートリアルを見ることができます
ViewController.h
@protocol NameDelegate <NSObject>
-(void)delegateMEthod: (ArgType) arg;
@end
@property id <NameDelegate> delegate;
ViewController.m
[self.delegate delegateMEthod: argument];
MainViewController.m
ViewController viewController = [ViewController new];
viewController.delegate = self;
方法:
-(void)delegateMEthod: (ArgType) arg{
}
デリゲート :- 作成
@protocol addToCartDelegate <NSObject>
-(void)addToCartAction:(ItemsModel *)itemsModel isAdded:(BOOL)added;
@end
送信して、データを送信しているビューにデリゲートを割り当ててください
[self.delegate addToCartAction:itemsModel isAdded:YES];