Storyboardとの付き合い方 2018
Aug 12, 2018 少し前に、自分のStoryboardの使い方をツイートしたら割と反応があったので、改めてまとめてみようと思います。これまで何年かiOSアプリの開発をしてきて、Storyboardとの付き合い方は何度も変わりました。なので、今回紹介するものはあくまで2018年現在のもので、来年には変わっているかもしれません。 説明のイメージを掴みやすくするため、画面の例を用意しました。左が編集時のStoryboardで、右が実行時のiOSシミュレーターです。具体的なトピックが出た時に、この例を説明に使うことがあります。 記事の最後にこれが動作するサンプルコードも用意しましたので、興味があればどうぞ。 Storyboardを使う目的 以下の2つを重視して、Storyboardを選択しています。 動作確認に掛かる時間を短縮する 成果物の構造を把握しやすくする ただし、Storyboar
iOSDCでRxSwiftを紹介してきた + ReactiveCocoaの補足
Aug 23, 2016 オタクなのでRxSwiftの話になるとつい早口にアレコレ喋りまくってしまうのですが、今回はそういった気持ちをそっと胸にしまって、RxSwiftを導入するとアプリ開発にどういう変化が起こるのか、なるべく多くの方に伝わるように心がけて話しました。 スライド: http://blog.ishkawa.org/talks/2016-08-20-iosdc/ ビデオ: https://abemafresh.tv/tech-conference/32381 (1:00:00~) 3行で書くと以下の通りです。 RxSwiftはイベントストリームをObservableで抽象化するライブラリ 大抵のイベント処理はObservableからObserverへの接続で実装できる イベントストリームの依存関係はオペレーターから読み取れる その他、以下の3つについても話そうと思っていましたが
APIKit: レスポンスに応じた独自のエラーを投げる
{ "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ] } 今回は、このようなエラーをリクエストの呼び出し側に伝える方法を説明します。なお、この説明はDefining Request Protocol for Web Serviceのエラーの扱いをもう少し詳しく説明したものとなります。 サービス用のリクエストプロトコル APIKitでは、特定のサービス(Web API)向けのリクエストの特徴をまとめるために、サービス用のリクエストプロトコルを定義します。今回はGitHub APIを例としているので、baseURLのデフォルト値がhttps://api.github.comとなっているGitHubRequestを定義しま
TestSchedulerとSessionAdapterTypeを使った仮想時間上のテスト
May 7, 2016 TestScheduler RxSwiftにはVirtualTimeSchedulerというSchedulerがあって、仮想的な時間でイベントストリームを扱えます。仮想的な時間というとなんだか難しそうですが、要は時間を自分で操作できるSchedulerということです。 RxSwiftのテストライブラリのRxTestsには、TestSchedulerというSchedulerも用意されています。これはVirtualTimeSchedulerにテスト向けの機能をつけたもので、イベントを記録できたりします。記録したイベントはXCTAssertEqual(_:_:)で検証できるので、どの時刻にどの値が来くるかテストできるというわけです。 func test() { let scheduler = TestScheduler(initialClock: 0) let obser
Rxで1つ前の値を取得する
Apr 19, 2016 Twitter for iOSには選択中のタブをもう1度タップしたら最上部までスクロールするという機能があります。便利ですね。 こういう機能を実装するには、1つ前に選択されていた値が何なのか知る必要があります。 桶の時代にはプロパティに前回の値を保存するのが定石でしたが、川の時代にはskip(1)してzip()するというのが定石です(たぶん)。 let tappedIndex: Observable<Int> = ... Observable .zip(tappedIndex, tappedIndex.skip(1)) { previousIndex, currentIndex in return previousIndex == currentIndex } .filter { $0 } .subscribeNext { _ in // 最上部までスクロール }
Swift 2でのAPIKit + Himotoki
Jul 29, 2015 Swift 2の利点を最大限に活かすため、APIKitのデザインは大幅に刷新されました。型制約つきprotocol extensionsとHimotokiと組み合わせるとresponseFromObject(_:URLResponse:)にデフォルト実装を与えられるので、個々のリクエストの定義を楽にできます。以下はその例です。 // https://developer.github.com/v3/search/#search-repositories struct SearchRepositoriesRequest: GitHubRequestType { enum Sort: String { case Stars = "stars" case Forks = "forks" case Updated = "updated" } let query: Strin
try! Swiftにスピーカーとして参加しました
Mar 12, 2016 良いセッションはたくさんあったのですが、書き切れませんね。 平常心で型を消し去る (Gwendolyn Weston) Associated Typeを持つプロトコルは型制約でしか使えないため、型パラメーターが利用側に波及しがちになるという問題があります。セッションでは型パラメーター地獄について話していなかったと思いますが、紹介されていたAnyPokemonのようなパターンは(表面上の)型を消すことでこの問題を解決できそうだなあと思いました。また、このパターンはRxSwiftでもAnyObserverで使われています。 完全に余談ですが、Gwendolyn Westonさんはスピーカーディナー後のカラオケパーティでモーニング娘のLOVEマシーンを歌っていて、めっちゃ上手かったです。 Swiftのエラー処理についての三つの話 (Yuta Koshizawa) Swi
APIKitでSwiftらしいAPIクライアントを実装する
Feb 22, 2015 堅牢で使いやすいAPIクライアントをSwiftで実装したいをライブラリにまとめてAPIKitとしてリリースしました。 なお、”Swiftらしい”というのは主観です。 https://github.com/ishkawa/APIKit 利用側のコード リクエストに渡すパラメーターは型によって明らかになっている。 レスポンスはモデルオブジェクトとして受け取れる。 成功時にレスポンスを非オプショナルな値で受け取れる。 失敗時にエラーを非オプショナルな値で受け取れる。 // リクエストに渡すパラメーターを型で制限 let request = GitHub.Endpoint.SearchRepositories(query: "APIKit", sort: .Stars) GitHub.sendRequest(request) { response in // option
NSRunLoop+PerformBlockをCocoaPodsに登録
NSRunLoop-PerformBlockをCocoapPodsに登録しろLINE株式会社— laiso(レイソー) (@laiso) 2014, 5月 27 なぜかテスト関連のツールはマジカルな実装が多いのですが、自分は愚直にテストをしたいので愚直なライブラリを書きました。 書いたのは半年前だったのですが、需要があったのでCocoaPodsに登録しました。 ざっくり説明すると、以下のようなものです。 引数に渡したblockの実行中はNSRunLoopを回してテストケースが終了しないようする *finish = YESとするとblockから抜ける タイムアウトした場合は例外を投げてテストケースを失敗させる NSRunLoop+PerformBlock 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 - (void)testPerformBl
iOS開発とGitタグ
いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打
XCTest + iOS 7でCoverallsを利用する
XCTest + iOS7でテストを実行しても上手くコードカバレッジが取得できずに困っていたのですが、 最近@tokoromさんが取得できる方法を紹介していたので、 そちらを参考にして対応してみました。資料は以下のものです。 My unit test environment for Objective-C Coverallsに対応したライブラリは以下のものです。 ISHTTPOperation ISDiskCache ISMemoryCache NSRunLoop+PerformBlock 対応の肝となるのはISGcovFlusherをテストターゲットに追加しておくことです。 これを追加することでテスト終了時に__gcov_flush()を自動的に呼んでくれて*.gcdaが出力されるようになります。 なお、__gcov_flush()を呼び出すにはBuild Settingsの”Instr
GHFeedで利用しているライブラリ一覧
先日GHFeedというGitHubのフィードを読めるiOSアプリをリリースしました。 今日はGHFeedの開発に利用したライブラリを紹介しようと思います。 NJKWebViewProgress UIWebViewの読み込み状況を取得してくれるライブラリです。 作者は@ninjinkunさんです。 このライブラリが出してくれる値は大体0.0, 0.1, 1.0なので、 GHFeedではこれらの値を補間するようなアニメーションを追加で実装しています。 KLSwitch フラットデザインなUIButtonのライブラリです。 UIAppearanceにも対応するなど、結構細かいところまで実装が行き届いていました。 TUSafariActivity UIActivityViewControllerにOpen in Safariを追加するライブラリです。 SSKeychain キーチェーンのwra
xib/storyboardとの付き合い方について - blog.ishkawa.org
アプリが大きくなるとstoryboardの小回りの利かなさに泣きたくなることがあると思います。 そうした反動からすべてのUIをコードで実装しているiOS開発者も少なくないと思います。 自分は全部storyboardにして痛い目にあってから、全部コードにしてまた痛い目に遭い、 結局コードとxibとstoryboardを上手く使い分けるのが良いという結論に達しました。 最近、やり方が定まってきてストレスを感じなくなってきたので方法をまとめます。 これから書くことは個人の見解ですが、自分のやり方を決める上では無駄にならないと思います。 使い分け方と理由 基本方針: 以下に挙げる条件にマッチする場合除いて、コードで実装を行います。 xibを使う条件 viewの複雑度が高い場合(subviewが2,3個以上の場合)にはxibを使います。 xibを利用する理由は以下のような退屈なコードをたくさ
Qiita Hackathonに参加しました - blog.ishkawa.org
テーマはGitHub APIを利用してプログラマーの問題を解決するというものでした。 http://qiitahackathon03.peatix.com つくったもの Gitのコミット毎に親コミットとのdiffからTODO:やFIXME:というコメントを探し出し、 それを元に自動的にissueのオープン/クローズを行うツールをつくりました。 このツールを使うと、TODO:コメントの挿入/削除 = issueのオープン/クローズとなります。 あまりウケないかなと思っていたのですが、思いの外受け入れてくれた方がいて嬉しかったです。 スライド GitHubのゲストの方向けに資料は英語で書かれていますが、発表は日本語でした。 デモビデオ 発表のときはその場で実演しました。 かなり緊張しました。 (音声はありません。) 実装方法 いつも通り、Objective-Cで書きました。 前後のコミッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
