第 2 回西東京 iPhone 勉強会に行ってきました

http://atnd.org/events/4014

メンツがそうそうたるメンバーでびっくりしました。内容も非常に充実していて、 iPhone 技術ネタとしては Bonjour と UIGestureRecognizer 、iPhone 技術以外のネタとしては iPhone アプリのネタだしの仕方と iPhone アプリで受託案件をした際のお話、最後に HTML5 で Keynote みたいなのを作ったよと言う話でした。

技術ネタは予習しておいたおかげで、聞くだけになってしまわなくてすごくよかったです。 UIGestureRecognizer は UIView.multiTouchEnabled を無視して複数指のジェスチャが取れるというネタが大収穫。あとは UIWebView のタッチを無理矢理検出する方法とか。

個人的には iPhone アプリで受託案件をした際の経験談が非常に面白かったです。作る方はまだ分かるのですが、契約だとかお金の話だとかそういう話になってくるとなかなか参考になるものがないので、非常に貴重でした。次回もこのネタは聞きたいです。

HTML5 は可能性を見た感じです。マルチタッチも検出できているし簡単なアニメーションも CSS で実装できているみたいで、 JavaScript （笑）なんて言えなくなりそう。

予想通りというか iPad 率は6割超えてました。 iPhone アプリリリース経験者も5割以上。

最後に懇親会で iPadによる iよせがき を試してみました。はい、単に岸川さんと高山さんにiPad上にサインを貰っただけです＞＜ ありがとうございます！

Core Data では モデルの delete - insert をしない方が良い

最近お仕事で Core Data を頻繁に使っているのですが、ちょっとだけハマったケースをご紹介します。 Core Data ではモデルの delete - insert による更新をしない方が良いようです。


■delete - insert が問題になるケース

たとえば、 Core Data から全く同じ内容をフェッチして表示する二つのUITableViewがあるとします。それぞれ A および B と名付けます。
ここで、 A を表示してから、 B を表示する際に Core Data モデルを delete - insert すると、 A を再度表示した際にアプリケーションがクラッシュします。原因はおそらく、 A で既に読み込まれているモデルを B が削除してしまっているため、 A で既に削除されているモデルをテーブルが表示しようとしてクラッシュしているものだと思われます。 A の viewWillAppear などのタイミングで、再度 Core Data からオブジェクトを取得し直せばこの問題は解決します。

そもそも NSFetchedResultsController を使えばたぶんこの問題は発生しないと思うのですが、いずれにせよ変更があったデータをフェッチしなおさなければならなくなってしまいます。ということで可能な限りプライマリキー項目を設定して update で対応することをお勧めします。ただし update は update で sqlite3 の実行がやたら遅いということが分かっているのでこちらはこちらで別途チューニングが必要です。詳細はまた別エントリーにて。

Byline 3 ヘルプ と Tips

Byline 3 のちょっとした日本語ヘルプとTipsをこちらに掲載しようと思います。

※2010/05/11よりBylineの日本公式アカウント @bylinejp を開設しましたので、是非ご活用ください。


■メインフォルダって何？

設定画面の同期セクションにあるメインフォルダという設定。これは、簡単に言えば Bylineで表示するフォルダ です。デフォルトでは「すべてのアイテム」になっています。この状態だと、 Google Reader 側にあるすべてのフォルダがBylineと同期されて画面に表示されます。メインフォルダを設定することで、 Google Reader 側の指定されたフォルダのみをBylineと同期して表示する事ができます。一部のフィードのみを同期したい場合に有効です。

注意点として、 一度に指定できるメインフォルダは一つだけ です。


■Webページのキャッシュ設定について

設定画面のキャッシュセクションにあるWebページという設定。こちらの内容が少々難解になっているので解説したいと思います。

• モバイル向けデザイン
  この設定をONにすると、外部Webサービスを使用して対象のWebページのコンテンツを「モバイル向けデザイン」に変換してキャッシュします。モバイル向けデザインにすると、CSSが除去されたり、イメージが除去されたりリサイズされたりします。また、全体的に縦長なデザインになり、モバイルデバイスで読みやすい形式になります。
• 自動でキャッシュするコンテンツ
  メインフォルダ、スター付きアイテム、メモのうち、同期時に自動的にキャッシュするものを選択します。画像はメインフォルダが「すべてのアイテム」にセットされている場合の物ですが、メインフォルダを変更するとここの名前も変化します。この設定項目をONにした場合、以下のようなポリシーでキャッシュが行われます。
  • メインフォルダに含まれるフィードは、次の「フィードごとのキャッシュ設定」で設定した内容に従ってキャッシュされます。
  • スター付きアイテムに含まれるフィードは、すべてのフィードがキャッシュされます。
  • メモに含まれるフィードは、すべてのフィードがキャッシュされます。

• フィードごとのキャッシュ設定
  メインフォルダに含まれるフィードのキャッシュポリシーを設定します。 この設定が適用されるのはメインフォルダに含まれるフィードのみです。 スター付きアイテムおよびメモには適用されず、常にすべてのフィードがキャッシュされます。
  一覧にある各フィード名をタップすると、以下の三つの状態が順番に変化します。
  • 無印（デフォルト状態）
    本文が意図的に削られていると判断されたアイテムのみを自動的にキャッシュします。すべての本文が含まれているアイテムはキャッシュしません。
    本文が意図的に削られているアイテムというのは、たとえば このような ニュース本文全体を乗せない RSS フィードの記事のことです。
  • √マーク付き
    本文が削られているか否かに関わらず、常にキャッシュします。
  • ×マーク付き
    本文が削られているか否かに関わらず、常にキャッシュしません。
  また、右側の図にある薄い色の√マークがついているフィードは、「Bylineによって本文が意図的に削られていると判断されたフィード」であることを示します。この薄い色の√マークはメインフォルダを自動でキャッシュする設定にしているときにのみ表示されます。左側の図のCNET Japanにはチェックが無くて右側の図のCNET Japanにはチェックがあるのはこれが原因です。

■Twitter連携の設定方法

BylineではOAuthを使用してTwitterアカウントにログインします。残念ながらこのOAuthの画面が英語のままになっているため、こちらで代わりまして簡単に解説いたします。



設定画面のアカウントセクションにあるTwitter欄をタップすると、上のような画面になります。ユーザー名とパスワードを入力して、ログインボタンを押してください。



この画面が正常に表示されれば完了です。画面右上の「完了」をタップして終了してください。なんか下の方で Redirecting you back to Byline とか表示されちゃってますが無視してOKです。


■Twitter投稿時にURLを短縮する方法

Twitter投稿画面には一見、URLを短縮するためのボタンがありません。ですがご安心ください。BylineにはURLを自動的に短縮する機能があります。



このように普通に本文をタイプして、140文字よりも長くなってしまうと・・・



ご覧の通り！自動的にURLが短縮されます。



さらに本文が長くなってそれでも投稿できなくなってしまったらこのようになります。どうでしょうか、いちいちボタンを押して縮めるよりスマートだと思います。


■裏技：Byline 2と同じ感覚で「すべて既読にする」方法

Byline 3ではUIが変更されて、Byline 2ではアイテム一覧の一番下にあった「すべて既読にする」ボタンがありません。個人的にはこの変更はすごい抵抗があって作者の人にも何とかならないかとお願いしてみたのですが、その代わりにちょっとした裏技を付けてくれました。



画面一番下のツールバーをスワイプすると、ツールバーに「すべて既読にする」ボタンが表示されて、すべて既読にすることができます。これで多少はByline 2に近い感覚で操作できるかと思います。