try! Swift 2024 「Accessibility APIを使ってアプリケーションを拡張する」 - 24/7 twenty-four seven
先日のtry! Swift 2024にて「Accessibility APIを使ってアプリケーションを拡張する」という発表をしました。 tryswift.jp スライド: speakerdeck.com 台本とアニメーション付きのスライド: github.com サンプルコード: github.com 講演のビデオ: youtu.be Accessibility APIとはUIテストや自動化システムなどで使われている、別のプロセスからアプリケーションの情報を読み取ったりボタンを押したりなど操作することができるAPIです。 スクリーンリーダーやボイスオーバーなどで自身のアプリケーションを操作可能にすることもAccessibility APIの役割ですが、今回は自身をアクセシブルにすることではなく他のアプリケーションを操作することで機能を付け足したりできる、ということを題材にお話ししました。
Apple IDの2ファクタ認証をCI環境で突破する - 24/7 twenty-four seven
【注意】この記事で紹介しているSMS APIサービスのVonageは利用規約により認証にVonageの電話番号を利用することを禁止しているという記述があるので、末尾の別解として載せたAndroidデバイスを使ってSMSを転送する方法が良さそうです。 help.nexmo.com 2021年2月から、App Store Connectにログインする際にすべてのApple IDで2ファクタ認証が必須になります。 Starting February 2021, additional authentication will be required for all users to sign in to App Store Connect. This extra layer of security for your Apple ID helps ensure that you’re the only
iOSDCでテストしづらいコードをテストしやすくするための方法について話しました - 24/7 twenty-four seven
speakerdeck.com 日本で開催されるもっとも大きなiOSに関するカンファレンスの１つであるTop | iOSDC Japan 2017に参加し、表題の内容で発表しました。 聴いてくださった方々からは好評のようでよかったです。発表資料は本題と関係のない話がちょこちょこ挟まったり、口頭の説明がないとわからないページがあり、スライドだけでは意図がよく伝わらない恐れがあるので、こちらで内容について補足します。 伝えたかったテーマは「依存が大きく複雑で、単体でテストしづらいコードを単体で動かしてテストできるようにするには」ということです。その題材として一般的に依存が複雑でテストしづらいコンポーネントであるビューを例として取り上げました。ですのでビューやUIをテストするということに絞った話ではなく、どのレイヤーに対しても複雑にいろいろな依存関係があってユニットテストが書けないという状況を改
try! Swift Tokyo 2017をもっと楽しむために - 24/7 twenty-four seven
いよいよ明日はtry! Swift Tokyo 2017が開催されます。 try! Swift Tokyo 2017を最大限楽しんでいただくために、ちょっとしたコツをお話しします。 公式アプリ try! Swift公式アプリがAppStoreから配信されています。タイムテーブルやセッション概要などが掲載されていますので、事前にインストールしておきましょう。Apple Watchを持っていれば時計の文字盤に情報を表示することもできます。 try! Natalya Murashevソーシャルネットワーキング無料 ソースコードはこちらです。興味のある方はPRを送ってください。 github.com github.com 公式Slackチャンネル 参加者のみなさんをtry! SwiftのSlackチャンネルにご招待しています。もし、招待メールが届いていない方は info@tryswiftconf.
try! Swift Tokyo 2017を開催します - 24/7 twenty-four seven
try! Swiftは世界中のSwiftデベロッパーが一堂に会し、Swiftに関する知見を共有するカンファレンスです。国内外からSwiftデベロッパーが参加する、世界最大級のコミュニティでもあります。 会期は2017年3月2日〜4日の3日間、うち2日、3日は招待講演とライトニングトーク、4日はハッカソンを行います。 TOKYO - try! Swift 今回はより多くの方に来場していただけるように広い会場を確保しました。およそ前回の1.5倍（800〜900人）の方にお越しいただけます。 すべての講演とQ&Aにはプロによる同時通訳を提供いたしますので、英語に自信がなくても問題なく楽しんでいただけます。 現在(Webサイト)https://www.tryswift.co/tokyo/jpには18名の講演者が掲載されていますが、さらに4名、合わせて22名の講演を予定しています。 たとえば、Fas
懇親会における英会話のプロトコル - 24/7 twenty-four seven
前回の記事では、カンファレンスをより楽しむために積極的に人と（特に海外の人と）話そうと書きました。しかしそうはいっても、言葉に自信がなかったりしてなかなか積極的に話しかける勇気が持てないかもしれません。 でも心配いりません。懇親会（ミートアップ）の会話はほとんど決まった形で始まるので、それを覚えておけばとりあえずなんとかなります。 挨拶と自己紹介のプロトコル とりあえずこの手順だけ覚えておきましょう。以下の流れから外れることは90%ありません。 （相手を見て）声をかける「Hi」 名前を言う。「I'm Katsumi」／「My name is〜」 「どこで働いてる/何をしている」か聞かれるので答える。「I'm iOS developer, work at Realm」／「I'm working at Realm. I develop〜」 要するに、1. 声をかけて、2. 名乗って、3. 自己
try! Swift 2016を200%楽しむために - 24/7 twenty-four seven
いよいよ今週はtry! Swift 2016が開催されます。 せっかくの機会ですので貴重なチケットを手に入れられた方にtry! Swift 2016を最大限楽しんでいただくために、ちょっとしたコツをお話しします。 公式アプリ try! Swift公式アプリがAppStoreから配信されています。タイムテーブルやセッション概要などが掲載されていますので、事前にインストールしておきましょう。Apple Watchを持っていれば時計の文字盤に情報を表示することもできます。 try! Natalya Murashevソーシャルネットワーキング無料 公式Slackチャンネル 参加者のみなさんをtry! SwiftのSlackチャンネルにご招待しています。もし、招待メールが届いていない方は info@tryswiftconf.com にご連絡ください。Slackでは自己紹介や、質問など、自由に参加者お
24/7 twenty-four seven
BenQからモニターライト「ScreenBar Pro」の提供とレビュー依頼を受けたのでレビューします。 ただ、私はMacBookしか使わないので、商品はnoppeさん（https://x.com/noppefoxwolf）に進呈してレビューを書いてもらいました。 以下、noppeさんの文章です。 BenQは、プロジェクターや液晶モニターなど快適なデスク環境を提供する製品を販売しています。今回は、先月発売されたばかりのモニターライト「ScreenBar Pro」をレビューします。 BenQ ScreenBar Pro モニターライト/輝度．色温度調整/省スペース/湾曲モニター対応/広範囲照明/目に優しい/映り込み軽減/省スペース/PC作業/USB Type-C/在宅勤務 BenQAmazon 以前から同社の「ScreenBar」を愛用していましたが、「ScreenBar Pro」は広範囲の
UIKeyCommandを使ってバーコードリーダーの入力を受け取る - 24/7 twenty-four seven
TL;DR ●バーコードリーダーは外部キーボードとして扱える ●UITextFieldなどの入力コンポーネントを使って入力を受け取れる ●UITextFieldなどを使いたくない場合がある ●UIKeyCommandを使うと入力コンポーネントを使わずに入力を受け取れる ユビレジでは商品の入力に市販のバーコードリーダーを利用することができます。 一般的なBluetoothのバーコードリーダーはHID(Human Interface Device)とSPP(Serial Port Profile)の両方のプロファイルに対応しています。 HIDとして接続する場合は外部キーボードと同じ扱いになります。 外部キーボードが繋がっているのと同じなので、UITextFieldやUITextViewを使って特別なSDKを必要とせずに入力を受け取ることができます。 ただし、このやり方は簡単なのですが、入力を受
Swiftで使いやすいAPIを書くために気をつけていること - 24/7 twenty-four seven
先日iOSオールスターズ勉強会でSwiftでライブラリを書く際に良いと思ってることについて話しました。そこで好評だったり同意してもらえた何点かについてあらためてまとめます。 オーバーロードを積極的に活用しよう Swiftではメソッドのオーバーロード（引数の数、型、および戻り値の型が異なる同じ名前のメソッドが定義できる）が言語仕様としてサポートされています。これは上手に使うと利用する側にとってとても書きやすくなるので積極的に使っていきましょう。 例えば下記のような例では、Objective-Cではデータ型によって複数のメソッドを使い分ける必要がありました。 （引数の型がNSStringかNSDataかでメソッドの名前が異なる） - (BOOL)setString:(NSString *)string forKey:(NSString *)key; - (BOOL)setData:(NSDat
コマンドラインからiOSアプリケーションをiTunes Connectにアップロードする - 24/7 twenty-four seven
参考 Testflight build notes via iTMSTransporter [self reloadData];: Automatic app creation and binary upload Command upload App/Ipa to the iTunes Connect App Store Redesign of itunes connect · Issue #38 · kovpas/itc.cli · GitHub TL;DR Xcode（厳密にはApplication Loader）に付属するiTMSTransporterまたはaltoolを使います。 上記のリンク先を見ればだいたいわかります。 altoolのほうが直感的なコマンドで簡単です。 iTMSTransporterはそもそもゲームのアイテムなど大量のIn-App Purchaseのメタデータを
Travis CIでビルドごとにiTunes ConnectのValidationを自動的に実行する - 24/7 twenty-four seven
コマンドラインからiOSアプリケーションをiTunes Connectにアップロードする - 24/7 twenty-four seven ↑ こちらの記事で書いたように、コマンドラインからiTunes Connectへのアップロードや、バリデーションができるのを利用して、Travis CIを使ってビルドするたびに自動的にバリデーションを実行するようにしました。 これにより、プライベートAPIを利用していたり、必須なサイズのアイコンやLaunchImageが無いなどの理由でバリデーションエラーになってアップロードが失敗するということが未然に防げます。 ARCを使う場合、ヘッダに載っていないメソッドを呼ぶのはコンパイルエラーになるので、知らずにプライベートAPIを使ってしまうようなことは現在はほぼありません。 しかし、iTunes Connectのバリデーションはあまり賢くないので（おそらく
Travis CIでiOSアプリのリリース作業を自動化する - 24/7 twenty-four seven
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル（dSYM）をアップロードする 5. 2のバイ
通知センターから今日やるアニメをサッと確認できる「今日のアニメ」をリリースしました - 24/7 twenty-four seven
iTunes の App Store で配信中の iPhone、iPod touch、iPad 用 今日のアニメ ※ 通知センターに表示できるのはiOS 8を使っている場合だけです iOS 8から通知センターに任意のウィジェットを表示することができるようになりました。 通知センターといえば、ロック画面、ホーム画面に次ぐ一等地であり、そこをほぼ自由に使える存在というのはかなりすごいことで（ホーム画面はそもそも開放されてない、ロック画面は制限付き（通知とPassbook, iBeaconなど））、間違いなく戦争が始まるので、今のうちにいろいろ確認しておくべきだろうと考えて作ってみました。 ↑ アプリケーションとしては通知センターに今日放映されるアニメ番組表を表示するというものです。 どこからでも（ロック画面からでも）サッと呼び出せるので、まあ必要なひとにはそれなりに便利かと思います。 で、まあ
iOS 8 beta5にてポップオーバーをキャンセルするための暗いところを連続でタップすると下にあるモーダルビューも閉じてしまうバグ - 24/7 twenty-four seven
一昨日くらいにiOS 8でテストをしていたら見つけました。 問題となる画面構成を多用するアプリケーションにとっては、修正が間に合わなければけっこう致命的と思われるので共有します。 （Base SDKをiOS 8にしてビルドしない限りは起こりません。リリース済みのアプリケーションをiOS 8で動かすぶんには問題無いです。） ↓ バグレポートした内容は下記の記事で公開しています。 重ねてレポートすると優先順位があがるかもしれません。 Radar: When double-tap the dimming view to dismiss the popover, it will also close modal view under - 24/7 twenty-four seven サンプルコード ↓ バグレポートに添付した問題が再現するサンプルコードです。 Xcode 6でビルドして、iOS 8
Travis CI (Pro) の実行をジョブの並列化とBundlerとCocoaPodsのキャッシュで速くした - 24/7 twenty-four seven
ユビレジではTravis CIを使って、テストの実行とベータ版のTestFlightへのアップロードを自動化しています。 Pull Requestが送られた時と、マージされた時に自動でマージした結果のベータ版が配布されるので、手元で変更をすぐに試すことができて便利です。 【参考】 Travis CIでiOSアプリのテスト＆ベータ版の配信に使っているRakefileを改善したメモ - 24/7 twenty-four seven ユビレジのiPadアプリのCI環境をJenkinsからTravis CIに移行したときのまとめ - 24/7 twenty-four seven ただ、これは導入当初からあった問題なのですが、Travis CIにジョブが登録されてから終了するまで、だいたい20〜25分くらいと、少し時間がかかるのが気になっていました。 そこでジョブの並列化と、BundlerとCoco
iOS 8でIn-App Purchaseの状態に追加されるSKPaymentTransactionStateDeferredの影響を考える - 24/7 twenty-four seven
In-App Purchaseでプロダクトの購入を扱うときにはStoreKitのSKPaymentTransactionStateを使います。 例えばPurchasedなら購入完了なのでプロダクトのダウンロードを始める、Failedなら失敗なのでアラートを出すなどとします。 iOS 8からはその状態に新しくSKPaymentTransactionStateDeferredが追加されます。 2014/8/6時点ではまだドキュメントに解説はありません。 API diffとヘッダには記載されています。 WWDCのセッション218, 303ではそれなりに詳しく解説されていますので参考になると思います。 Deferredという状態は「Ask to Buy」というiOS 8のApp Storeの新機能のために導入されました。 「Ask to Buy」はiOS 8で搭載される「ファミリー共有 (Fami
Storyboardを1画面ごとに分割した話 - 24/7 twenty-four seven
今年の5月くらいの話なのですが、ユビレジのiPadアプリケーションのプロジェクトで使っているStoryboardを基本的に1画面（≒1 View Controller)の単位に分割するということをしました。 1画面1Storyboardメソッドについてはnakiwoさんが書かれた記事も参考になります。 1画面から始めるStoryboard - Cocoaメモ ↑ 上記の資料はどちらかというとStoryboardを使い始めるにあたって、１画面単位で少しずつ使っていこうという感じですが、ユビレジではもともとほぼ全部の画面がStoryboardになっていました。 ただ複数人で共同作業をするにあたっては、1画面単位を1ファイルにしておくくらいがメンテナンスしやすいんじゃないかなあという結論になったのでしばらくそういうふうに運用することにしました。 また、XIBと違ってStoryboardは単純にコ
Travis CIでipaを作るときのCode Signが失敗するのを修正したメモ - 24/7 twenty-four seven
一週間ほど前から（おそらくTravis CIの環境がXcode 5.1に変わってから）Travis CI上でipaファイルの作成に失敗するようになってしまって、TestFlightにベータ版を自動的にアップロードすることができなくなっていたのを昨日ようやく直したのでメモ。 ↓ということで以前に書いた記事はちょっと古くなってしまいました。 本文はそのままですが、参照先のgistの内容はアップデートしてあります。 ユビレジのiPadアプリのCI環境をJenkinsからTravis CIに移行したときのまとめ - 24/7 twenty-four seven 失敗している箇所のエラーメッセージは下記の通り。ipaを作る前の、プロジェクトのビルドでコード署名をするところで失敗しているけど、これだけだと原因がよくわからないのでまず手元で同様のメッセージが出る状況を再現することを実行しました。 
NSArrayやNSDictionaryからNSNullを効率よく取り除く - 24/7 twenty-four seven
iOSアプリケーションでWeb APIから返ってきたJSONを処理するのにNSNullの扱いに困っていて、事前にNSNullを取り除いてしまうのが事故を防ぐための確実な方法なのですが、再帰的にすべての要素を検査する以外になにかいい方法がないかと思って考えていたらちょっとおもしろい方法を思いついたので書いてみました。 kishikawakatsumi/CollectionUtils · GitHub ↑ に含まれるCUCompactArrayとCUCompactDictionaryです。 NSArrayとNSDictionaryのサブクラスとして実装されていて、次のようにして生成します。 （普通にalloc/initを使って生成することも可能です） NSArray *array = @[@"0", @"1", [NSNull null], @"2", [NSNull null], @"3"]
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
