回答編集履歴
2
そのまま適用するとスコープの問題でエラーが出る可能性があるので変更した。
answer
CHANGED
@@ -68,7 +68,11 @@
|
|
68
68
|
var cabinVC: CabinViewController?
|
69
69
|
|
70
70
|
// viewDidLoad() 内部などで
|
71
|
+
if let index = self.children.firstIndex(where: { vc -> Bool in
|
72
|
+
return vc is CabinViewController
|
73
|
+
}) {
|
71
|
-
|
74
|
+
cabinVC = self.chidren[index] as! CabinViewController
|
75
|
+
}
|
72
76
|
```
|
73
77
|
|
74
78
|
のような方法で、`vc` に `CabinViewController` のインスタンス(具体的なメモリ上のアドレス)を得ることができますので、あとは
|
1
回答の変更
answer
CHANGED
@@ -1,11 +1,19 @@
|
|
1
|
-
|
1
|
+
コメントを受けて修正します。
|
2
2
|
|
3
|
+
~~とりあえず、ご質問の内容から確実に言えることだけご指摘します。
|
4
|
+
~~
|
5
|
+
結論としては、はやりインスタンスの関係を正しく把握しない状態でコーディングされていることが原因です。
|
6
|
+
|
3
7
|
```Swift
|
4
|
-
let
|
8
|
+
let let cabinVC = CabinViewController()
|
5
9
|
```
|
6
10
|
|
7
|
-
という行があり、たしかに `
|
11
|
+
という行があり、たしかに `CabinViewController` はインスタンス化されます。
|
8
12
|
|
13
|
+
しかし、StoryBoard 状に配置した Container View には`CabinViewController` が紐づけられていいるはずで(`embeded segue`として関連づけられているはず)で、ここで改めてインスタンス化した `CabinViewController` とは全く無関係になっています。
|
14
|
+
|
15
|
+
コード内でインスタンス化された `CabinViewController` は単にインスタンスが出来るるだけであり、`viewDidLoad()`などのライフサイクルに関するメソッドや、
|
16
|
+
|
9
17
|
```Swift
|
10
18
|
@IBOutlet weak var myTableView: UITableView!
|
11
19
|
```
|
@@ -23,6 +31,84 @@
|
|
23
31
|
}
|
24
32
|
```
|
25
33
|
|
26
|
-
この行にある`myTableView.reloadData()`のメソッドチェインに失敗し、
|
34
|
+
この行にある`myTableView.reloadData()`のメソッドチェインに失敗し、実行時エラーとなっています。
|
27
35
|
|
28
|
-
|
36
|
+
以上が、今回のエラーの原因です。
|
37
|
+
|
38
|
+
###対策
|
39
|
+
|
40
|
+
さて、追記していただいたコードや StoryBoard 上の階層から想像すると、ContainverView を使い、そこで TableView を表示を(つまり、`CabinViewController` の表示を)されています。
|
41
|
+
|
42
|
+
そうすると、必要な作業は、Container View に入れられた `CabinViewController` のインスタンス(より具体的に言うと、メモリ上に展開されたアドレス)を調べ、そこから直接 `CabinViewController` のメソッドを操作することになると思われます。
|
43
|
+
|
44
|
+
Container View に追加された (一般的に言うところの)View Controllerのインスタンスは、`children` という `[UIViewController]`の配列に入ますので、そこから `CabinViewController` のインスタンスを探し出す必要があります。
|
45
|
+
|
46
|
+
全てコードベースで Container View に追加するのであれば、それは自明なのですが、StoryBoard で追加したのであれば、自分で探す必要があります(ちなみに、Container View というのは、実際には UIView に過ぎず、StoryBoard で紐づければ一連の厄介な手続きが自動化されるだけの話です。逆にいうと、自動化されるために手間がかかる作業も増えるということです)。
|
47
|
+
|
48
|
+
Container View が一つだけであれば、配列のインデックスを決め打ちで調べることも可能ですが、安全性や、あるいは今回みたいに複数の Container View を使うのであれば、なんらかの方法で調べる必要があります。
|
49
|
+
|
50
|
+
たとえば、`viewDidLoad()`で
|
51
|
+
|
52
|
+
```Swift
|
53
|
+
if let index = self.children.firstIndex(where: { vc -> Bool in
|
54
|
+
return vc is CabinViewController
|
55
|
+
}) {
|
56
|
+
print("Cabin:", index)
|
57
|
+
}
|
58
|
+
```
|
59
|
+
|
60
|
+
みたいな方法を使い、`children` に入っているインスタンスとのパターンマッチを行うことでインデックスを調べる必要があります。
|
61
|
+
|
62
|
+
正確に言うと、`is` 演算子は `CabinViewController` クラスを元にして作られたインスタンスとのマッチングであり、仮に `children` の内部に複数の`CabinViewController`から作られたインスタンスが存在するのであれば、それはこの方法で調べることはできませんし、全体構成を根本的に見直す必要があると思います
|
63
|
+
|
64
|
+
それはさておき、上記の方法で `index` がわかれば、
|
65
|
+
|
66
|
+
```Swift
|
67
|
+
// クラスのプロパティとして宣言
|
68
|
+
var cabinVC: CabinViewController?
|
69
|
+
|
70
|
+
// viewDidLoad() 内部などで
|
71
|
+
cabinVC = self.chidren[index] as! CabinViewController
|
72
|
+
```
|
73
|
+
|
74
|
+
のような方法で、`vc` に `CabinViewController` のインスタンス(具体的なメモリ上のアドレス)を得ることができますので、あとは
|
75
|
+
|
76
|
+
```Swift
|
77
|
+
cabinVC?.reloadTabeleDate()
|
78
|
+
```
|
79
|
+
|
80
|
+
のような感じで、直接 `CabinViewController` のメソッドを操作することになります。
|
81
|
+
|
82
|
+
### delegate の適用
|
83
|
+
|
84
|
+
今回のようなパターンであれば、無理に delegate パターンに持ち込む必要はないと思いますし、上記のようになんらかの方法で対象となるインスタンスを探すのであれば、delegate としてインスタンスを保持する理由もあまりないとおもます(結果として、行っていることは同じなので)。
|
85
|
+
|
86
|
+
もちろん、`CabinViewController` を汎用的なクラスとして使いたいということであれば、delegate パターンを適用することになりますが、その場合には `CabinViewController` のインスタンス化の流れから根本的に見直す必要があると思います。
|
87
|
+
|
88
|
+
たとえば、StoryBoard で Container View を使うのではなく、UIView を配置し、`instantinateViewController` で従属させたいView Controllerを正しく初期化させ、`addChild` で child として追加し、その view を UIView のサブビューとして登録し、必要に応じて画面全面に持ってくるという流れを全て手動で行えば、また話は違ってくると思います(それでも、delegate パターンを使う必然性はあまりないと思います)。
|
89
|
+
|
90
|
+
### 全体の構成
|
91
|
+
|
92
|
+
もう一つ考えていただきたいのは、全体の構成です。
|
93
|
+
|
94
|
+
ViewController 内部に多くの Container View を取り込み、複数の View Controller を扱っている時点で、もはや質問者さんご自身が管理不能な状態に陥っているように思えます。
|
95
|
+
|
96
|
+
全体像が見えないのでなんとも言えないのですが、一つの画面に対してこれほどたくさんの View Controller を適用する必要があるのか、もう一度設計をよく見直された方がいいかもしれません。
|
97
|
+
|
98
|
+
ざっとみた感じであれば、一つの View Controller 内部に Table View を配置し、適切に制約(constraint)などを設定すれば、それで住むだけの話のようにも思えます。
|
99
|
+
|
100
|
+
ただ、これは期待される構成としてどのような構成を考えていらっしゃるのかよく聞かない限り判断できませんが、ただこの内容のご質問だと、聞いている方も把握するのは難しいのではないかと感じています。
|
101
|
+
|
102
|
+
### 今後の方針として
|
103
|
+
|
104
|
+
それでもやはり Container View を使って作りたい、ということであれば、
|
105
|
+
|
106
|
+
**ひとつの View Controller に一つの Container View だけを持つサンプルを作り、そこから Container View 内部に配置した View Controller のインスタンスを特定し、操作する**
|
107
|
+
|
108
|
+
という、ごく単純で明快なサンプルを作り、そこで納得のゆく結果を得てから拡張されるのが良いかと思います。
|
109
|
+
|
110
|
+
別件のご質問も拝見しましたが、そこで指摘されているように View と View Controller の違い、特に役割の違いについて誤解を受けているように私も感じました。
|
111
|
+
|
112
|
+
もしかしたら、なんらかのサンプルを元にオリジナルのアプリを作ろうとされているのかもしれません。
|
113
|
+
|
114
|
+
でも、結局はごく最小限の構成を理解しないことにはそれより大きい構成を作ることは難しい話なので、まずはごく簡単なサンプル作りから始め、着実に積み重ねられた方が良いのではないでしょうか。
|