前回の
![$テン*シー*シー-6](https://stat.ameba.jp/user_images/20100305/00/xcc/5e/88/j/o0221039610438381742.jpg?caw=800)
こんなんなっちゃったの原因は、SecondView.xib側のUIImageViewの属性設定ですね。
![$テン*シー*シー-2](https://stat.ameba.jp/user_images/20100309/22/xcc/00/c8/j/o0500025610444727845.jpg?caw=800)
ModeをCenterからAspect Fillに設定すればバッチリ解決。
![$テン*シー*シー-3](https://stat.ameba.jp/user_images/20100309/22/xcc/d6/d1/j/o0500025610444732747.jpg?caw=800)
ばっちり。
![$テン*シー*シー-4](https://stat.ameba.jp/user_images/20100309/22/xcc/58/8a/j/o0211037910444735239.jpg?caw=800)
って、思ったら~、横長の写真選ぶとあららら~。
![$テン*シー*シー-6](https://stat.ameba.jp/user_images/20100309/22/xcc/b0/00/j/o0408026310444757344.jpg?caw=800)
いや、まあ、はみ出すこと自体はAspect Fillを選んでるんで予想どおりなんですけどね。
縦横比を保ったまま縮小するのがAspectで、UIImageViewの枠内に画像の長い方の辺が収まるように縮小率を設定したければFit、すなわちAspect Fitを選べばいいわけで、私は画像の短い方の辺をUIImageViewの枠に合わせるFillを選んでるので、縮小率自体は正しいわけです。
![$テン*シー*シー-7](https://stat.ameba.jp/user_images/20100309/22/xcc/f9/f7/j/o0321019310444772784.jpg?caw=800)
Aspect Fitだとこうなる
問題は、はみ出し部分がカットされてないこと。こいつは別に指定する必要がありました。
![$テン*シー*シー-5](https://stat.ameba.jp/user_images/20100309/22/xcc/89/bf/j/o0500023610444767971.jpg?caw=800)
これだ~。
![$テン*シー*シー-8](https://stat.ameba.jp/user_images/20100309/22/xcc/d3/e8/j/o0327019510444777844.jpg?caw=800)
こんどこそ、ばっちり。って、あらららら~
![$テン*シー*シー-9](https://stat.ameba.jp/user_images/20100309/22/xcc/72/5d/j/o0329027110444781537.jpg?caw=800)
って、あ、そーか、こっちも何も設定してないわ。
こっちはInterface Builderじゃなくプログラム上で作ってるから、直で設定っすね。
上の設定もxibファイルいじらずに、viewDidUnloadメソッドで設定してもかまわないんだけど、まあ、xibで設定できるならxibで設定が素直でしょう。
どっちもUIImageViewじゃなくてUIViewのプロパティでした。
![$テン*シー*シー-10](https://stat.ameba.jp/user_images/20100309/23/xcc/00/00/j/o0332025410444790843.jpg?caw=800)
ふう。
やれやれだぜ、っと軽く編集モードでスクロールさせたら~
![$テン*シー*シー-11](https://stat.ameba.jp/user_images/20100309/23/xcc/87/c5/j/o0500031310444807351.jpg?caw=800)
き、消えたー。てか、これ前回からこうだったみたい。
コメント4から下が出てこね~。
編集モード抜けたら出てきた。
な、なぜに?
原因は意外に簡単で、FirstViewControllerクラスのenterEditModeメソッドとleaveEditModeメソッドでの
でした。
どうも、これ、特に必要ないみたい。
複数の行を一括で削除したり追加する時に使えばいいってことみたいです。なので処理削除。
これで、なんとかなりました。
追加、削除とも問題なし。
で、いよいよ本題。
やっと本題。
今から本題。
基本的な機能の実験は終わったんで、全体を試せるKonohanaDBが必要になってきたわけですよ。現状では投稿、提案の追加や削除は対応できないわけで、もう一段高機能なウエブ上のデータベースとの連携エミュレーションが必要になってきたわけです。
で、ここらへんをエミュレートするために投稿、提案、支持コメントをNSMutableArrayで管理しようと思います。
クラス図はこんな感じ。
![$テン*シー*シー-1](https://stat.ameba.jp/user_images/20100309/23/xcc/d0/00/j/o0394050710444835731.jpg?caw=800)
ContributionPrivate、SuggestionPrivate、VotePrivate、各インスタンスは自分を特定できるインディックスをIDとして保持。これを生成管理するのはPrivateIDObjectクラスで、3つのクラスともこのクラスを継承。
これでウエブ上のデータベースをエミュレーションできます。
極力単純な構造にはしたいけど、入れ子状になるのはしょうがないね~。
それ以外は特に複雑なことはしてない(というか複雑にはしてはいけない)ので、詳しくはKonohanaDB.mをみてください。
で、KonohanaDBが投稿、提案、コメント付き支持すべての追加、削除にた対応したので、
提案用ビューコントローラ(DetailViewController)、支持用ビューコントローラ(CoDetailViewController)にも追加、削除機能を実装します。
まず追加用にナビゲーションバーにそれぞれボタンを追加。
![テン*シー*シー-12](https://stat.ameba.jp/user_images/20100310/01/xcc/43/0b/j/o0332019910444997731.jpg?caw=800)
提案用ビュー
![テン*シー*シー-13](https://stat.ameba.jp/user_images/20100310/01/xcc/0a/69/j/o0332019910444997732.jpg?caw=800)
支持用ビュー
それぞれこんな感じでボタンに対応するメソッドを実装。
支持ビューコントローラでは、「支持する」ボタンが押されたら自分のビューを閉じて、提案ビューに戻るようにしている。
ちなみにFirstViewControllerのnewFlower:comment:メソッドは以下のように変更。
登録後は再度データベースに問い合わせてテーブルを再構築させます。
これには投稿用のモーダルビューが消えた時点でviewWillAppear:メソッドが呼び出されることを利用。viewWillAppear:メソッドを実装して
という処理後、KonohanaDBのメソッド
を呼び出すようにしました。
これにともないviewDidLoadメソッドでの上記メソッド呼び出しは廃止。
viewDidLoadの後はviewWillAppearが呼ばれるからね。
これはDetailViewController、CoDetailViewControllerでも同じ。
ただし、呼び出すKonohanaDBのメソッドは異なる。
またtableView:commitEditingStyle:forRowAtIndexPath:メソッドでも、各コントローラにみあったKonohanaDBのメソッド
を呼ぶようにしとります。
最後にDetailViewControllerには
CoDetailViewControllerには
を実装してデータベースからの検索結果を受け取るようにしてる。
あと、細かいところでtableView:canEditRowAtIndexPath:メソッドをランダムな値ではなくデータベースから返される投稿情報が自分の投稿であった場合、編集可能になるようにもしとります。
で、いいかげんワーニングが鬱陶しくなったんすよ。
FirstViewControllerにarrivedSuggestionメソッド、DetailViewControllerにarrivedContributionメソッドの実装はいらんわけで、この実装が抜けてるとワーニングされても迷惑なわけですわ。
UITableViewDelegateやUITableViewDataSourceでは実装してないメソッドがあっても文句言われないのはなぜに?
てことで、例のごとく右クリックで定義へジャンプでUITableViewDelegateの定義調べたら
てのを付けてると、メソッドが実装してなくても文句言われないてのがわかったので、さっそく
でKonohanaDBDelegateの全メソッドをオプション指定しました。
これでワーニングも消えてスッキリ。
スッキリついでに、ずいぶん昔に使われなくなったContributionViewController関係は削除。
だいぶ、試せるようになってきた。
って、あれ、まだ写真が歪んでるような…
ゲロゲロ。新規投稿でコメント入れようとしたら写真の後ろにいっちまった。
そこらへん次回。
------------
サンプルプロジェクト:konohana_test17.zip
![$テン*シー*シー-6](https://stat.ameba.jp/user_images/20100305/00/xcc/5e/88/j/o0221039610438381742.jpg?caw=800)
こんなんなっちゃったの原因は、SecondView.xib側のUIImageViewの属性設定ですね。
![$テン*シー*シー-2](https://stat.ameba.jp/user_images/20100309/22/xcc/00/c8/j/o0500025610444727845.jpg?caw=800)
ModeをCenterからAspect Fillに設定すればバッチリ解決。
![$テン*シー*シー-3](https://stat.ameba.jp/user_images/20100309/22/xcc/d6/d1/j/o0500025610444732747.jpg?caw=800)
ばっちり。
![$テン*シー*シー-4](https://stat.ameba.jp/user_images/20100309/22/xcc/58/8a/j/o0211037910444735239.jpg?caw=800)
って、思ったら~、横長の写真選ぶとあららら~。
![$テン*シー*シー-6](https://stat.ameba.jp/user_images/20100309/22/xcc/b0/00/j/o0408026310444757344.jpg?caw=800)
いや、まあ、はみ出すこと自体はAspect Fillを選んでるんで予想どおりなんですけどね。
縦横比を保ったまま縮小するのがAspectで、UIImageViewの枠内に画像の長い方の辺が収まるように縮小率を設定したければFit、すなわちAspect Fitを選べばいいわけで、私は画像の短い方の辺をUIImageViewの枠に合わせるFillを選んでるので、縮小率自体は正しいわけです。
![$テン*シー*シー-7](https://stat.ameba.jp/user_images/20100309/22/xcc/f9/f7/j/o0321019310444772784.jpg?caw=800)
Aspect Fitだとこうなる
問題は、はみ出し部分がカットされてないこと。こいつは別に指定する必要がありました。
![$テン*シー*シー-5](https://stat.ameba.jp/user_images/20100309/22/xcc/89/bf/j/o0500023610444767971.jpg?caw=800)
これだ~。
![$テン*シー*シー-8](https://stat.ameba.jp/user_images/20100309/22/xcc/d3/e8/j/o0327019510444777844.jpg?caw=800)
こんどこそ、ばっちり。って、あらららら~
![$テン*シー*シー-9](https://stat.ameba.jp/user_images/20100309/22/xcc/72/5d/j/o0329027110444781537.jpg?caw=800)
って、あ、そーか、こっちも何も設定してないわ。
こっちはInterface Builderじゃなくプログラム上で作ってるから、直で設定っすね。
上の設定もxibファイルいじらずに、viewDidUnloadメソッドで設定してもかまわないんだけど、まあ、xibで設定できるならxibで設定が素直でしょう。
imageview.contentMode = UIViewContentModeScaleAspectFill;
imageview.clipsToBounds = YES;
imageview.clipsToBounds = YES;
どっちもUIImageViewじゃなくてUIViewのプロパティでした。
![$テン*シー*シー-10](https://stat.ameba.jp/user_images/20100309/23/xcc/00/00/j/o0332025410444790843.jpg?caw=800)
ふう。
やれやれだぜ、っと軽く編集モードでスクロールさせたら~
![$テン*シー*シー-11](https://stat.ameba.jp/user_images/20100309/23/xcc/87/c5/j/o0500031310444807351.jpg?caw=800)
き、消えたー。てか、これ前回からこうだったみたい。
コメント4から下が出てこね~。
編集モード抜けたら出てきた。
な、なぜに?
原因は意外に簡単で、FirstViewControllerクラスのenterEditModeメソッドとleaveEditModeメソッドでの
[self.tableView endUpdates];
[self.tableView beginUpdates];
[self.tableView beginUpdates];
でした。
どうも、これ、特に必要ないみたい。
複数の行を一括で削除したり追加する時に使えばいいってことみたいです。なので処理削除。
これで、なんとかなりました。
追加、削除とも問題なし。
で、いよいよ本題。
やっと本題。
今から本題。
基本的な機能の実験は終わったんで、全体を試せるKonohanaDBが必要になってきたわけですよ。現状では投稿、提案の追加や削除は対応できないわけで、もう一段高機能なウエブ上のデータベースとの連携エミュレーションが必要になってきたわけです。
で、ここらへんをエミュレートするために投稿、提案、支持コメントをNSMutableArrayで管理しようと思います。
クラス図はこんな感じ。
![$テン*シー*シー-1](https://stat.ameba.jp/user_images/20100309/23/xcc/d0/00/j/o0394050710444835731.jpg?caw=800)
KonohanaDBはContributionPrivate(投稿情報)インスタンスをNSMutableArrayで管理。
ContributionPrivateは、その投稿に対するSuggestionPrivate(提案情報)インスタンスをNSMutableArrayで管理。
SuggestionPrivateは、その提案に対するVotePrivate(コメント付き支持情報)インスタンスをNSMutableArrayで管理。
ContributionPrivateは、その投稿に対するSuggestionPrivate(提案情報)インスタンスをNSMutableArrayで管理。
SuggestionPrivateは、その提案に対するVotePrivate(コメント付き支持情報)インスタンスをNSMutableArrayで管理。
ContributionPrivate、SuggestionPrivate、VotePrivate、各インスタンスは自分を特定できるインディックスをIDとして保持。これを生成管理するのはPrivateIDObjectクラスで、3つのクラスともこのクラスを継承。
これでウエブ上のデータベースをエミュレーションできます。
極力単純な構造にはしたいけど、入れ子状になるのはしょうがないね~。
それ以外は特に複雑なことはしてない(というか複雑にはしてはいけない)ので、詳しくはKonohanaDB.mをみてください。
で、KonohanaDBが投稿、提案、コメント付き支持すべての追加、削除にた対応したので、
提案用ビューコントローラ(DetailViewController)、支持用ビューコントローラ(CoDetailViewController)にも追加、削除機能を実装します。
まず追加用にナビゲーションバーにそれぞれボタンを追加。
![テン*シー*シー-12](https://stat.ameba.jp/user_images/20100310/01/xcc/43/0b/j/o0332019910444997731.jpg?caw=800)
提案用ビュー
![テン*シー*シー-13](https://stat.ameba.jp/user_images/20100310/01/xcc/0a/69/j/o0332019910444997732.jpg?caw=800)
支持用ビュー
それぞれこんな感じでボタンに対応するメソッドを実装。
支持ビューコントローラでは、「支持する」ボタンが押されたら自分のビューを閉じて、提案ビューに戻るようにしている。
提案ビューコントローラ(DetailViewController)
- (void)newSuggestion {
// とりあえずの処理。最終的にモーダルビュー表示。
static int index = 1;
[db addSuggestion:contributeID
name:[NSString stringWithFormat:@"test-%d", index++]
comment:@"提案"];
[result removeAllObjects];
[db connectForSuggestion:contributeID];
}
支持ビューコントローラ(CoDetailViewController)
- (void)doVote {
[db addVote:contributeID suggestionID:sugestionID
comment:voteCommentView.text];
[self.navigationController popViewControllerAnimated:YES];
}
- (void)newSuggestion {
// とりあえずの処理。最終的にモーダルビュー表示。
static int index = 1;
[db addSuggestion:contributeID
name:[NSString stringWithFormat:@"test-%d", index++]
comment:@"提案"];
[result removeAllObjects];
[db connectForSuggestion:contributeID];
}
支持ビューコントローラ(CoDetailViewController)
- (void)doVote {
[db addVote:contributeID suggestionID:sugestionID
comment:voteCommentView.text];
[self.navigationController popViewControllerAnimated:YES];
}
ちなみにFirstViewControllerのnewFlower:comment:メソッドは以下のように変更。
if (inImage != nil) {
[db addContribution:inImage comment:inComment];
}
[self.navigationController dismissModalViewControllerAnimated:YES];
[db addContribution:inImage comment:inComment];
}
[self.navigationController dismissModalViewControllerAnimated:YES];
登録後は再度データベースに問い合わせてテーブルを再構築させます。
これには投稿用のモーダルビューが消えた時点でviewWillAppear:メソッドが呼び出されることを利用。viewWillAppear:メソッドを実装して
db.dbDelegate = self;
[result removeAllObjects];
[result removeAllObjects];
という処理後、KonohanaDBのメソッド
// 無条件検索
-(void)connect;
-(void)connect;
を呼び出すようにしました。
これにともないviewDidLoadメソッドでの上記メソッド呼び出しは廃止。
viewDidLoadの後はviewWillAppearが呼ばれるからね。
これはDetailViewController、CoDetailViewControllerでも同じ。
ただし、呼び出すKonohanaDBのメソッドは異なる。
提案ビューコントローラ(DetailViewController)
// 投稿IDを指定して検索
-(void)connectForSuggestion:(int)inContributionID;
支持ビューコントローラ(CoDetailViewController)
// 投稿ID、提案IDを指定して検索
-(void)connectForVote:(int)inContributionID suggestion:(int)inSuggestionID;
// 投稿IDを指定して検索
-(void)connectForSuggestion:(int)inContributionID;
支持ビューコントローラ(CoDetailViewController)
// 投稿ID、提案IDを指定して検索
-(void)connectForVote:(int)inContributionID suggestion:(int)inSuggestionID;
またtableView:commitEditingStyle:forRowAtIndexPath:メソッドでも、各コントローラにみあったKonohanaDBのメソッド
投稿ビューコントローラ(FirstViewController)
// 投稿IDの削除
-(void)removeContribution:(int)inContributionID;
提案ビューコントローラ(DetailViewController)
// 提案IDの削除
-(void)removeSuggestion:(int)contributeID suggestionID:(int)inSuggestionID;
支持ビューコントローラ(CoDetailViewController)
// コメント付き支持IDの削除
-(void)removeVote:(int)inContributionID suggestionID:(int)inSuggestionID
voteID:(int)inVoteID;
// 投稿IDの削除
-(void)removeContribution:(int)inContributionID;
提案ビューコントローラ(DetailViewController)
// 提案IDの削除
-(void)removeSuggestion:(int)contributeID suggestionID:(int)inSuggestionID;
支持ビューコントローラ(CoDetailViewController)
// コメント付き支持IDの削除
-(void)removeVote:(int)inContributionID suggestionID:(int)inSuggestionID
voteID:(int)inVoteID;
を呼ぶようにしとります。
最後にDetailViewControllerには
// 提案が見つかった。
-(void)arrivedSuggestion:(int)inID
name:(NSString*)name
comment:(NSString*)comment
vote:(int)count;
-(void)arrivedSuggestion:(int)inID
name:(NSString*)name
comment:(NSString*)comment
vote:(int)count;
CoDetailViewControllerには
// コメント付き支持が見つかった。
-(void)arrivedVote:(int)inID
comment:(NSString*)comment;
-(void)arrivedVote:(int)inID
comment:(NSString*)comment;
を実装してデータベースからの検索結果を受け取るようにしてる。
あと、細かいところでtableView:canEditRowAtIndexPath:メソッドをランダムな値ではなくデータベースから返される投稿情報が自分の投稿であった場合、編集可能になるようにもしとります。
で、いいかげんワーニングが鬱陶しくなったんすよ。
FirstViewControllerにarrivedSuggestionメソッド、DetailViewControllerにarrivedContributionメソッドの実装はいらんわけで、この実装が抜けてるとワーニングされても迷惑なわけですわ。
UITableViewDelegateやUITableViewDataSourceでは実装してないメソッドがあっても文句言われないのはなぜに?
てことで、例のごとく右クリックで定義へジャンプでUITableViewDelegateの定義調べたら
@optional
てのを付けてると、メソッドが実装してなくても文句言われないてのがわかったので、さっそく
@protocol KonohanaDBDelegate
@optional
@optional
でKonohanaDBDelegateの全メソッドをオプション指定しました。
これでワーニングも消えてスッキリ。
スッキリついでに、ずいぶん昔に使われなくなったContributionViewController関係は削除。
だいぶ、試せるようになってきた。
って、あれ、まだ写真が歪んでるような…
ゲロゲロ。新規投稿でコメント入れようとしたら写真の後ろにいっちまった。
そこらへん次回。
------------
サンプルプロジェクト:konohana_test17.zip