17:13若干誇張気味のタイトルですが・・・。XcodeでiPhoneアプリを作成していると、フォント名指定のところで「えーと、指定できるフォント名って何だっけ?」と、よく手が止まってしまいます。欲を言うならここで補完入力が効いてくれて、一覧から選べたりすると嬉しいんですが文字列なのでそうもいかず。ならないかなぁと常々思っていたのですが、ふと「ひょっとしたら力業でいけるかも?」と思い立ち、作ってみたのが次のコード。:ハイ、単にフォント名をマクロ定義しただけなんですが、これが思いのほか便利。作業効率が上がりました。そこでフォントファミリーも含めた全てのフォント情報をマクロ定義したヘッダファイルを作ってみましたので、ぜひ開発のお供にご利用くださいませ。OS3.0で増えた/改名したフォントやフォントファミリーにも対応しています*1。ライセンスは一応MITライセンスとしておきますのが、大した情報ではないのでライセンス明記にはこだわりません。ご自由に使用してください。(そもそもマクロなのでバイナリには含まれず、無断使用しても分からないんですけどね)いつも他愛もない情報ですみません。UIAlertViewを別の場所に表示させる方法。11:05UIAlertViewを使って表示させるUIを、任意の場所に表示させる方法です。alert(UIAlertView)」です。方法はとても簡単で、UIAlertViewをインスタンス化した後にアフィン変換をかけてあげるだけ。サンプルソースは以下のとおりです。Applicationのコントローラクラスに作成しました。他のUIと同じ操作をすべく敢えてretainしています(なくても動作します。その場合は下のreleaseを削除)。後半2つの引数がx,yの移動量です。デフォルトの場所が0,0(->alert.transform)です。nothing.}@end実行結果はこちら。使いどころはというと、・・・えーと、タブやツールバーなどで、操作画面の中央がずれているような場合に使えるのではないかと思います。19:56せっかく教えてもらった情報を独り占めしておくのは良くないなので、ここに記しておきます。以下の情報は@tokidaさんに教えてもらった方法です(氏の記事はこちら)。@tokidaさん、これは素晴らしい情報です。ありがとうございます。テーブルビューにGroupedを選択していると、背景には縦ストライプの、あまりパッとしない絵が表示されます。標準のUIだけを使ってアプリを作成していれば何となく合うんでしょうが、独自のアプリを作っているような場合には合わないような、なんとも微妙な柄です。これをうまく変えられないかな、と思っていたら、@tokidaさんに「UIColorの+colorWithPatternImageを使えば良いですよ」と教えてもらいました。こんな感じのソースです。release];:その結果は以下のとおり。・・・イメージをガラリと変えることが出来ました。素晴らしい!!今後も使うことの多いメソッドになりそうです。参考図書このメソッドの説明、私の読んだSDK本の範囲では「iPhoneアプリケーションプログラミング*1」にのみ記載がありました(p.181)。この本にはUIColorのそれ以外のメソッドについても色々と紹介されていますので(たとえば+groupTableCiewBackgroundColorなんてご存じでした?)、けっこう重宝しています。Thanks@tokidaさん*1:Amazonインスタントストアへのリンクです。23:44※@hiroaki310さんのレビューを反映させたコードもアップしました。本当にありがとうございます。※@hirobeさんのコメントで有益な情報を得ました。メソッド(+その後のセットアップ)の処理に時間がかかってしまうことのようです。コメントにあるように、ダミーのUIViewを用意して貼り付けておくと、だいぶん改善するようです。ありがとうございます!現在作成中のアプリではテーブルビューを使う予定です。ところが実装して動かしてみると、スクロールさせたときの挙動がスムーズではありません。本来なら「スルスル」とした感じでスクロールしてくれると思うのですが、実機上では「ズルッズルズルッ」といった具合に引っかかりがあり、イマイチ気持ちよくないUIになってしまっています。テーブル内の各セルはビューコントローラの中で独自のものを作成しています。既存のものでは表示できない内容を表示させていることと、独自xibによるセルだと遅すぎて(ズ・・ズズズ・・・みたい)まともに動かないことで、その中間を狙って実装しました。そこでテーブル高速化の常套手段:セル内のビューを出来るだけ少なくするセル内で半透明になっているものを不透明にするセル内でのビューの重なりを避けるテーブル動作中のデリゲートメソッドを出来るだけ減らすテーブルの高さを高くするなどを試したのですが、どれも殆ど効果がありませんでした。Graphicsを使えばCPUの代わりにGPUで描いてくれるので、スクロールもスムーズになる」といった趣旨の結論を得るに至りました。そこで教えてもらった参考サイトのプロジェクトファイル(リンク先)をベースにコントローラクラスの中でUITableViewCellクラスにビューを追加UITableViewCellクラスのサブクラスを作成してテーブルのセルに使用UITableViewCellクラスのサブクラスだけど、描画にはCoreGraphicsを使用という3種類の方法でテーブルを実装し、動かしてみることにしました。サンプルプロジェクトをダウンロードする(修正前です。何が変わったかを比較したい方向け)サンプルプロジェクト(修正版)をダウンロードする(こちらが最新版。info.plistを変更して使ってください)「これでうまく確認できる!」と思っていたのですが・・・サンプルプログラムを実際に動かしてみると分かりますが、上記1-3のどれも殆ど同じでスベスベスクロールをしてくれました。orz確かにCoreGraphicsが若干速いものの、殆ど誤差の範囲です・・・。して自作アプリのときはあんなにも遅いんだろう??というわけで、今もって自アプリで遅い原因を調査中です。何か分かったら、高速化できたらまた書きます。書いておきながらまだ解決していないという展開で、失礼しました。*1:@takuma104さん、@cqa02303さん、@satokoさん、@hiroakiさん、@norio_nomuraさん、@onkn101さん、@khirohisさん、@kimadaさん、ありがとうございました。00:43ソース拝見しました。気になったことがありますので、以下に記させて頂きます。メモリ管理上、不要なメモリの確保や解放し忘れ(リーク)が多いような気がします。drawAtPointする際に渡すUIFontを、わざわざstaticに持ってそれをセットする必要はないと思います。firstTextLabelやlastTextLabelをcontentViewにaddSubviewした後にリリースしていないようです。(この実装であれば、alloc/initWithFrameの後でautoreleaseした方がいいかもです。UILableのfontプロパティは、それ自身がretainしてくれるので、わざわざUIFontをretainしたものをstaticに持ってそれをセットする必要はないと思います。以下のような実装の方がいいと思います。lastTextLabelをaddSubviewした後にreleaseしていないようです。11:22コメント、というよりもレビューしていただいて恐縮です。プロパティをcopyで定義していますが、retainの方が早いのではないでしょうか?確かにそうですね。ここはオリジナルのファイルのままを使っていましたが、変えた方が良いですね。*firstText;としておきます(retainは警告つぶし)。setNeedsDisplay];として、retain形式で保持するようにしました。セットする時にわざわざcopyする必要はないんじゃないでしょうか?は解決出来たと思います。コピーは確かに不要ですね。firstTextやlastTextプロパティへのセットはself.をつけないとダメじゃないでしょうか?これはセッター内でのことだと思いますが、ここでselfを付けてしまうとプロパティによって無限ループが発生してしまうので、あえて外してあると思っています。勘違いしていたらすみません。drawAtPointする際に渡すUIFontを、わざわざstaticに持ってそれをセットする必要はないと思います。staticでUIFontを書いているのは、コンビニエンスメソッドのautoreleaseによるオーバーヘッドを避けてのものではないかな、と推測しています。オリジナルのままなので推測ですが。プロパティをcopyで定義していますが、retainの方が早いのではないでしょうか?そうですね。オリジナルとの比較がしやすいように合わせましたが、無意味でした。*lastTextLabel;に変更です。つけないとダメじゃないでしょうか?ここは私のミスでした。firstTextLabelやlastTextLabelをcontentViewにaddSubviewした後にリリースしていないようです。(この実装であれば、alloc/initWithFrameの後でautoreleaseした方がいいかもです。UILableのfontプロパティは、それ自身がretainしてくれるので、わざわざUIFontをretainしたものをstaticに持ってそれをセットする必要はないと思います。ここはNormalTableViewCellセルクラスのメンバーであって、所有権は破棄していないことを明記したくて意図的に残しました。あと、UIFontは確かにstaticで持つ必要は全然無いですが、オリジナルと合わせた方向で,というのを優先したのは事実です。deallocメソッド内でreleaseされていないのは問題なので,リリースしておきます。いうことで、修正版を本記事中に改めてアップしておきます。ありがとうございました。firstTextやlastTextプロパティへのセットはself.をつけないとダメじゃないでしょうか?>これはセッター内でのことだと思いますが、...すみません、これ、私の勘違いです。setterでしたね。firstTextLabelやlastTextLabelをcontentViewにaddSubviewした後にリリースしていないようです。>ここはNormalTableViewCellセルクラスのメンバーであって、所有権は破棄していないことを明記したくて意図的に残しました。いう意味では、firstTextLabelとlastTextLabelプロパティをretainじゃなくてassignで宣言しないとリークしちゃいそうですね。リファレンスカウンタが2個になると思うので。(もし、self.を付けてセットするように変更する場合は、です。)色々と余計なコメントしてしまって逆にお時間とらせてしまったようで失礼しました。これからもどうぞヨロシクお願いします。19:00いいえ、こちらこそ色々と参考になったので助かりました。いう意味では、firstTextLabelとlastTextLabelプロパティをretainじゃなくてassignで宣言しないとリークしちゃいそうですね。リファレンスカウンタが2個になると思うので。self.を付けてセットするように変更する場合は、です。self.と付けるのと付けないのとで挙動が変わるコードはメンテナンス性が著しく落ちると思いますので、retainではなくassignにした方がいいですね。いずれにせよ、助かっています。ありがとうございます。22:24わたしもズルズルスクロールで試行錯誤中です。試した限りでは、ダミーのUIViewを用意して、Cellに張る予定のViewを先にダミーUIVewに張っておくとズルズルを回避できるようです。テーブルビュー自体の初期商事が遅くなるので、別スレッドでやるなどの対処が必要そうです。メモリ的にOKかNGかとかは未検証ですが。16:18id:hirogramさん、貴重な情報を教えていただいて、ありがとうございます。別のビューに貼り付けておくとズルズルが回避出来る、というのは朗報です。これはテーブル内で使われる全セルの、全ビューということでしょうか。UIへの処理を別スレッドでやるのは危険なので、初期処理が遅くなるのはしょうがないと諦めた方が良いかもです。01:33hirogramこと@hirobeです。要は、cellForRowAtIndexPathが呼ばれるのが画面に出る直前なので、そこでの処理に手間取るとズルズルするようです。全ビューというよりは描画の遅そうなビューを対象とするとよいと思います。セルについては全セルですが、データが多い場合は以下にあるようなページング処理と組み合わせるとよいかと。http://d.hatena.ne.jp/KishikawaKatsumi/20090118/1232224534heightForRowAtIndexPathがreload時に呼ばれるので、私はそこでビューをダミーUIViewに貼付けるなどしています。別スレッドはご指摘の通り、うまくいきませんでした。あと、グループを使うと一番上のセクションヘッダがスクロールに逆らおうとするアニメーション(?)で少し遅くなるような気がしています。セクションヘッダを使わないのも一つの手のようです。15:22hirogramさん、返事が大幅に遅くなってしまってすみません。ありがとうございます。掘り下げた調査をされているようで、とてもためになります。表示のための準備処理が遅くなるとずるずるする、ということは果たしてセルの準備がボトルネックであるということですね。ここをできるだけ速くするように頑張ってみます。それにしても、3.0だと幾つかの高速なスタイルが使えるので楽ちんになりましたね。互換性がない、というのが本当にネックですが・・・。22:55UITableViewのデリゲートメソッドについて、自分なりにまとめてみました。各メソッドがサポートするバージョン各メソッドがいつ呼ばれるかをポイントにしています。ご参考になれば幸いです。役割テーブルビューを表示する時の、テーブルビュー構築に必要なプロパティを伝えてあげること。※データソースは、テーブルビュー内で表示する情報を渡したり、テーブルビュー上の情報の変化をデータに反映させるためのもの。必須メソッドUITableView.h上で「@required」と表記されているもの。このメソッドがデリゲートを担当するクラスで定義されていないとビルドが通らない。・・・はありませんでした。デリゲート無しでも動きはするよ、ということです。オプションメソッドUITableView.h上で「@optional」と表記されているもの。このメソッドが無くても、動く。細かい制御をしたい場合には必要。こちらは用途に応じたメソッドがいっぱいありました。テーブル表示時に各セクションで1回だけ■セクションのヘッダやフッタの情報決定ここで決められた情報はtitleプロパティよりも優先されます。選択系はwill→didの順で呼ばれます。editingプロパティをYESにしたときに、各セルでまとめデリゲートだけで結構色々あるので、データソースの方は挫折してしまいました。気が向いたらやります。この表を作る時に参考にした書籍ちなみにですが、このテーブルを作る際は書籍「iPhoneアプリケーションプログラミング*1」を参考にしました。※Amazonインスタントストアへのリンクですこの本は日本語がおかしい部分があるものの、リファレンスとして活用できるようになったときに一番役に立つ本です。各クラスの主要なメソッドが一覧として書かれているので、最近何かをしたいときにとりあえず手元に置くようになっています。「はじめてのiPhoneプログラミング*2」がチュートリアルだとすれば、こちらはリファレンスですね。特筆すべきは、はじめての〜よりこちらの方が、UITableViewCellを使う時に行儀の良くてスピードの出る書き方をしていることです。読んでいたボクは、「テーブルはやっぱり遅いなぁ」という固定観念を持ってしまっていました。不明点や間違っている部分があれば教えてください。今回の記事は未申請の方法ですので、ひょっとすると審査に通らなくなるかもしれません。戻すのは簡単ですのでリスクは少ないですが、ご利用は計画的にお願いします。(@cqa02303さん、ご指摘ありがとうございました)UITableViewをスクロールさせると、画面の右側にスクロールバーが表示されます。この画像を変更する方法が分かりました。UITableViewは幾つかのSubviewを持っていて、そのうちの1つがスクロールバーを表すUIImageViewですので、そのイメージを差し替えるだけです。imageNamed:@"scrollbar.png"];}}こうすることで、たとえば下の画像のようにスクロールバーの見た目を変更できます。使いどころが難しいとは思いますが、自分のUIに統一性を持たせたい時に活用すると良いのではないかと。やってこのビューを見つけたかちなみにこのビューをどうやって見つけたかを記しておきます。・・・とはいっても簡単で、tableViewは複数のサブビューを持っているという話をエリカ本で読んだので、subviewsメソッドで1つ1つを取り出し、そのクラス名を出力しただけです。そのときのソースコードは以下のとおり。コレ!!という出力が得られます。「最後のは何?」ということで取りあえず画像を突っ込んでみたら分かった、という流れです。以下のAmazonインスタントストアで紹介した本を参考にしました。エリカ本と、iPhoneアプリケーションプログラミングの2冊は今回お世話になリました。iPhoneアプリ開発グループ」で書いていた、テーブルビューのサイズ変更をするとテーブル表示がおかしくなるという問題が、その原因とともに解決したので記録を残しておきます。以下が修正後のソースです(実際はもう少し手を入れましたが、今回は違いが分かるように同じソースを使っています)。「Edit終了でendUpdates」という処理を行わせていたことが悪かったようです。これらのメソッドはテーブルの情報を実際に変更しているコードの前後で書いてあげればよく、上記ソースのようにイベントをまたぐような大きな処理で使わせるものではありませんでした。これを消すことで、ものの見事に動くようになりました。お騒がせいたしました。これ、エリカ本で書かれていた方法なんだよなぁ・・・。情報が間違っているのか、それとも少しずつ情報が古くなっているのか。公式ドキュメントも含めて、記述されている情報を鵜呑みにしてはいけないという好例になってしまいました。iPhoneアプリ開発グループ上記のサイトで「もしかしてひょっとして」と気づきました。「beginUpdatesとendUpdatesは、複数のセル情報を一度に入れ替える場合にのみ必要」といったところですかね。Thankskouichiさん、ohnoさん、有益なコメントをありがとうございました。問題解決のヒントになっただけでなく、知識も広げられました。09:23NavigationControllerを使用しているTableViewControllerで次のようにするとtoolbarが表示されます。tableViewのサイズは自動的に変わります。NO;}私がやったところでは、本記事の方法ではうまく行きませんでした。01:15コメントありがとうございます。toolbarItemsはOS3.0から導入されたプロパティですね。Targetにしているためこの方法は使えないですが、将来のために参考にさせていただきます。貴重な情報、ありがとうございました。20:34貴重な情報ありがとうございます。参考にさせていただいています。Tableviewのサイズを変更できずに私も困っています。上記方法でも変更できませんでした。20:58whaison@me.comさん、コメントありがとうございます。1つ簡単なトリックとして、テーブルビューを置く時はUIViewを下に一枚敷いた上でウィンドウに配置すると、UIView(テーブルビューではない)のサイズ変更に対して上手に追随してくれてサイズ変更も容易、という方法があります。20:20今、タイトルのことで悩んでいます。やろうとしていることは、ナビゲーションバー付きのテーブルビューを最初に表示しておいて、ナビゲーションバー上には「Edit」ボタンを付けておく「Edit」ボタンが押されたら、隠しておいたツールバー(UIToolBar)を表示させて、編集画面に移行するこのツールバーを表示させたとき、テーブルビューの大きさをツールバーぶん縮める(でないとツールバーに隠れる最後の方の行を編集できないため)「Edit」ボタン(UIではDoneに変えてます)をもう一度押すと、ツールバーは隠れてテーブルビューも元の大きさに戻る。Safariのブックマーク編集のときのようなイメージを持ってもらうと良いかもしれないです。ところが、上記の3のときに縮めたテーブルビューが行全体の一部しか表示しなくなってしまう問題に当たってしまいました。全体で20行程度のテーブルを表示させているときに3で縮めると、今画面上に表示されているぶんはそのまま残りつつも、残りの行が何も表示されなくなってしまうのです(スクロールは20行ぶんは行えるみたい)。4の処理を行えば、また元通りです。どなたか同じような症状に陥った方っていますか?ちなみに「Edit」を押したときの処理はこんな風にしています。commitAnimations];}tableView.boundsではなくtableView.frameでも全く同じ状況でした。期待通りの動作をします。バグと問題を切り分けることができないですかね。21:29ありがとうございます!SDKは2.2.1と3.0のデバイス/シミュレータ全ての組み合わせで試したのですが、まったく同じ症状でした。いうことは私のビューの作り方か、もしくはその取り扱いのどこかに問題がある可能性が濃厚ですね。方向性としては間違っていなかったということが、何よりの収穫です。kouichiさん、ありがとうございます。