Xcode 7.2 の LLDB で Swiftのデバッグをするコツ
現在のXcode 7.2でSwiftを使ったiOSアプリのデバッグをするときのコツみたいなものをまとめました。将来的にはより良くなる可能性はあります。というか良くなってほしいです(´･_･`) ■LLDBはbreakした地点によって挙動が変わるまずハマりどころがこれですが、現在のLLDBはbreakした地点で実行されていたコードがSwiftのコードかC言語系のコードかによってモードが変わります。 // Objective-C mode (lldb) po [someObject property] // Swift mode (lldb) e someObject.property Objective-Cモードの時にSwiftっぽい呼び出しをしたり、その逆をしてもまともにLLDBは動作しません。なので現在自分がどちらのモードのLLDBにいるのかを判断するのがキモになります。 ハマりどころと
Silent Push / Background Fetch 時の fetchCompletionHandler に渡す引数ごとの挙動の違いを調べてみた
Silent Push / Background Fetch 時の fetchCompletionHandler に渡す引数ごとの挙動の違いを調べてみた 2014/09/10追記: 追加調査によって判明した事項を追記しています。 iOS 7から追加されたPush通知によるバックグラウンド処理機能 (Silent Push) および定期的なバックグラウンドフェッチ機能 (Background Fetch) ですが、これらの機能はバックグラウンド処理が完了したタイミングでいずれもfetchCompletionHandlerにUIBackgroundFetchResult型の値を渡すような設計になっています。 ちょっと調べれば、大体どこの解説サイトにも以下のように説明があります。 UIBackgroundFetchResultNewData 新しいコンテンツの取得に成功し、新しいデータが存在した
Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた
Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた iOS 7以降とiOS 6以前で、俗にいうリモートPush通知の受け取り方と受け取った際の挙動がまるで違っているので、最近リモートPush通知を実装した時につまづいた箇所をまとめてみました。 使用するdelegate methodの違い いかなる種類のPush通知においてもapplication:didReceiveRemoteNotification:fetchCompletionHandler:を使用します。 application:didReceiveRemoteNotification:fetchCompletionHandler:とapplication:didReceiveRemoteNotification:が両方実装され
Parse.com の Cloud Code ハマりどころ
Parse.comのCloud Codeを触っていてハマった点や気づきにくい仕様を列挙させて頂きます。 ■Parse.Cloud.useMasterKeyを呼び出すことで特権ユーザー権限になれるCloud Code上でACLによるアクセス制限を無視して現在のrequest.userとは関係なしにデータを操作したいということが多々あるかと思います。そのような場合は以下のようにリクエスト処理の先頭でParse.Cloud.useMasterKeyメソッドを呼び出してください。 useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。 ■Parse.Cloud.beforeSaveやParse.Cloud.afterSaveはData Browserから直接Rowを追加した場合にも呼び出されるこれは意外とハマりどころです。例えばData BrowserからUserを
UIBarButtonItem の見た目を画像にしたいときのテクニック
iPhoneアプリでよく使われる、ナビゲーションバーに配置するボタン UIBarButtonItem の見た目を完全に画像にする時のテクニックです。 参考にしたページはこちら。 http://discussions.apple.com/thread.jspa?threadID=1505647 http://www.iphonedevsdk.com/forum/iphone-sdk-development/13809-uibarbuttonitem-customview-action.html http://discussions.apple.com/thread.jspa?threadID=1546506&tstart=60 ■作戦１：initWithImage てか、 UIBarButtonItem には initWithImage あるからそれでいいんじゃないか、と思ってさっそく以下の
__has_feature(objc_arc_weak) を使って賢く安全に ARC/Blocks を使う
iOS 6も発表されて、皆さんARCやBlocksをガンガン使用する感じのプログラミングスタイルに変化してきていると思うのですが、そこで問題になってくるのが後方互換性の話です。特にiOS 4。Blocksを使うとなるとどうしても以下の様に非同期で実行されたBlocksの中からViewを書き換えるようなコードを書きたくなるのですが、 __weak MyViewController *__weakSelf = self; [NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse* response, NSData* data, NSError* error){ __weakSelf.label.text = [[NSS
Jenkins を iOS アプリ開発に導入してみた (GHUnit編)
前回 はSenTestKitを用いてJenkins上で単体テストの自動実行を行いました。今回はGHUnitを使った単体テストの自動実行にチャレンジしてみたいと思います。またついでといっては何ですが、単体テスト時に必要になってくるモックを作成するためのライブラリOCMockも同時に導入してみようと思います。 ■なぜGHUnitを使うのか GHUnitを使うことで、SenTestingKitと比べて以下のようなメリットが得られます。 非同期処理のテストを行うための仕組みが用意されている（GHAsyncTestCase）これをSenTestingKitないし他のテスティングフレームワークでやろうとすると大変骨が折れます。 .app形式（要するに実際のiOSアプリケーション）でテストを実行するため、UIApplicationやUIWindowといったUIコンポーネントを使うクラスのテストが可能にな
UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
