📦 ⌛️ 🍀 Swiftのバインディング。 MVVMの最初の一歩を踏み出す 👨🏿‍🏭 🌈 🚢

良い一日。この記事は、毎日インターフェイスのデータの変動に苦労している人、MVVMの存在をまだ知らない人、およびiOSアプリケーションの開発時にこのパターンが実際にうまく適用できることを疑う人に役立ちます。猫の下で興味を持ってください。

歌詞の束と背景

自分を経験豊富なiOS開発者と呼ぶことはできません。 iOSの世界との知り合いは数年前に行われましたが、iOS向けアプリケーションの開発に力を入れたいという要望が最近現れました。私の道は厄介でした。 Obj-Cはすぐには感心しませんでした。使い慣れたものでアプリケーションを開発したかったのです。したがって、PhoneGap、Apcelerator Titaniumが使用されました。それだけです。しかし、当然のことながら、これらの取り組みからは何も生まれませんでした。長い休憩の後、私が働いている会社は、モバイルアプリケーションの開発について真剣に考えました。私は何も発明せず、人生を単純化しませんでした。サードパーティのフレームワークを使用せずに、ObjCのみで作業を行いました。そして、それは私にとって苦痛でした。単純なことが複雑であることが判明し、自動レイアウトに対処できず、コードを見ることができませんでした。したがって、次のプロジェクトでは、Xamarin Formsが開始されました。プロジェクトで約2か月作業した後、この技術はまだ完全にはほど遠いことが明らかになりました（最終的にはプロジェクトがベータ状態であることが判明しましたが、これについてはあまり言及されていませんでした）。しかし、Xamarin Formsを使用している間、このプロジェクトが飽和している多くのパターンに触発されました;さらに、カスタムコンポーネントを大量に作成する必要があったため、UIKitの動作をより明確に理解することができました。その瞬間、プロジェクトをネイティブに書き直す必要があることが明らかになったとき、Swiftは急速にリリースに近づいていました。私はこの言語の本を読み、最初からやり直すことができる自分の強さを感じました。しかし、最初の体験はまだ自分を連想させるものだったので、iOSでMVVMを探し始めました。私はこのコンセプトが本当に好きでした。

当時、私の目に留まった記事はすべて、ReactiveCocoaを使用して問題を解決することを提案しました。このライブラリのコードサンプルを見ると、私はまだ勉強しなければならないことに気付きました。私は何を見たのか分からなかった。 Swiftについては、ReactiveCocoaの使用も提案しました。実際、Colin Eberhardtの記事が私の出発点でした。しかしすぐに、前述の著者が説明したアプローチがメモリリークにつながったという事実に直面しなければなりませんでした。どうやら私は何か間違ったことをしていて、それから何を正確に理解しなかったようです。さらに、ReactiveCocoaは私にとってブラックボックスのままでした。ビューモデルとビューをリンクするためだけに使用されることを考えると、このライブラリを削除することが決定されました。バインディングの問題を解決したObservable Swiftプロジェクトに出会いました。すぐに私たちのプロジェクトが完了し、地平線上で新しいプロジェクトが完成しました。私はそれを徹底的に準備したかったのです。

問題の声明

現時点では、MVVMをUIKitに安全に導入する方法を想像することはできません。これは、Xamarin Formsで見たMVVMのことで、とても感銘を受けました。ほとんどの場合、このためにUIKitの上にフレームワークを記述し、開発者をこのフレームワークにバインドする必要があります。抵抗が最も少ない経路をたどります。Appleが提供するものを使用します。ただし、同時に、UIのより宣言的な記述に努めます。

MVVMに惹かれた最初で最も重要なことは、ViewModelとViewの動的リンクでした。これにより、プレゼンテーションから分離してビジネスロジックを記述することができます。 ViewControllerでのロジックの記述にはすでに慣れています。そして、これは本当に地獄です。 ViewControllerのコードを最小限に抑えることを目指しましょう。最初に、ViewModelの状態が変更され、この変更がUIに反映される必要があることを理解する必要があります。 Appleは、たとえばKVOの使用を提案しています。 ReactiveCocoaはこのタスクを簡素化します。しかし、Swiftがあります。そして、私たちはできるだけシンプルでクリーンな決断をしたいと考えています。同僚がこの問題を解決する方法を以下に示します。

ところで、 Reactive Cocoa 3.0の今後のリリースを忘れないでください。しかし、 Bondライブラリは私たちのタスクに最も適しています。私が以下に示すものに取り組んでいる間、 ボンドはちょうど始まったばかりで、私の要件に適合しませんでした。今でもそれは彼らに少しは合いません。加えて、開発者が何らかの形ですべてを複雑にしているように思えました。すべてを可能な限り簡素化したかった。しかし、実は、データを表現に関連付ける方法についてのビジョンに取り組んでいるときに行き止まりになったとき、 ボンドソースで答えを見つけ続けました。

ダイナミック

小さいことから始めましょう。同時に、最も重要なことから始めましょう。変数の状態の変化について学び、何らかの形でこれらの変化に反応できる必要があります。私たちはシンプルさと簡潔さのために努力していることを思い出させてください。そしてこの場合、スウィフトはその栄光のすべてに現れます。ジェネリック、驚くべき構文を持つラムダ、観測可能なプロパティを提供します。それで何かを作りましょう。

class Dynamic<T> { init(_ v: T) { value = v } var value: T { didSet { println(value) } } }

これで、値valueの変化を監視する機会があります。実際には、次のようになります。

 let dynamicInt: Dynamic<Int> = Dynamic(0) println(dynamicInt.value) dynamicInt.value = 1 dynamicInt.value = 17

可変エンティティのリスナーサポートを追加します。リスナーは匿名関数になり、引数に新しい値valueを渡します。

 class Dynamic<T> { typealias Listener = T -> () private var listeners: [Listener] = [] init(_ v: T) { value = v } var value: T { didSet { for l in listeners { l(value) } } } func bind(l: Listener) { listeners.append(l) l(value) } func addListener(l: Listener) { listeners.append(l) } }

addListenerメソッドは、リスナーのリストにハンドラーを追加するだけで、 bindメソッドも同じことを行いますが、追加されたリスナーをすぐに呼び出して、現在の値を渡します。

 let dynText: Dynamic<String> = Dynamic("") dynText.bind { someLabel.text = $0 } dynText.addListener { otherLabel.text = $0 } dynText.value = "New text"

ジェネリックを使用しているため、データ型を確認したりキャストしたりする必要はありません。コンパイラーがこれを行います。たとえば、次の場合、コードはコンパイルされません。

 let dynInt: Dynamic<Int> = Dynamic(0) dynInt.bind { someLabel.text = $0 }

コンパイラは、リスナーの引数がInt型であることを認識しており、このフィールドの型がStringであるため、この引数の値をUILabelクラスのオブジェクトのテキストフィールドに割り当てることはできません。さらに、匿名関数の単純化された構文のおかげで、不必要な記述をせずにリスナーを追加することができました。しかし、完璧に制限はありません。いくつかの演算子を定義するか、コードをさらに削減する目的で使用可能な演算子をオーバーロードできます。

 func >> <T>(left: Dynamic<T>, right: T -> Void) { return left.addListener(right) } infix operator >>> {} func >>> <T>(left: Dynamic<T>, right: T -> Void) { left.bind(right) }

 let dynText: Dynamic<String> = Dynamic("") dynText >>> { someLabel.text = $0 } dynText >> { otherLabel.text = $0 } dynText.value = "New text"

所有されていない、弱い、ボイドとボイドについての考え？

実際には、上記の例ではメモリリークが発生します。以下に例を示します。

 class MyViewController: UIViewController { @IBOutlet weak var label: UILabel! let viewModel = MyViewModel() override func viewDidLoad() { viewModel.someText >>> { self.label.text = $0 } super.viewDidLoad() } }

明らかに、今ではリスナー関数とselfは互いに厳密に接続されており、 MyViewControllerクラスオブジェクトは決して削除されません。これを防ぐには、接続を緩める必要があります。

 viewModel.someText >>> { [unowned self] in self.label.text = $0 }

良いですしかし、一つだけあります。 MyViewControllerオブジェクトの削除後にリスナー関数が呼び出されないという保証はありません。自分自身を保護するために、 weakを使用します。

 viewModel.someText >>> { [weak self] in self?.label.text = $0 }

ただし、この場合、コードはコンパイルされません。リスナーのタイプはString-> Void？ 、ただし、正常なコンパイルのためにはString-> Void型でなければなりません。したがって、最初にDynamicに 2種類のリスナーを追加しました。戻り値VoidとVoid？..したがって、 bind メソッドとaddListenerメソッドをオーバーロードして、2種類のリスナーをサポートしました。しかし、たとえば次の場合、コンパイラはどのメソッドを呼び出すかを決定できないことがすぐに明らかになりました。

 viewModel.someText >>> { [weak self] in if self != nil { self!.label.text = $0 } }

したがって、2種類のリスナーをサポートするという考えを捨て、そのようなトリックを活用する必要がありました。

 viewModel.someText >>> { [weak self] in self?.label.text = $0; return } viewModel.someText >>> { [weak self] in self?.label.text = $0; () } viewModel.someText >>> { [weak self] v in v; self?.label.text = v }

もちろん、ハンドラー関数に加えて、オブジェクトへの参照に加えて、動的オブジェクトを渡すためにweakを使用することを拒否し、オブジェクトが突然削除された場合、関数を呼び出すことはできません。 Bondライブラリで使用されるのはこのアプローチです。しかし、それは私のやり方ではありませんでした:)

UIKitを使用した作業の簡素化

同意します。テキストとUILabelをリンクするために同じラムダを常に説明するのは不快です。シンプルにしたい：

 viewModel.someText >>> label

不可能はありません。結局、このような構文に簡単に到達できます。実装アイデアは再びBondから親切に借りられました。アイデアは簡単です。リスナーを持つフィールドを何らかのオブジェクトに保存し、このリスナーを動的オブジェクトにバインドできます。

 final class PropertyModifier<T> { typealias Modifier = (T) -> () let modifier: Modifier init (_ l: Modifier) { self.modifier = l } }

PropertyModifierクラスのオブジェクトはビュー自体によって作成され、ラムダはビューの特定のフィールドの値を変更するコードとともにコンストラクターに渡されます。

 private var UILabelPropertyKeyTextModifier: UInt8 = 0 extension UILabel { var textModifier: PropertyModifier<String?> { if let pm: AnyObject = objc_getAssociatedObject(self, &UILabelPropertyKeyTextModifier) { return pm as PropertyModifier<String?> } else { let pm = PropertyModifier<String?> { [weak self] in self?.text = v; () } objc_setAssociatedObject(self, &UILabelPropertyKeyTextModifier, pm, objc_AssociationPolicy(OBJC_ASSOCIATION_RETAIN_NONATOMIC)) return pm } } }

拡張では、保存されたフィールドを記述することができないため、ObjCランタイムと関数objc_setAssociatedObject 、 objc_getAssociatedObjectが 助けになります 。これを行うことができます：

 viewModel.someText >>> label.textModifier.modifier

簡単にしましょう：

 func >> <T>(left: Dynamic<T>, right: PropertyModifier<T>) { left.addListener(right.modifier) } func >>> <T>(left: Dynamic<T>, right: PropertyModifier<T>) { left.bind(right.modifier) } viewModel.someText >>> label.textModifier

はるかに良い。しかし、それだけではありません。ビューの最も使用されているプロパティの一部を強調表示し、デフォルトでPropertyModifierを割り当てることができます。

 protocol BindableObject { typealias DefaultPropertyModifierTargetType var defaulPropertytModifier: PropertyModifier<DefaultPropertyModifierTargetType> { get } } extension UILabel: BindableObject { typealias DefaultPropertyModifierTargetType = String? var defaulPropertytModifier: PropertyModifier<DefaultPropertyModifierTargetType> { return textModifier } } func >> <T, B: BindableObject where B.DefaultPropertyModifierTargetType == T>(left: Dynamic<T>, right: B) { left.addListener(right.defaulPropertytModifier.modifier) } func >>> <T, B: BindableObject where B.DefaultPropertyModifierTargetType == T>(left: Dynamic<T>, right: B) { left.bind(right.defaulPropertytModifier.modifier) }

以上です。 UILabelには 、 テキストフィールドの値を変更する標準のPropertyModifierがあります。そして、指定された目標に到達しました。つまり、次のような関係を作成できます。

 viewModel.someText >>> label

チーム

私が気に入ったXamarin Formsの注目すべき概念の1つは、チームでした。実際、2つの関数を使用してコマンドを記述できます。1つはtrueまたはfalseを返し、コマンドが実行可能であることを示し、2番目はコマンドが実行するアクションです。ボタン（ UIButton ）があるとします。ボタンには有効なフィールドがあり、ユーザーはボタンを押すことができます。その後、何らかのアクションが発生します。インターフェイスの動作の宣言的な記述を目指していることを覚えていますか？このアイデアをコントロールに拡張しましょう。

 final class Command<T> { typealias CommandType = (value: T, sender: AnyObject?) -> () weak var enabled: Dynamic<Bool>? private let command: CommandType init (enabled: Dynamic<Bool>, command: CommandType) { self.enabled = enabled self.command = command } init (command: CommandType) { self.command = command } func execute(value: T) { execute(value, sender: nil) } func execute(value: T, sender: AnyObject?) { var enabled = true if let en = self.enabled?.value { enabled = en } if enabled { command(value: value, sender: sender) } } } protocol Commander { typealias CommandType func setCommand(command: Command<CommandType>) } func >> <T, B: Commander where B.CommandType == T>(left: B, right: Command<T>) { left.setCommand(right) } private var UIButtonPropertyKeyCommand: UInt8 = 0 extension UIButton: Commander { typealias CommandType = () func setCommand(command: Command<CommandType>) { if let c: AnyObject = objc_getAssociatedObject(self, &UIButtonPropertyKeyCommand) { fatalError("Multiple assigment to command") return } objc_setAssociatedObject(self, &UIButtonPropertyKeyCommand, command, objc_AssociationPolicy(OBJC_ASSOCIATION_ASSIGN)) command.enabled?.bind { [weak self] in self?.enabled = $0; () } addTarget(self, action: Selector("buttonTapped:"), forControlEvents: .TouchUpInside) } func buttonTapped(sender: AnyObject?) { if let c: Command<CommandType> = objc_getAssociatedObject(self, &UIButtonPropertyKeyCommand) as? Command<CommandType> { c.execute((), sender: sender) } } }

したがって、 有効なフィールドと、 executeメソッドが呼び出されたときに実行する必要がある関数を持つコマンドがあります。チームをボタンに関連付ける必要があります。これを行うために、 setCommandメソッドを使用してCommanderプロトコルを入力しました 。 有効なコマンドの動的フィールドを対応するUIButtonプロパティに関連付けることにより、 UIButtonのプロトコルを実装します。また、便宜上>>演算子をオーバーロードしました。結果として何が得られますか：

 class PageModel { let nextPageEnabled: Dynamic<Bool> = Dynamic(true) lazy var openNextPage: Command<()> = Command ( enabled: self.nextPageEnabled, command: { [weak self] value, sender in //Open next page }) } class MyViewController: UIViewController { @IBOutlet weak var nextButton: UIButton! let pageModel = PageModel() override func viewDidLoad() { nextButton >> pageModel.openNextPage super.viewDidLoad() } }

おわりに

私たちが自由に使えるのは、あらゆるものに関連付けることができる動的オブジェクトです。ボタンをより表情豊かにクリックすることでアクションを説明できるコマンドが用意されました。そして、これはすでにUIViewControllerを単純化するのに十分です。舞台裏には、 動的な双方向バインダー用のマップとフィルター 、およびUITableViewの簡略化された作業がありました。しかし、あなたはこれを自分で見ることができます。このアプローチの機能を示すプロジェクトは、 GitHubで入手できます。ご覧になることをお勧めします。

シードの例

 class TwoWayBindingPage: Page { typealias PMT = TwoWayBindingPageModel @IBOutlet weak var switchLabel: UILabel! @IBOutlet weak var switchControl: UISwitch! @IBOutlet weak var switchButton: UIButton! @IBOutlet weak var textFieldLabel: UILabel! @IBOutlet weak var textField: UITextField! @IBOutlet weak var textFieldButton: UIButton! @IBOutlet weak var sliderLabel: UILabel! @IBOutlet weak var slider: UISlider! @IBOutlet weak var sliderButton: UIButton! override func bindPageModel() { super.bindPageModel() let pm = pageModel as PMT switchButton >> pm.changeSomethingEnabled textFieldButton >> pm.changeUserName sliderButton >> pm.changeAccuracy pm.somethingEnabled | { "Current dynamic value: \($0)" } >>> switchLabel pm.userName | { "Current dynamic value: \($0)" } >>> textFieldLabel pm.accuracy | { "Current dynamic value: \($0)" } >>> sliderLabel pm.somethingEnabled <<>>> switchControl pm.userName <<>>> textField pm.accuracy <<>>> slider } } class BeerListPage: Page { typealias PMT = BeerListPageModel @IBOutlet weak var tableView: UITableView! private var tableViewHelper: SimpleTableViewHelper! override func bindPageModel() { super.bindPageModel() let pm = pageModel as PMT tableViewHelper = SimpleTableViewHelper(tableView: tableView, data: pm.beerList, cellType: BeerTableCell.self, command: pm.openBeerPage) tableView.pullToRefreshControl >> pm tableView.infiniteScrollControl >> pm } }

ご清聴ありがとうございました。コメント、提案、批判を歓迎します。

Swiftのバインディング。 MVVMの最初の一歩を踏み出す

問題の声明

ダイナミック

UIKitを使用した作業の簡素化

チーム

おわりに

More articles: