SlideShare a Scribd company logo

iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い

399 likes

views

Total views84,966
On Slideshare68672
From embeds16294
Number of embeds16294
Ken Morishita
Ken Morishita

iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。

Report content

1 of 78
Downloaded 376 times
iOS/Androidアプリエンジニアが   理解すべき「Model」の振る舞い 2014年7月   ゆめみ 森下 健 1 そろそろ   聞き飽きた   煽りタイトルで ごめん
以前「iOS/Androidアプリの３つの大事な設計方針」とい う話をしたのだけれど、今回はもう少し具体的な設計の 話をするよ 2
この１年で10個近くアプリのコードを見てきたのだけど、 ほぼ全てにおいて「Modelがない」のよ。皆「MVCです。 Modelあります」というけれど、私にはModelが見えな い。そう、「Modelとは何か」が共有できてないのよ 3
Modelという言葉は色々な意味で皆捉えるから、本当 は別の良い言葉を使えれば良いのだけど、見つからな いのよね。誰かエロイ人が決めてくれればなぁ。 4
以前の資料では「UIではない部分≒Model」としたけど、 今回はもう少し具体的に構造を整理して「（よく忘れら れている）Modelの重要な振る舞いは何か？」について 考察するよ。 Modelって俺の ことさ 大喜利どうぞ 5
まず、結論から述べよう！それは次の２点！   •  基本死なない   •  通知で変更を伝える   この２点がなぜ重要かをこれから説明するよ   6
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   この図はアプリを作る時によく出てくるコンポーネントよ。 ここではコンポーネントという言葉を、「一塊の機能を実 現するClass群」という意味で使っているわ。（他にいい 言葉無いかな…） よく使うコンポーネント 外部サービス データソース コンポーネント コンポーネント コンポーネント コンポーネント コンポーネント コンポーネント コンポーネント 7
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Modelもコンポーネントの一つよ。まずは、他のコン ポーネントとModelの違いをはっきりさせることにするよ。 よく使うコンポーネント 8
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   まずはプレゼンテーション層から。   9
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Viewは「データを表示」したり「ユーザの操作を受け付 ける」部分ね。Class名に  〜View  となっているやつかな。 ViewというよりWidgetみたいなものだけど。ImageView とかBuLonとかね。   ボタンやTextbox等 EventをTargetに送る データを表示する   10
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   次は、iOSならViewController、AndroidならAc@vityや Fragmentと呼ばれる部分ね。iOS的な呼び名で悪いけ ど、今後VCと呼ぶことにするわ。古典MVCでいうViewと いうのはこのVCのことだと思うけど、論争になるので略   ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 1画面1+インスタンス ボタンやTextbox等 EventをTargetに送る データを表示する   UIの状態制御とModelとの対話 11
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   VCの役割は画面の制御。Viewとの対話、画面の状態 制御、Modelとの対話、が主な役割ね。複雑なビジネス ロジックが入り込みがちなのは世の常だけど、ある程 度経験がある人はそれを意識して回避するわね。   ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 1画面1+インスタンス ボタンやTextbox等 EventをTargetに送る データを表示する   UIの状態制御とModelとの対話 フルスタックVCはよく あるアンチパターン 12
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   VCの特性として忘れてはいけないのは、「ユーザの操 作で生成・消滅する」ということよ。それがいつなのか 基本的に予測が付かないわ。これ重要だから覚えてお いてね。あと、Singletonにするとかやめてね。   ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 1画面1+インスタンス ボタンやTextbox等 EventをTargetに送る データを表示する   UIの状態制御とModelとの対話 トキ、安らかに眠れ 13
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   次はビジネス層。   14
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   まず、ビジネス層はプレゼンテーション層を参照しては いけないよ。これは絶対のルール。   ✕ ダメ、絶対 15
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   En@tyは「データそのもの」よ。他のModelやAPIを参照 したり、そういう複雑な操作は一切しないわ。単にList やMapだったり、DTOやValueObjectみたいなシンプル なObjectをイメージしてね。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer 16
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   でも例えば「画面の範囲」を表すEn@tyで「面積を計算」 「中央の位置を計算」程度なら良いと思う。でもGlobal なPropertyを参照したりはしない。さじ加減は難しいけ どあまり他のClassを参照することはしないかな。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer 17
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   En@tyはアプリケーションの本質となるデータで、フラグ とか画面・通信状態とかとはまた違います。ユーザが 入力したり、サーバから取得したようなデータね。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer 18
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   En@tyはマルチスレッドの場合などで、不変Objectであ る方が便利なこともあるけど、そこまで意識しなくても 良いかもしれない。スレッド周りの罠はたくさんあるから 今回は触れないようにします。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer スレッドはパンドラの箱 19
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   En@tyがSaveとかLoadとかデータ層へのアクセスを提供 するケースもあります。でも、オススメはそういうことは Modelに任せてしまって、En@tyは単なるデータくらいの 位置づけが良いと思っています。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer 色々あるからなー 20
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   さて、いよいよModel。Modelはデータを取得・提供・計 算・保存するのが主な役割。データを扱う中心的な役 割ね。内部状態も持つよ。Modelは複数存在して各々 取り扱うデータが異なるよ。ここは概ね良いわよね。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 21
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Modelは、基本Singleton的な非常に長寿命なObject、 とするわ。「基本死なない」ということ。Sta@cなロジック やHelper的なものは除くけど。これはいつ消滅するか わからないVCやAPIと大きく違う点になるわ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 22
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Modelは、データの更新があれば「通知」で変更を伝え る、とするよ。「通知」は「Callback的なもの」とは少し意 味合いが違うよ。これは後でまた説明します。ちなみに ObserverとかNSNo@fica@onは「通知」の実装例だよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 23
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   この２点「基本死なない」「通知で変更を伝える」という ものをModelとした場合、「Modelがない」ことが多い、と いうのが最初に言っていたことになるわ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 24
(VC)   ViewController   Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   要するに、大抵こういう構成になっているイメージね。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データ処理   ロジック   25
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   「基本死なない」「通知で変更を伝える」という性質が何 故大事なのか、というのは後でまた説明するよ。実は そんなもの必要ないかもしれないよね。でも、これが無 いから落ちたりグダグダな実装は多いんだよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 後ほど 26
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   とりあえず残りのコンポーネントの説明をしておくよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 27
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Model  Locatorは、Modelを保持しておくだけのコンポー ネント。「Service  Locatorパターン」というのがあるけど、 その名前をちょっと借りたの。適切な名前かはよくわか らないけど…   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 死なない Modelは誰かが登録する   自分では登録しない Modelを返すのが仕事 名前むずい 28
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   LocatorはSingletonで「ModelのSeLer/GeLerしかない」 と思って良いよ。Setはアプリの起動処理時にしかるべ き部分で明示的にModel  Objectを作成してSetするよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 死なない Modelは誰かが登録する   自分では登録しない Modelを返すのが仕事 29
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   起動時に明示的にSetするメリットはあって「設定(環境 情報)を伴うModelの初期化」「Main  Thread以外だと初 期化できないModelの初期化」が自然に扱えるというと ころかな。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 死なない Modelは誰かが登録する   自分では登録しない Modelを返すのが仕事 Singletonだと少し辛い 30
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   他にも、ModelはSingletonで実装しても良いのだけど 「Singletonだと単体テストでTest  Doubleに置換しにく い」のを解決するし、「Pluginのような実装が後から ModelのObjectを置換できる」というメリットもあるよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 死なない Modelは誰かが登録する   自分では登録しない Modelを返すのが仕事 挿げ替え簡単 31
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   Model  Locatorを使うかどうかは状況次第だけど、さっ き言った問題で困ったら使うと良いよ。   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object 不変ObjectがBeLer データの提供・取得・更新の責任者 機能やデータグループ毎に存在 基本死なない 「通知」で変更を伝える 死なない Modelは誰かが登録する   自分では登録しない Modelを返すのが仕事 32
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   最後にデータ層。   33
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   まず、プレゼンテーション層参照することは絶対にダメ。   ビジネス層も参照しないのが原則だけど、「APIの結果 でEn@ty  Objectを返す」のをどう考えるべきか…  密結合 で替えが効かないけど、議論の余地はあるのかも？   ✕ ダメ、絶対 ？ 34
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   APIは、外部サービスの通信の仕様を吸収するよ。1リ クエスト1インスタンスの短命さ、他のAPIを呼び出さな い単純さ、を原則とすると良いと思うよ。   短命単純 1リクエスト1インスタンス 外部サービスの通信仕様を吸収 APIは他のAPIを使用しない   やっぱり単純は最高だぜ 35
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   さっきも触れたけど、APIの結果としてビジネス層の En@ty  Class  Instanceを返すのをみたことがあります。密 結合になる、というのがデメリットなんだけど、En@tyが APIと１対１ならありなのかな、と思わなくもない   短命単純 1リクエスト1インスタンス 外部サービスの通信仕様を吸収 APIは他のAPIを使用しない   何か歪だ 36
(VC)   ViewController   Fragment View View Model   En@ty En@ty En@ty Model  Locator   Model   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   最後、Local  Data  Accessは、ファイルやDBなどへのアク セスを提供するよ。同期的な場合と非同期的な場合が あるかな。ここも色々なケースがありそうだし今回はあ まり触れないことにします。   短命単純 1リクエスト1インスタンス 外部サービスの通信仕様を吸収 APIは他のAPIを使用しない   ファイル・DBなどへのアクセス   37
これからは   「Callbackと通知」   「なぜModelが必要なのか」   を説明していくよ!   38
Callbackは、ニュアンスとして   「（自分と相手が）基本1対1の関係」   「1回呼び出すと1回呼び返される(callback)」   という意味で使うよ。   1回呼ぶと   １回返ってくる １対１ Callback 39
通知は、ニュアンスとして   「（自分と相手が）基本1対多の関係」   「呼んでも来ない呼ばなくても来る、ことがある」   という意味で使うよ。   呼んでも来ない   呼ばなくても来る １対０...N   通知 誰もいないこともある たくさん相手がいることもある 呼ばなくても来る 呼んでも来ない 40
Callbackは「(iOSの)Blocks/delegate」や「(Javaの)無名ク ラス/Interface実装」や「Deferred-­‐Promise」を使ってよく 実装されるね。Promiseの場合「１対１の関係」では無い けど、とりあえずこっちに分類しておくよ。   [[[API  create:  productId]  onFinish:  ^(Result  *result)  {          //  結果の処理   }]  execute]; new  API(productId).onFinish(new  Finish()  {                            @Override                          public  void  onFinish(Result  result)  {                                  //  結果の処理 }                  }).execute(); Blocks 無名   クラス Callback 41
通知は「(iOS)NSNo@fica@onCenter/Key  Value   Observing(KVO)」「(iOS)delegate」「(Android)Handler」や 「Observerパターン」を使ってよく実装されるね。 delegateの場合「１対多の関係」では無いけどね。   NSNo@fica@onCenter Observer   パターン   通知 42
Callbackでよく使われる「Blocks」「無名クラス」 「Deferred-­‐Promise」で(通常)共通するのは、「呼び出し 側が相手に参照を掴まれていて解除することができな い」ということよ。これは実装方式による特徴ね。   呼び出し側 呼び出される側 Call Callback Blocks、無名クラス、Deferredでは   ここを断ち切る手段がない Callbackでよくある実装 43
通知でよく使われる実装は、「通知を受け取ることを解 除する」方法が大抵あるわ。従って、「参照を掴まれて 放されない」という問題を回避する手段があるというこ とね。   通知受け取り側 通知する側 通知 通知を受け取ることを解除できる 通知受け取り側 通知受け取り側 通知 44 （Handlerだと無いかな？）
違いをまとめるとこうなるよ。この定義が一般的かはよ くわからないけど、今回の話の中ではこういう違いを意 識してね。通知は実装が少し面倒だけど「解除手段が ある」「１対多もOK」なのが重要だよ。   Callback  的 通知 相手との関係 １対１ １対多 Callback/通知回数 １回呼ぶと１回Callback 基本、不定   （だと思っておく） 実装方法 Blocks/無名クラス/Deferred   (↑この３つはクロージャ系)   Delegate/Interface Observerパターン   NSNo@fica@onCenter/KVO   (Delegate/Interface) 明示的な解除手段 クロージャ系だと普通はない 普通はある 45
次に「なぜModelが必要なのか」、つまり、   「基本死なない」   「通知で変更を伝える」   がなぜ必要なのか説明するよ！   46
まず、Modelが無い状態でどういう問題が起こりえるか を考えるよ。   (VC)   ViewController   Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   データ処理   ロジック   ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 短命単純 1リクエスト1インスタンス 想像する 47
こういう場合、大抵VCがAPIを生成・所有することになる ね。また、APIからVCはCallback的になることが多いわ。   (VC)   ViewController   Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   データ処理   ロジック   短命単純 1リクエスト1インスタンス ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 生成・所有する Callback 48
VCはAPI  Callをした直後に消滅を始めて、Callbackがあ る頃にはDestroyされているけどInstance自体は生きて いる（APIが掴んでいるから）ことがある   (VC)   ViewController   Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   データ処理   ロジック   短命単純 1リクエスト1インスタンス ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 生成・所有する Callback 49
例えばAndroidだとDestroyされたVCで、Dialogなど出そ うとすればそれで落ちるわ。VCが連続でAPIを呼び出す 実装だと無駄な処理が継続することになるね。こんな 風に「危険」と「無駄」の温床になるということね。   (VC)   ViewController   Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   データ処理   ロジック   短命単純 1リクエスト1インスタンス ユーザ入力やデータ 層の結果から生成 データそのもの List,  Map,  Object ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 生成・所有する Callback やらなくて良い   Callbackのコードが動く 既に無効なVC 要らん事しないで 50
また、ユーザが何度もそのVCを生成・消滅させるとそ の度にAPI呼び出しとCallback処理が実行されることに なる。このせいで「画面を行ったり来たりしていると重く なる（果てには落ちる）」原因になるよ。   (VC)   ViewController   Fragment API   短命単純 1リクエスト1インスタンス ユーザの操作 (VC)   ViewController   Fragment API   (VC)   ViewController   Fragment API   生成・消滅 生成・消滅 生成 ユーザの操作で   生成・消滅 ボタン連打などで   頻繁に生成・消滅もあり得る 死ねばいいのに 通信   通信   通信   連打に負けた 51
•  「危険」と「無駄」の温床   •  「画面を行ったり来たりしていると重くなる」   この２点が主要な「問題」よ   52
(VC)   ViewController   Fragment View View Model   Model  Locator   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   そこでModelを使うよ。こんな風になるよ。   生成・所有する Callback 通知 所有 更新要求 基本死なない 「通知」で変更を伝える 53
VCは次の手順で動くよ。   •  通知を受け取る準備をしてModelに「要求」を伝える   •  消滅する前にModelからの通知受信を解除する   (VC)   ViewController   Fragment onCreate()  {      this.model  =  ModelLocator.getXXModel();      this.model.addObserver(this);      ...   }     updateMyView()  {      XXEn@ty  xx  =  this.model.getXX();      if  (xx  ==  null)  {            this.model.fetchData();      }  else  {      ...     }     onDestroy()  {      this.model.removeObserver(this);   } こんな感じ 54
(VC)   ViewController   Fragment View View Model   Model  Locator   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   まず、VCは無効になる前に「通知の受信を解除」する ので、前述の「危険と無駄の温床」はなくなるよ。   生成・所有する Callback 通知 所有 更新要求 基本死なない 「通知」で変更を伝える 既に無効なVC 解除する 帰宅するときは   社用携帯  OFF！ 55
(VC)   ViewController   Fragment View View Model   Model  Locator   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   また、ユーザの操作で何度もVCが生成されて、Model に何度も「更新要求」を出しても、Modelが内部状態を 持って無視するようにできるよ。「既に通信中」「X秒前 に通信したから無視」のようにね。   生成・所有する Callback 通知 所有 更新要求 基本死なない 「通知」で変更を伝える 状態によって   要求を無視 やり過ごし社員！ 56
これで   •  「危険」と「無駄」の温床   •  「画面を行ったり来たりしていると重くなる」   この問題が解消するよ   57
VCとModelの呼び出しはこんな感じになるよ。 fetchPoint()みたいなのを明示的に呼ぶかは色々ある かな。その辺はModelの挙動ポリシーかな。   MMooddeell VVCC 残高教えて→ ←ごめん、わからん じゃあ調べてよ→ ←通知 残高教えて→ ←1000pt  だよ 通信中 model.getPoint()     -­‐>  null model.fetchPoint() model.getPoint()   -­‐>  1000 （通信しないかもしれない） 決めの問題かな？ 58
他にもModelは通知の仕組みがあるから、異なるVCに 即座に変更を伝えることができるよ。Excelみたいに、 「シートの値を変えると複数のグラフ表示が変わる」よ うなこともできるよ。   (VC)   ViewController   Fragment Model   Model  Locator   En@ty En@ty En@ty API   API   API   プレゼンテーション層 ビジネス層 データ層 State  Machine Local  Data   Access   生成・所有する 通知 基本死なない 「通知」で変更を伝える (VC)   ViewController   Fragment MVCが綺麗にハマるね 59
Excelなんて作らないよ、って思うかもしれないけど、 メールの未読数と未読マークも一つのModelを複数VC が参照するケースだよね。こういう場合もModelから通 知で考えておくと自然に作れるよ。   未読件数表示 未読マーク .   戻った時に更新されて欲しい 未読更新通知 データは一つ 60
まとめると、今回定義したModelでこうなるよ   •  危険と無駄の温床、が解決   •  画面を行ったり来たりしていると重くなる、が解決   •  VC間でデータの共有や表示の更新が簡単になる   61
いくつかこの設計に関する議論を紹介するよ   62
開発時は大抵高速回線でアプリを動かすから、気が付 きにくいというのもあるのよね   議論 API通信なんて１，２秒で終わるから、   そこまで神経質にならなくても   良いのではないか？ Mobileだと通信環境が悪いときも多いし、   その場合かなり時間かかるかな。   ユーザもイライラすると連打したりするし。 63
VCがGCされない、ことだけが問題ではないということか な。VCが「終わった、リソース解放！」した後のCallback が危ないんだよ   議論 明示的に通知を解除しなくても   Model側がWeakRef（弱参照）で   VC側を掴んでおけば問題ないんじゃないか？ 確かに弱参照は推奨されることが多いね。   でも、AndroidでDestroyからInstanceが破棄さ れるまでの間にCallbackが発生すれば問題 は同じだよ 64
フラグが乱立するのは死亡フラグ   議論 通知を解除とかしなくても、無効flag立てて   Callback内で無効flagをチェックするとかでも   良いのではないか？ 参照を掴まれている間はVCは消滅しないか らメモリの解放が遅れるけど、そういうのが大 丈夫なら大きな問題はないかもね。でも、そう いうFlagって美しくないなぁ。忘れそうだし。 フラグを折れる人   になりたい 65
cancel()は通知を解除しつつ、さらにcancel()というよう に使うと良いよ。   議論 VCからcancel()みたいなのを送れれば良いので はないか？ 確かにcancel()が有効なケースもあるね。特 にcancel()によってキューイングされている未 実行の重たい処理が破棄できる場合とかね。 66
構造的に潜在的なリスクがあるのは怖いよね   議論 Callback処理が   たいして無駄でも危険でもない場合は   問題ないのではないか？ 今は危険ではなくても、将来誰かが「問題に なる処理」を付け足す可能性があるわ。そう いう地雷は無い方が良いと思うの。 67
UIの快適さはNa@veアプリの大事な強みだしね   議論 通信中なら画面遷移させない・VC破棄させない   とか、そういう考えで良いんじゃないか？ 通信中だろうがユーザの操作はなるべく妨げ 無い方が良いよね？それって最後の手段だ と思うんだ。 68
志を下げないで   議論 連打するのはユーザが悪い、とか、   そういう考えで良いんじゃないか？ ユーザは悪くないよ。可能な操作をしている のに落ちたり重くなる方が悪いよね。Excelと かPPTが落ちたらその人のせいなの？ 69
「今回のModel定義」ってサーバサイド開発をやってき た人には馴染みがなくて抵抗があるんじゃないかと思 うの。私も実はその口なのよ。でも、クライアントアプリ をやってきた人には普通らしいんだよね。   余談 70
サーバサイドのアプリだと、「リクエストが来てレスポン スを返す」というのが鉄板の流れだよね。   サーバ リクエスト Controller Model DAO レスポンス PHPとか 71
この場合、各層の静的な参照構造の依存関係をなくし たり、操作を抽象化しておけば、結構良い感じになるよ ね。   Controller Model DAO 抽象化  依存性注入 サーバ 72
クライアントアプリだと、それぞれの層に予測しにくいタ イミングでイベントが発生するね。特にユーザの操作は 読めないわ。   VC Model DAO ユーザの操作 APIレスポンス センサーデバイス 出入口多数 クライアント 73
なんかもう住んでる世界が違う感じだと思うの。だから クライアントアプリの場合は、VC-­‐Model間はタイミング 的な依存関係も無いようなイメージで作る方が上手くい く気がするの。   Model Ac@ve VC Ac@veなVCは移り変わる・指先一つで死ぬ 長寿・マイペース APIレスポンス センサーデバイス ユーザの操作 ユーザの操作 74
呼んだら呼ばれる、ではなく、お互い好き勝手にメッ セージを送り合うような。それで問題なく動くように作る べきかと。そのために互いに状態を持ち、メッセージへ の反応には自己責任で対応する感じかな！   Model Ac@ve VC Ac@veなVCは移り変わる・指先一つで死ぬ 長寿・マイペース APIレスポンス センサーデバイス ユーザの操作 ユーザの操作 タイミング的にも緩い結合 独自の「時」 を刻む 独自の「時」 を刻む 75
今のは私の脳内イメージの余談だったけど、クライアン トアプリケーションの性質を把握した上で設計を検討す ると良いと思うよ。   76
77
参考 •  AAfN:  アプリケーションとサービスの設計   –  hLp://msdn.microsoq.com/ja-­‐jp/library/ms978348.aspx 78

Recommended

IOS/Androidアプリの３つの大事な設計方針 by Ken Morishita, has 74 slides with 44098 views.
IOS/Androidアプリの３つの大事な設計方針IOS/Androidアプリの３つの大事な設計方針
IOS/Androidアプリの３つの大事な設計方針
Ken Morishita
74 slides•44.1K views
オブジェクト指向できていますか？ by Moriharu Ohzu, has 129 slides with 241043 views.
オブジェクト指向できていますか？オブジェクト指向できていますか？
オブジェクト指向できていますか？
Moriharu Ohzu
129 slides•241K views
C#とILとネイティブと by 信之 岩永, has 63 slides with 26703 views.2013/12/21 プログラミング生放送勉強会 第27回＠品川 にて発表。
C#とILとネイティブとC#とILとネイティブと
C#とILとネイティブと
信之 岩永
63 slides•26.7K views
オブジェクト指向の設計と実装の学び方のコツ by 増田 亨, has 76 slides with 102321 views.
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
76 slides•102.3K views
20分くらいでわかった気分になれるC++20コルーチン by yohhoy, has 31 slides with 14344 views.C++MIX #5 資料
20分くらいでわかった気分になれるC++20コルーチン20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
yohhoy
31 slides•14.3K views
ソースコードの品質向上のための効果的で効率的なコードレビュー by Moriharu Ohzu, has 109 slides with 55732 views.
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
Moriharu Ohzu
109 slides•55.7K views
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発 by 慎一 古賀, has 84 slides with 86954 views.これから C# 開発を始める方、あるいはチームの開発品質をあげたい リーダー・マネージャ向けに、C# の勉強方法を解説した、約２時間の研修用の資料です。
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
慎一 古賀
84 slides•87K views
やはりお前らのMVCは間違っている by Koichi Tanaka, has 66 slides with 151028 views.PHPカンファレンス2012 & WordCampTokyo2012 LT発表資料です。 タイトルの元ネタ： http://www.amazon.co.jp/dp/4094512624
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
66 slides•151K views
オブジェクト指向エクササイズのススメ by Yoji Kanno, has 85 slides with 59768 views.
オブジェクト指向エクササイズのススメオブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
85 slides•59.8K views
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する by Yoshifumi Kawai, has 94 slides with 76409 views.Talked at CEDEC 2018, 2018/08/22 - https://2018.cedec.cesa.or.jp/session/detail/s5b559852a6405
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
94 slides•76.4K views
モジュールの凝集度・結合度・インタフェース by Hajime Yanagawa, has 100 slides with 17097 views.社内勉強会発表用 内容 ・モジュールの凝集度 ・モジュール結合度 ・オブジェクト指向 ・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
100 slides•17.1K views
Jsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contactJsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contact
tsukasa tamaru
 
WPF開発での陥りやすい罠
WPF開発での陥りやすい罠WPF開発での陥りやすい罠
WPF開発での陥りやすい罠
Sho Okada
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
さくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組みさくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組み
Takeshi Ogawa
 
Kotlinアンチパターン
KotlinアンチパターンKotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
 
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」 DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
 
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Preferred Networks
 
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
 
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
aha_oretama
 
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
Ken Morishita
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
Takuto Wada
 
怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション
土岐 孝平
 
MVC の Model を考える
MVC の Model を考えるMVC の Model を考える
MVC の Model を考える
tomo_masakura
 
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
NTT DATA Technology & Innovation
 
アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）
Shoichi Matsuda
 
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeiOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
 

More Related Content

What's hot (20)

オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメオブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
 
Jsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contactJsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contact
tsukasa tamaru
 
WPF開発での陥りやすい罠
WPF開発での陥りやすい罠WPF開発での陥りやすい罠
WPF開発での陥りやすい罠
Sho Okada
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
さくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組みさくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組み
Takeshi Ogawa
 
Kotlinアンチパターン
KotlinアンチパターンKotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
 
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」 DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
 
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Preferred Networks
 
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
 
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
aha_oretama
 
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
Ken Morishita
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
Takuto Wada
 
怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション
土岐 孝平
 
MVC の Model を考える
MVC の Model を考えるMVC の Model を考える
MVC の Model を考える
tomo_masakura
 
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
NTT DATA Technology & Innovation
 
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメオブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
 
Jsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contactJsug spring bootコードリーディング 接触篇 a contact
Jsug spring bootコードリーディング 接触篇 a contact
tsukasa tamaru
 
WPF開発での陥りやすい罠
WPF開発での陥りやすい罠WPF開発での陥りやすい罠
WPF開発での陥りやすい罠
Sho Okada
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
さくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組みさくっと理解するSpring bootの仕組み
さくっと理解するSpring bootの仕組み
Takeshi Ogawa
 
Kotlinアンチパターン
KotlinアンチパターンKotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
 
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」 DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
 
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Playgram開発秘話_2022年1月プログラミングシンポジウム招待講演_西澤勇輝、岡本雄太
Preferred Networks
 
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
 
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
aha_oretama
 
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）知らないと損するアプリ開発におけるStateMachineの活用法（full版）
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
Ken Morishita
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
Takuto Wada
 
怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション怖くないSpring Bootのオートコンフィグレーション
怖くないSpring Bootのオートコンフィグレーション
土岐 孝平
 
MVC の Model を考える
MVC の Model を考えるMVC の Model を考える
MVC の Model を考える
tomo_masakura
 
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
今こそ知りたいSpring Batch（Spring Fest 2020講演資料）
NTT DATA Technology & Innovation
 

Similar to iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い (20)

アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）
Shoichi Matsuda
 
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeiOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
 
スマートフォンアプリケーション開発の最新動向
スマートフォンアプリケーション開発の最新動向スマートフォンアプリケーション開発の最新動向
スマートフォンアプリケーション開発の最新動向
Tsutomu Ogasawara
 
スマ研第2回レポート
スマ研第2回レポートスマ研第2回レポート
スマ研第2回レポート
Shinpei Niiyama
 
121117 metro styleapp_templateapp
121117 metro styleapp_templateapp121117 metro styleapp_templateapp
121117 metro styleapp_templateapp
Takayoshi Tanaka
 
AndroidでDIxAOP
AndroidでDIxAOPAndroidでDIxAOP
AndroidでDIxAOP
nfc research
 
Apiドキュメンテーションツールを使いこなす【api blueprint編】
Apiドキュメンテーションツールを使いこなす【api blueprint編】Apiドキュメンテーションツールを使いこなす【api blueprint編】
Apiドキュメンテーションツールを使いこなす【api blueprint編】
dcubeio
 
変数の重要度ってどうやったらわかるん？
変数の重要度ってどうやったらわかるん？変数の重要度ってどうやったらわかるん？
変数の重要度ってどうやったらわかるん？
hiroya akita
 
ひと目でわからん Metro アプリ開発入門
ひと目でわからん Metro アプリ開発入門ひと目でわからん Metro アプリ開発入門
ひと目でわからん Metro アプリ開発入門
Masuda Tomoaki
 
Cod2012 デバッグ講座
Cod2012 デバッグ講座Cod2012 デバッグ講座
Cod2012 デバッグ講座
Masuda Tomoaki
 
Windows phone ＆ windows 8で見えてくるメトロの世界
Windows phone ＆ windows 8で見えてくるメトロの世界Windows phone ＆ windows 8で見えてくるメトロの世界
Windows phone ＆ windows 8で見えてくるメトロの世界
Makoto Nishimura
 
Djangoとは
DjangoとはDjangoとは
Djangoとは
Gomamatsu
 
「Camelog」Android開発秘話
「Camelog」Android開発秘話「Camelog」Android開発秘話
「Camelog」Android開発秘話
Shoya Tsukada
 
GUI アプリケーションにおける MVC
GUI アプリケーションにおける MVCGUI アプリケーションにおける MVC
GUI アプリケーションにおける MVC
Yu Nobuoka
 
Android開発者とデザイナーの効率的な連携について
Android開発者とデザイナーの効率的な連携についてAndroid開発者とデザイナーの効率的な連携について
Android開発者とデザイナーの効率的な連携について
lychee .
 
空のテンプレートから始めるWindows 8 ストアアプリ
空のテンプレートから始めるWindows 8 ストアアプリ空のテンプレートから始めるWindows 8 ストアアプリ
空のテンプレートから始めるWindows 8 ストアアプリ
Akira Hatsune
 
我が家のフロントエンド開発事情
我が家のフロントエンド開発事情我が家のフロントエンド開発事情
我が家のフロントエンド開発事情
Naoki Yamada
 
cochica
cochicacochica
cochica
Hiroki Yoshida
 
非技術者でもわかる（？）コンピュータビジョン紹介資料
非技術者でもわかる（？）コンピュータビジョン紹介資料非技術者でもわかる（？）コンピュータビジョン紹介資料
非技術者でもわかる（？）コンピュータビジョン紹介資料
Takuya Minagawa
 
ScalaMatsuri 2016
ScalaMatsuri 2016ScalaMatsuri 2016
ScalaMatsuri 2016
Yoshitaka Fujii
 
アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）アプリでもオブジェクト指向エクササイズ（Potatotips#3）
アプリでもオブジェクト指向エクササイズ（Potatotips#3）
Shoichi Matsuda
 
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeiOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
 
スマートフォンアプリケーション開発の最新動向
スマートフォンアプリケーション開発の最新動向スマートフォンアプリケーション開発の最新動向
スマートフォンアプリケーション開発の最新動向
Tsutomu Ogasawara
 
スマ研第2回レポート
スマ研第2回レポートスマ研第2回レポート
スマ研第2回レポート
Shinpei Niiyama
 
121117 metro styleapp_templateapp
121117 metro styleapp_templateapp121117 metro styleapp_templateapp
121117 metro styleapp_templateapp
Takayoshi Tanaka
 
AndroidでDIxAOP
AndroidでDIxAOPAndroidでDIxAOP
AndroidでDIxAOP
nfc research
 
Apiドキュメンテーションツールを使いこなす【api blueprint編】
Apiドキュメンテーションツールを使いこなす【api blueprint編】Apiドキュメンテーションツールを使いこなす【api blueprint編】
Apiドキュメンテーションツールを使いこなす【api blueprint編】
dcubeio
 
変数の重要度ってどうやったらわかるん？
変数の重要度ってどうやったらわかるん？変数の重要度ってどうやったらわかるん？
変数の重要度ってどうやったらわかるん？
hiroya akita
 
ひと目でわからん Metro アプリ開発入門
ひと目でわからん Metro アプリ開発入門ひと目でわからん Metro アプリ開発入門
ひと目でわからん Metro アプリ開発入門
Masuda Tomoaki
 
Cod2012 デバッグ講座
Cod2012 デバッグ講座Cod2012 デバッグ講座
Cod2012 デバッグ講座
Masuda Tomoaki
 
Windows phone ＆ windows 8で見えてくるメトロの世界
Windows phone ＆ windows 8で見えてくるメトロの世界Windows phone ＆ windows 8で見えてくるメトロの世界
Windows phone ＆ windows 8で見えてくるメトロの世界
Makoto Nishimura
 
Djangoとは
DjangoとはDjangoとは
Djangoとは
Gomamatsu
 
「Camelog」Android開発秘話
「Camelog」Android開発秘話「Camelog」Android開発秘話
「Camelog」Android開発秘話
Shoya Tsukada
 
GUI アプリケーションにおける MVC
GUI アプリケーションにおける MVCGUI アプリケーションにおける MVC
GUI アプリケーションにおける MVC
Yu Nobuoka
 
Android開発者とデザイナーの効率的な連携について
Android開発者とデザイナーの効率的な連携についてAndroid開発者とデザイナーの効率的な連携について
Android開発者とデザイナーの効率的な連携について
lychee .
 
空のテンプレートから始めるWindows 8 ストアアプリ
空のテンプレートから始めるWindows 8 ストアアプリ空のテンプレートから始めるWindows 8 ストアアプリ
空のテンプレートから始めるWindows 8 ストアアプリ
Akira Hatsune
 
我が家のフロントエンド開発事情
我が家のフロントエンド開発事情我が家のフロントエンド開発事情
我が家のフロントエンド開発事情
Naoki Yamada
 
cochica
cochicacochica
cochica
Hiroki Yoshida
 
非技術者でもわかる（？）コンピュータビジョン紹介資料
非技術者でもわかる（？）コンピュータビジョン紹介資料非技術者でもわかる（？）コンピュータビジョン紹介資料
非技術者でもわかる（？）コンピュータビジョン紹介資料
Takuya Minagawa
 
ScalaMatsuri 2016
ScalaMatsuri 2016ScalaMatsuri 2016
ScalaMatsuri 2016
Yoshitaka Fujii
 

More from Ken Morishita (6)

BigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL DialectBigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL Dialect
Ken Morishita
 
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
Ken Morishita
 
SwiftでのiOSアプリ開発
SwiftでのiOSアプリ開発SwiftでのiOSアプリ開発
SwiftでのiOSアプリ開発
Ken Morishita
 
最近の単体テスト
最近の単体テスト最近の単体テスト
最近の単体テスト
Ken Morishita
 
Logをs3とredshiftに格納する仕組み
Logをs3とredshiftに格納する仕組みLogをs3とredshiftに格納する仕組み
Logをs3とredshiftに格納する仕組み
Ken Morishita
 
Pythonとdeep learningで手書き文字認識
Pythonとdeep learningで手書き文字認識Pythonとdeep learningで手書き文字認識
Pythonとdeep learningで手書き文字認識
Ken Morishita
 
BigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL DialectBigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL Dialect
Ken Morishita
 
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
知らないと損するアプリ開発におけるStateMachineの活用法（１５分版）
Ken Morishita
 
SwiftでのiOSアプリ開発
SwiftでのiOSアプリ開発SwiftでのiOSアプリ開発
SwiftでのiOSアプリ開発
Ken Morishita
 
最近の単体テスト
最近の単体テスト最近の単体テスト
最近の単体テスト
Ken Morishita
 
Logをs3とredshiftに格納する仕組み
Logをs3とredshiftに格納する仕組みLogをs3とredshiftに格納する仕組み
Logをs3とredshiftに格納する仕組み
Ken Morishita
 
Pythonとdeep learningで手書き文字認識
Pythonとdeep learningで手書き文字認識Pythonとdeep learningで手書き文字認識
Pythonとdeep learningで手書き文字認識
Ken Morishita
 

iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い