Xcode 8.3 & Swift 3.1 環境で LLDB を使う Tips
以前も似たような記事書いた気がするんですが、定期的にSwiftのコード上でLLDBを使ってて困ることがあるので定期的に書くことにします。ほとんど https://stackoverflow.com/questions/29441418/lldb-swift-casting-raw-address-into-usable-type からの転載です。 LLDBの言語を指定して実行する標準ではbreakpointを挟んでbreakした行がSwiftであればSwift、Objective-CであればObjective-CでLLDBの言語が選択されるようなのですが、これでは毎回毎回breakした地点に応じてデバッグの仕方が変わって大変で仕方がないので、Swiftに統一してしまうのが良いと思っています。 expr -l swift -- {Swift Command} e -l swift -- {S
iOSのフォントのお話
最近フォント周りについて深く掘り下げる機会がありましたので、その際のメモを残しておこうと思います。かなり読む人置いてけぼりな中身になってますが、フォントを詳しく触り始めるとなるほどーとためになる（と思う）のでどうかご了承ください(´･_･`) UIFontのプロパティについて UIFontにはフォントに関する数値を表すプロパティが存在します。いろいろありますが、もっとも重要なのは以下に列挙するプロパティです。 pointSize lineHeight ascender descender leading capHeight 以下の画像を見ると非常にわかりやすいかと思います。 参照元: https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/Cus
Asset Catalog を使用しているときは [UIImage imageNamed:] が遅くなることがある
タイトルのとおりですが、本日発見してひどくパフォーマンスに影響が出たため注意喚起を兼ねて共有いたします。 最近のiOSプロジェクトは全て画像をxcassetsすなわちAsset Catalog経由で管理することが多いかと思いますが、このAsset Catalogを使用している際に[UIImage imageNamed:]経由で画像を取得するとiOS 8以前とは異なり大変画像の取得が遅くなることがあるようです。 詳細はこちら。 https://forums.developer.apple.com/thread/17888 実際に私の環境では目に見えて遅くなりました。Instruments経由で計測したところ最大で10倍ほど差が出ているように見えました。iOS 9.1以降は修正されているとのことですが、それでも[UIImage imageNamed:inBundle:compatibleWit
![Asset Catalog を使用しているときは [UIImage imageNamed:] が遅くなることがある](https://cdn-ak-scissors.b.st-hatena.com/image/square/f67ee108b30759b1317d2d9aed59cc5f0932480c/height=288;version=1;width=512/http%3A%2F%2F1.bp.blogspot.com%2F-i5FR1wVEKH0%2FU-njiIkVrUI%2FAAAAAAAAC88%2F_BdfUwQVKbE%2Fs72-c%2F%25E3%2582%25B9%25E3%2582%25AF%25E3%2583%25AA%25E3%2583%25BC%25E3%2583%25B3%25E3%2582%25B7%25E3%2583%25A7%25E3%2583%2583%25E3%2583%2588%2B2014-08-12%2B18.50.52.png)
レガシーな Objective-C プロジェクトを Swift なプロジェクトに変換する
ここで言うレガシーなObjective-Cプロジェクトの定義とは iOS 7時代 (Xcode 5) より前に作成されたプロジェクトである Swiftのコードを一行も含んでいない IOS_DEPLOYMENT_TARGETが8.0よりも小さい (7.xをサポートしている) とします。 こんな由緒正しいiOSのプロジェクトを未だにメンテしている人もなかなかいないのかと思いますが、もしいらっしゃいましたらそんな方のためにSwiftなプロジェクトに変換していく方法をメモしておきます。 ■前提条件 まずIOS_DEPLOYMENT_TARGETを8.0以上にしましょう。IOS_DEPLOYMENT_TARGETを8.0以上にすることでdynamic frameworkおよびclang moduleが使えるようになるため、Objective-CとSwiftの間の垣根が非常に低くなります。 ■ケース1
iOS でヒラギノフォントが明示的に指定された時に描画サイズの計算が正しくならない問題を修正する
タイトルからして出落ち感が少々ありますが・・・ iOSのフォントサイズ計算には長年修正されないバグというか仕様がございまして、「ヒラギノフォント（ヒラギノ角ゴシック、ヒラギノ明朝等）」が明示的に[UIFont fontWithName:size:]で指定されたとき、そのフォントを使ったUILabelやUITextViewなどの描画サイズの計算が正しくならない問題があります。iOS 6からiOS 9.1現在に至るまでずっとなので今後も直ることはないと思います。 詳細についてはこちらの記事が詳しいです。 http://qiita.com/yusuga/items/2be8c55ca561bba44702 一番下のリンク先の記事でも同様の問題が訴えられていまして、それぞれ対策が記載されていますので合わせてご参照ください。 でまぁ、対処法としてはいくつかあります。 UIControl.conten
A-Liaison BLOG: AppBank GAMESを退職していました
表題の件、私akisuteは2013年10月末日を持ちましてAppBank GAMES株式会社を退職したことをご報告いたします。短い間ではございましたが関係者皆様大変ありがとうございました。今後の予定につきましてはとりあえずのところ問題なくやっていけそうで助かっております。 ところで、せっかくの退職エントリですので感慨深いものですし、ここはひとつ昔話などをしたいと思います。 まずはAppBank GAMESの軌跡を年表にして振り返ってみました。 2012年2月 AppBank GAMESがスタートしました。2012年4月 最初の退職者が現れました。2012年夏 第一次反乱が発生しました。2012年7月 G君という大変優秀なレベルデザイナーがジョインしました。2012年10月 Dungeons and Golfの追い込み時期にとある出来事が発生しました。2012年12月3日 Dungeons
Apple Watch の実機を触ってわかった、アプリ開発者が抑えておくべきポイント
本日からついにApple Watchの実機がお目見えとなりました。私も早速Apple Storeに行って試着・試用してきたのですが、予想以上にアプリ開発に影響がありそうな点が多数見つかりましたので、思うところをブログ記事にまとめて公開しようかと思います。 ■小さい、とにかく小さい Apple Watchの実機を身につけてまず最初に感じるのがその圧倒的な小ささです。この小ささというのは これまでのAndroid Wearデバイスのどれと比べても感じる相対的な小ささ Apple Watch上で表示されているUIを見て感じる絶対的な小ささ の2つの要素から感じられます。 試しに私が身につけているAndroid WearデバイスとApple Watch Standard 42mmを並べて写真をとってみたのですが、見ての通り42mmモデルですら表示領域がずいぶんと小さいのがわかります。 その上App
Swift から Core Data を操作するときはこの2点だけ気をつけよう (Xcode 6 beta 7編)
将来的にXcode側の対応が変わる可能性が極めて高いので暫定ですが、Xcode 6 beta 7でSwiftからCore Dataを触った時に注意するポイント2点まとめです。この2点にだけ気をつければSwiftでもCore Dataは案外あっさり動きますのでご安心ください！ 1. プロパティの設定の仕方 @NSManagedを使うこと Int, BoolではなくNSNumberを使うこと。StringはStringでOK Many関連にはNSSetを指定すること 2. entityNameの与え方 コード上ではクラス名だけを与える Model Editor上ではモジュール名.クラス名（完全修飾名）を与える
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:が両方実装され
既存の Objective-C のメソッド引数の Swift 上での扱われ方を調べてみた
前置き こちらの記事には2014/06/09現在、公式にはリリースされていないiOS8プレリリースドキュメントへのリンクが含まれます。iOS8にて新しく追加された内容には一切触れておらずAppleとのNDA規約にも違反するものではないという認識ですが、場合により予告なく削除する可能性があります。予めご了承ください。 本題 iOS8プレリリースドキュメントを眺めていて気になったのですが、ほとんどのCocoaのメソッドの引数に!がついています。例えばNSKeyValueObservingプロトコルのaddObserver:forKeyPath:options:context:メソッドのシグネチャは以下のようになっています。 func addObserver(_ anObserver: NSObject!, forKeyPath keyPath: String!, options options
Swift で __conversion メソッドを使ってカスタムの型変換を定義する方法
2014/10/21追記: Xcode 6.0 beta 6以降、__conversion()を使った暗黙的なas演算子を用いた型変換はサポートされていません。Xcode 6.1(Swift 1.1)現在、暗黙的な型変換を行う手段はないため、型変換を行いたい場合はイニシャライザを定義する方法を取るのが通例として良いと思います。 class 変換対象の型 { init(_ obj: 変換元の型:) -> 変換対象の型 { return 適当に変換対象の型を返す } } Swiftではas演算子を使ったり、型の定義されている変数・定数へ代入したり、メソッド呼び出しの引数にオブジェクトを渡す際に型変換が行われますが、デフォルトでは対応していない型変換があったりします。例えばStringはasを使ってもIntに変換することはできません。 また、SwiftではnilはNilTypeという型のシングル
Swift の enum型を for-in でイテレーションする方法
例えばJavaのEnum型などはそのまま以下のようにイテレーションすることが可能なのですが、 なぜかSwiftのenum型はそのままではイテレーションすることができません。対策としてGeneratorという仕組みが標準ライブラリに用意されてますので、それを使ってenumをイテレーションできるようにします。 具体的には、Generatorを継承したクラスを作成して next() -> Element? を実装してください。ElementはAnyObjectのtypealiasなので実際には好きな型を返していただければOKです。あとはSequenceOf<T>型でGeneratorをラップしてあげればOKです。next()メソッドがnilを返すまでSequenceOf<T>はイテレーションを続けてくれます。 以下にサンプルコードを示します。 Generator内部でyieldが使えれば便利なん
xxd を使って画像などのバイナリデータをソースコードに含める方法
iOS向けのライブラリやフレームワークを作成しているときに、どうしても画像などのバイナリデータをライブラリやフレームワークに含めたくなる時があります。たとえばUI系のフレームワークなどですね。このようなときに、たとえば静的ライブラリ（.aと.h）やフレームワーク（.framework）とセットで画像を一緒に同梱し、ユーザーのXcodeプロジェクトに一緒に含めてもらうという方法もあるのですが、この方法だと画像名がユーザーのプロジェクトに含まれている画像とかぶったりしてはいけませんし、管理が面倒になってしまいます。また、ライセンスがプロプライエタリなライブラリでは、画像などのリソースをあまり積極的にユーザーに公開したくないというニーズがあったりします。 そこでxxdツールのご紹介です。岸川先生に教えていただいたのですが、xxdというツールを使えばバイナリデータをC言語のヘッダファイルとして簡単
Jenkins を iOS アプリ開発に導入してみた (SenTestKit編)
最近、iOSアプリの開発でも継続的インテグレーション(CI)を取り入れていくプロジェクトが増加傾向にあるようで、各種ツールやライブラリ、ノウハウが出回ってきているように感じられます。そこで私も早速iOSアプリ開発でのCI導入を試してみることにしました。今回の導入試験では、以下のような環境を想定して行いました。 iOSアプリの開発を、Xcode 4.X系のプロジェクトとして行う。 VCSにはgitを採用し、githubの公開リポジトリをリポジトリサーバーとして使用する。 CIサーバにはMacを採用し、プロジェクトをビルドするためにXcode 4.Xをインストールしておく。 ■必要なツールを準備する CIといったら、まずは何はなくともJenkinsです。 http://jenkins-ci.org/ ここでは導入について詳しくは挙げませんが、私は以下の本を参考にしました。 https://gi
UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
Xcode のビルド設定で $(inherited) を使って設定を継承する
AppleのXcode 2のころのドキュメントによるとXcodeのビルド設定は以下の順に設定内容が解決されていきます。ユーザーのデフォルトの環境変数設定（たいていは ~/.MacOSX/environment.plist で指定されている）Xcodeのビルトインデフォルト設定Xcodeのアプリケーション設定（これはXcode 4では廃止されている気がします）ベースとなるビルド設定ファイル（元のドキュメントには書いてありませんが、.xcconfigファイルを使ってビルド設定を指定可能です）プロジェクトのビルド設定ターゲットのビルド設定コマンドラインから起動した場合は、コマンドラインのビルド設定フラグの値このとき、下位の設定は上位の設定を上書きして使用するようになっているのですが、ここで上位の設定をそのまま受け継いで使いたい場合には、設定項目に$(inherited)という特殊な値を指定するこ
LLVM compiler 2.0 (clang 2.9) で linker にパスを出力させる方法
Xcode 4 から使えるようになった LLVM compiler 2.0 (clang 2.9) の覚え書きです。リンカにパスを出力させる方法を調べてみました。 ※ clang 2.8 じゃなくて 2.9 がベースになってるみたいです。ごめんなさい＞＜ 方法は簡単。ビルド設定中のOther Linker Flags (OTHER_LDFLAGS) に、-v -Xlinker -vまたは-v -Wl,-vを与えればOKです。 ほいごらんのとおり。 gcc 4.2 または LLVM gcc 4.2 を使っているときは、 gcc がコンパイルして ld でリンクするようになっていましたが、 clang を使うときは clang が一人でコンパイルして一人でリンクまでやってしまいます。そのため、これまで通り普通に-vを渡しただけではうまくいきません。これだと、単に clang が verbose
Python で Xcode のビルドスクリプトを書く方法
以前こんな記事を書きましたが、今回はもっと実践的なお話。PythonでXcodeのビルドスクリプトを書いてハッピーになろうというお話です。 ■なぜXcodeのビルドスクリプトを書くのか Xcodeのビルド機能だけでは出来ないことをやりたいからです。たとえば、特定のディレクトリの中に入っているリソースを、ビルド時にアプリにパッケージングしたい。ビルドする前に、特定のリソースを暗号化して、アプリにパッケージングしたい。といった要望が結構ありますが、これらはビルドスクリプトを使えば簡単に可能になります。 手でいちいちやるより楽で安全ですね。 ■なぜPythonか 理由はいくつかあります。Windows, Mac, Linux, 全ての環境で動く。したがって、万が一のときにはビルドスクリプトだけを移植できる。sh とか csh とか非力すぎてやってらんない。 zsh もつかえるけど Python
lipo を使って簡単に Universal Binary を作成する方法
iOS 向けのライブラリやフレームワークは、よく static library (.aファイル) の形式で配布されています。これは iOS がユーザーが作成した dynamic library (.dylibファイル) や framework バンドルをサポートしていないからなのですが、ときどきこの static library がシミュレーターとデバイス両方で使える形式、いわゆる Universal Binary になっていない場合があります。 たとえばこんな感じですね。 この状態でビルドを行うと、シミュレーター向けビルドを行えばデバイス用のバイナリが、デバイス向けビルドを行えばシミュレーター用のバイナリが、それぞれ対応していないアーキテクチャであると警告を出してしまいます。警告ですからコンパイルは通るのですが、私は几帳面で気になってしまうので、これを解消したいと考えます。 ■lipoの
Android のメモリ管理は大変です
■理想 AndroidってJavaだからメモリ管理なんてしなくてもいいよね！！ なんて思っていた時代が私にもありました・・・ ■現実 @Override protected void onDestroy() { super.onDestroy(); // 画面が回転した時など、Activityが破棄されるときに呼び出されます // すべてのメモリはここで開放します // - 特に危険なのが内部クラス（MyWebChromeClientなど）、正しく開放しないとActivityが開放されません // - セットしたbackgroundのcallbackもnullにしないと開放が行われません // - webViewのdestroy()を忘れると後からGCが走ったときにVMがクラッシュします this.webView.stopLoading(); this.webView.setWebChro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
