最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
iOS9 SDKでDeprecatedになるもの。 - なるようになるかも
UPDATE(2015/09/26):この文書はDeprecatedという単語の使い方が雑なのでDeprecatedになりました。 こちらの記事を参照した方が得るものがあるかと思います。 qiita.com 新しいAPIの誕生より、APIの滅びの方が好きです。なぜならそこには失敗があり、学びがあるからです。 developer.apple.com …とか適当に言ってみましたが、iOS9のAPI Diffは、Swift2.0絡みの変更点（主にNSErrorに対応するenumの追加と、後述するビットマスクの扱いの変更）だらけで、本当に変わった場所がどこなのか分かりにくいので、ちゃんと調べてないです。 AudioUnitがOSXに追いついたCoreAudio周りが熱いような…。CFunctionPointerの魔窟だったCoreMIDIなんかは刷新と言っていいレベルで変わっていますね。でも今のA
強制バージョンアップの話。 - なるようになるかも
という記事を見かけたので。 このライブラリの実装の問題点 key description type 基本的には強制バージョンアップを行うことを前提に解説していますが、SRGVersionUpdaterではキャンセルボタン付きの告知アラートを表示することも出来ます。強制アップデートの場合は"force" を任意でのアップデートの場合は"optional"を入力して下さい。 これ、設計ミスってません？ 一度致命的なバグを出して"force"で通知したら、それ以降二度と"optional"は使えません。「必ず一定以上のバージョンを使って欲しいけど、最新版の通知もしたい」ようなユースケースに対応できないなら、"optional"の存在意義はない気がします。 あと、「評価が付くまで様子見ユーザー」層は毎回"optional"の通知を繰り返し見せられて離れます。開発者がいいと思ったアップデートが必ずし
UIKit徹底解説読んでる。 - なるようになるかも
StoryBoardに乗り遅れてる感があるので手にとってみたのですけど、いい本です。まだ完全に読み込めてないのでざっくりとした感想ですけども。 UIKit徹底解説 iOSユーザーインターフェイスの開発 作者: 西方夏子,丸山弘詩出版社/メーカー: インプレスジャパン発売日: 2014/06/13メディア: 単行本（ソフトカバー）この商品を含むブログを見る 特にUIFontDescriptorまわりについては、これほど丁寧な解説は存在しないと思います。 StoryBoardを駆使してコード量を減らしつつTODOアプリを作る章など、読み応えのある本でした。 iOS6と7による違いのトラップについても随所に述べられています。 ただUIKitの処理について徹底的に書かれているかというと、ヒットテストビューやレスポンダチェーンについての解説はイベント処理ガイド（iOS用）をほぼなぞりつつ、ジェスチャ
実行ループとdispatch_sourceの話。 - なるようになるかも
いまやiOSのネットワーク処理といえばAFNetworkingな感じです。 しかし古いストリーミングAPIを使った経験があれば、ブロックベースのAPIでどうやってネットワーク通信を行っているのか疑問に思うはずです。なぜかというと、 GCDは実行ループを持てない からです。 そもそも実行ループとは何なのでしょう。 実行ループとは NSRunLoop Class Referenceより The NSRunLoop class declares the programmatic interface to objects that manage input sources. An NSRunLoop object processes input for sources such as mouse and keyboard events from the window system, NSPort
Objective-Cの列挙の話。 - なるようになるかも
Objective-C - NSArrayでfor(; ;)とかfor-inを使うのをやめて、enumerateObjectsUsingBlock:を使う - Qiita とか Objective-Cのいろいろな反復処理 - koogawa blog とかで列挙の話を見たので。 最も高速な列挙の方法 最初に結論を書いておくと、Objective-Cにおいて最も高速な列挙の方法は、Objective-Cを投げ捨ててC言語で記述することです。 NSArrayやNSDictionaryは ランタイム関数の呼び出しがボトルネック になります。 文字列を列挙するだけならNSStringのNSArrayよりも、char*の配列を扱ったほうが圧倒的に早いです。 NSEnumerator Objective-C 1.0から存在するプロトコルで、基本的な列挙方法です。 objectEnumeratorで列挙
estimatedHeightについて計測してみた。 - なるようになるかも
iOS - 見積もりの高さでUITableViewを高速化する話。 - Qiita iOS6検証用だったiPhone4Sを、速度テスト用に初期化してiOS7に上げたのはいいんだけど、Apple Developerのダウンタイムだったみたいで、結局テスト機はiPhone5Sを使うことに。 そのためテストデータ件数が実際にはありえない数字になってます。本当は実際的な数字で確かめてみたかったんだけどね…。iPhone5Sだと処理が一瞬で終わってテストにならないんです…。 rowHeightプロパティの効果 まずUITableViewのrowHeightプロパティと、tableView:heightForRowAtIndexPath:デリゲートメソッドで高さを計算した場合の比較。 [self.tableView reloadData]で高さを再計算する時間を計測しています。 テストデータ数 1,0
Effective Objective-C 2.0の日本語訳版が出たらしい - なるようになるかも
Effective Objective-C 2.0 作者: Matt Galloway,長尾高弘出版社/メーカー: 翔泳社発売日: 2013/11/02メディア: 大型本この商品を含むブログ (1件) を見る 買うべきかどうかやや迷っている。 公式サイト（Effective Objective-C 2.0）の目次を見る限りでは、やたら常識的なことしか書いて無いし、この本を読むよりDynamic Objective-Cと、エキスパートObjective-Cプログラミングを読んだ方が役に立つ気がする。 前者はもう絶版なんだけどね。 不穏な目次 目次を見ると用語の翻訳に不穏な点が目に付く。監訳者は悪くないと思うんだけど…。 項目10 既存のクラスにカスタムデータを追加するにはAssociated Objectを使う 公式ドキュメントで Associative References と呼ばれていて
iOS7時代のUITableView - なるようになるかも
NSAttributedTextとDynamic Typeを利用したUITableViewを書いてみました。 NSAttributedText＆Dynamic Type XCodeとか半年ぶりなので、正しいのかあまり自信はないです。 こんな感じに表示されます。tableViewのmarginやpaddingはかなり適当な値で、ちゃんと調べてません。 TableViewの作法 iOS6からいろいろ変わってます。「ついてこれる奴だけついてこいッ！」って勢いでいろいろ変えやがります。適合者への道は遠いです。 UITableViewCell の生成と再利用 iOS5までのdequeueReusableCellWithIdentifier:では、キャッシュのCellが存在すれば再利用し、なければ生成していましたが、iOS6以降はUITableViewの描画を行う時点で必要なCell数を計算し、事前に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
