MacBookを開いた時に自動的にテザリングを開始する
Nov 9, 2018 最近お外で作業する機会が増えて、MacBookを開く度にメニューバーからテザリングを開始するのが億劫だと感じるようになった。本当は単体でモバイル通信ができるMacBookがあれば良いのだけど、今のところそういうモデルはないので、自分が手動でやっていることを自動化することにした。この手順は「スリープ解除のイベントを捕まえる」と「Bluetoothのメニューバーを操作する」の2つに分解できる。少し調べてみると、前者はSleepWatcherで、後者はAppleScriptで実現できることがわかった。 SleepWatcherは今日まで全然知らなかったけど、歴史が長いらしい。ドキュメントではMac OS X 10.1についても言及されているので、2000年くらいから開発されていてるみたい。そして、macOS Majave(10.14)の今でもきちんと動く。こういうプロダク
Storyboardとの付き合い方 2018
Aug 12, 2018 少し前に、自分のStoryboardの使い方をツイートしたら割と反応があったので、改めてまとめてみようと思います。これまで何年かiOSアプリの開発をしてきて、Storyboardとの付き合い方は何度も変わりました。なので、今回紹介するものはあくまで2018年現在のもので、来年には変わっているかもしれません。 説明のイメージを掴みやすくするため、画面の例を用意しました。左が編集時のStoryboardで、右が実行時のiOSシミュレーターです。具体的なトピックが出た時に、この例を説明に使うことがあります。 記事の最後にこれが動作するサンプルコードも用意しましたので、興味があればどうぞ。 Storyboardを使う目的 以下の2つを重視して、Storyboardを選択しています。 動作確認に掛かる時間を短縮する 成果物の構造を把握しやすくする ただし、Storyboar
ls2xsでLocalizable.stringsからStoryboardの.stringsを自動生成する
Feb 17, 2015 iOS 6あたりからxib, storyboardの文字列ベースのローカライズを可能とするBase Internationalizationが導入されましたが、 xib, storyboardの.stringsのキーは”4gA-LI-pd8.title”といった謎のオブジェクトIDとなっており、メンテナンスしていくのがなかなか大変なものでした。 それに対してコード上では、NSLocalizedString("key", "comment")といった形式で予めLocalizable.stringsに自分で設定したキーを使用することができました。 xib, storyboardでもコードと同じようにLocalizable.stringsを利用できるように、ls2xsというツールをつくりました。 https://github.com/ishkawa/ls2xs インスト
堅牢で使いやすいAPIクライアントをSwiftで実装したい
Feb 17, 2015 昨年末にはてなの@cockscombさんと@yashiganiさんがつくっていたSwiftでenumとジェネリクスを活用したかっこいいAPIクライアントを書くが 面白かったので、これを参考にしつつSwiftらしい堅牢で使いやすいAPIクライアントを考えてみました。 目標としたのは以下の3つの条件を満たすことです。 レスポンスはモデルオブジェクトとして受け取る (便利) 個々のリクエスト/レスポンスの定義は1箇所で済ます (変更しやすくしたい) リクエストオブジェクトはAPIクライアントから分離させたい 例にはGitHub System Status APIを使用しています。 サンプルコードはGitHubに上がっています。 APIクライアントのインターフェース APIの呼び出し用に用意されたメソッドはcallのみで、callに渡すリクエストによってレスポンスの型が変
Carthage: Swift対応の新しいライブラリ管理
Nov 20, 2014 iOS, OSXで利用できるライブラリ管理ツールといえばCocoaPodsが有名ですが、 それとはまた違った方針のCarthageというライブラリ管理ツールがリリースされました。 GitHubのデベロッパーを中心としたチームで開発が進められているようです。 https://github.com/Carthage/Carthage インストール方法 Releasesからpkgをダウンロードして、インストーラーを実行します。 使い方 Cartfileを書く carthage updateを実行する Carthage.buildに作成された.frameworkをXcodeに追加する Cartfileではgithub, gitの2種類のキーワードが利用でき、以下のように書きます。 サポート対象 Carthageはdynamic frameworkのみをサポートするため、C
auto_closureを利用して条件成立を待つXCTestExpectationをつくる
Jul 23, 2014 AppleのSwift Blogを読んで@auto_closureが面白そうだと思い活用方法を考えてみました。 @auto_closureはclosureを取る引数につけると、呼び出し側はclosureの{}を省略できるようになるというものです。 Swift Blogによると、AppleはSwiftでのassert()などの実装にこれを利用しているそうです。 今回はこれを利用して、条件が成立するまで待つXCTestExpectationを実装してみました。 以下のように使うことができます。 func testBlockOperation() { let queue = NSOperationQueue() let operation = NSBlockOperation(block: { NSThread.sleepForTimeInterval(1.0) })
すべてのテストケースの前後にあれこれする
iOSのアプリケーションテストを書いていると、各テストケースの前後に永続ストアやスタブサーバーなどをリセットしたくなることがあると思います。 リセットが必要なテストスイートのsetUp/tearDownに書いても良いのですが、書くのが面倒だったり書き忘れてしまうこともあるので、 すべてのテストケースについてリセットが走るようにしておいた方が心を穏やかにすることができると思います。 実現方法 すぐに思いついたのは以下のような方法です。 setUp/tearDownにリセット処理を加えたサブクラスを継承させる XCTestCaseのsetUp/tearDownをswizzleする サブクラスを継承させる方法には、KIFTestCaseなど他のライブラリのクラスには適用ができないという問題があります。 method swizzlingを利用する方法は、他のmethod swizzlingと衝突す
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
デバッグ中にJSONをサッと出力する
NSDictionaryやNSArrayのdescriptionはそれとなく見やすいフォーマットで出力されますが、JSONで欲しくなる場合があります。 しかも、デバッグ中に欲しくなったりします。 XcodeのLLDBは~/.lldbinit-Xcodeに独自のコマンドを定義することができるので、 pretty printedなJSONを吐くコマンドを定義してカジュアルにJSONを得られるようにしてみました。 1 command regex pj 's/^(.+)$/po [[NSString alloc] initWithData:[NSJSONSerialization dataWithJSONObject:%1 options:1 error:nil] encoding:4]/' ここで定義したpjコマンドを使うと以下のようなNSDictionaryから 1 2 3 NSDiction
xcodebuildのログをxcprettyで整える
Xcode 5になってからxcodebuildも進化していて、Xcode 4までネックになっていたApplication Testsの実行も簡単になりました。 そういうわけで自分にとってのxctoolの必要性は薄まり、あとはログさえキレイになってくれればいいのになあと思っていたのですが、そんなときにxcprettyが登場しました。 mneorr/XCPretty xctoolとの違い xctoolはxcodebuildを置き換えることを目的としていましたが、xcprettyはxcodebuildと共存してログの整形のみを行います。 xctoolの場合、”xcodebuildでは動くけどxctoolでは動かない”という状況に遭遇することがありますが、 xcprettyはビルドやテストの実行自体にxcodebuildを利用するので、既にxcodebuildで進んでいるプロジェクトでは簡単に利用
iOS開発でGitを利用する際のTips - blog.ishkawa.org
ちょっと今更な感じもありますが、iOS開発でGitを使うときのTipsを紹介します。 Gitそのものの使い方は理解している前提のもとで書きます。 バージョン管理する対象 Xcodeのプロジェクトにはバージョン管理する上で結構余計なものが入っています。 Gitで管理すべきでないもの Xcodeの作業データ Xcodeのプロジェクトは.xcodeprojですが、こいつ自身はディレクトリになっていて project.pbxproj project.xcworkspace xcuserdata というファイルが入っています。このうち、Gitで管理するべきものはproject.pbxprojです。 その他のものはXcodeの状態(グループを開いてるかなど)を管理しているものなので、 プロジェクトのバージョン管理対象としては適切ではありません。 ビルドデータ xcodebuildコマンドを実
Travis CIがXcode 5に対応してからのあれこれ
Xcode 5のxcodebuildでテストを実行するにはxcodebuild testを使うといいみたいです。 man xcodebuildのbuildactionの説明に以下のように書かれているので-scheme SchemeNameが必要となります。 Travis CIなどの手元以外の環境でbuild schemeを利用する場合には、他の環境でも同じbuild schemeを使えるようにする必要があるので、 あらかじめXcodeのManage SchemeというメニューのShareというチェックボックスを有効しておく必要があります。 This requires specifying a scheme and optionally a destination. Xcode 4のときにはMakefileを以下のように書いていましたが 1 2 3 4 5 6 7 test: xcodebu
単体テストの実行時に非同期処理を待つ
SenTestingKit/XCTestは非同期処理を待たずにテストケースを終了してしまうので、 直接SenTestingKit/XCTestを利用する場合には自分でNSRunLoopを回して処理の完了を待つ必要があります。 これまでSenTestCaseにfinishedフラグが追加されたサブクラスを使ったりしていたのですが、 どうしてもテストコードが明示的にならなくて悩んでいました。 いままで書いていたテストコードは以下のような感じです。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 - (void)testExample { // step 1 dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); dispatch_async(queue, ^
JSONにNSNullが入ってきたとき
多くのiOSアプリはサーバーとの通信が必要で、やりとりされるデータのフォーマットにはJSONが採用されることが多いと思います。 iOS 5からは標準ライブラリにNSJSONSerializationが導入され、特に理由がなければJSONのエンコード/デコードにはこれを利用します。 NSJSONSerializationが扱うオブジェクトは以下の5種類のオブジェクトです。 NSString NSNumber NSArray NSDictionary NSNull そこで心配になるのが、予期しないところにNSNullが入ってきて”unrecognized selector sent to instance.“となってしまうことです。 NSNullではなくてnilが入っていてほしいと考える人は多いようですが、そもそもNSArrayやNSDictonaryはnilを含むことはできず、 そのような状
#potatotips で隅々までタップできるUINavigationBarの話をしました
potatotipsというのはクックパッドさんが開催しているiOS/Android開発者のtips共有会です。 普段は社内のメンバーで定期的に行っているそうなんですが、今回は社外の開発者も含めて開催でした。 持ち時間は1人あたり5分と短かったので、すぐに活用できそうなtipsが多かったように思います。 話したこと iOS 7になってからUINavigationBarのcustomViewが中央寄りになってしまい、 バーの両サイドに配置されたカスタムボタンが押しにくいという問題が起きました。 これだけを理由にUINavigationBarを使うのを辞めるのはもったいないので、 customViewのフレームに影響されずに隅々までタップできるUINavigationBarを実現する方法を考えました。 実装のアイディアは結構単純で、customViewのフレーム外であってもタッチイベントの位置に
複数のiOSバージョンでのテストを自動的に実行する
Xcode 5になってxcodebuildコマンドも進化したらしいのですが、あまり変更を追えていませんでした。 今日、ぼんやりとman xcodebuildを眺めていたら-destinationというオプションをみつけました。 これを使えば任意のiOSバージョンでテストを走らせられるなと思ってやってみました。 はじめはXCTestで実行したかったのですが、iPhoneSimulator6.0.sdkやiPhoneSimulator5.0.sdkには xctestという実行ファイルが含まれていないため、以下のようなコマンドでテストを実行することができませんでした。 (OS=7.0だと実行できます。) 1 xcodebuild test -scheme Example -destination "name=iPhone,OS=6.0" OCUnitを実行するounitという実行ファイルはiPh
main queueのNSManagedObjectContextの話
ふとTwitterで@cockscombさんと@k_katsumiさんとCoreDataの話になって考えました。 これから書くことは正しさが曖昧なので、鵜呑みにしないように気をつけてください。 なお、マルチスレッドに関する話にはここでは触れません。 前提 CoreDataを使うときにNSManagedObjectContext, NSPersistentStoreCoordinator, NSManagedObjectModelを持つ、以下のようなsingletonを作ったことがあると思います。 こういう実装をすると確かに便利なんですが、共有されたNSManagedObjectContextが色んな所からアクセスされることになって、それをどうにかしたいなと思いました。 1 2 3 4 5 6 7 8 9 10 11 12 #import <Foundation/Foundation.h>
GHUnitをやめてSenTestingKitを使う理由 - blog.ishkawa.org
※ はじめにことわっておきますが、GHUnitを批判したくて書いているわけではなく、 SenTestingKitが意外と使えたということを書きたくて書いています。 – 特定のテストがターミナルから実行できないという問題に遭遇した。 GHUnitは新しいXcodeやiOS SDKが出たときに対応されるまでにラグがある。 やっぱりcommand+Uでマメにテストを実行したい。 SenTestingKitではできないと思い込んでいたことが実はできた。 以下、誤解していたことについて書きます。 SenTestingKitへの誤解 実機ではテストを実行できない。 UIKitが絡むテストは書けない。 非同期のテストが書きづらい。 実機での実行 SenTestingKitで実行できるテストにはLogic Unit TestsとApplication Unit Testsがあります。 前者は実機での実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gcovrでコードカバレッジを確認
ISPersistentStackというCoreDataのヘルパーを書いた