‘iOS’ カテゴリーのアーカイブ

Fastlaneの基本 〜構造を知る〜

iOSアプリ生成時のコストを下げる事を目標にFastlaneを勉強中なのですが、
検索かけてもなかなかまとまった記事が見つからないので
自分の脳内整理の為に簡潔にまとめてみました
テスト用ということで、まずViewControllerを1つ用意したFastlaneTestというプロジェクトを作り、
Fastlaneをインストールして早速動作確認
Fastlaneファイルの基本構造こんな感じ

1 fastlane_version "1.81.0"
2 default_platform :ios
3
4 platform :ios do
5 before_all do
6 say ["before all"]
7 end
8
9 desc "テストですよー"
10 lane :test do
11 say ["テストですよー"]
12 end
13
14 desc "テストですよー2"
15 lane :test2 do |options|
16 say [options[:hoge]]
17 end
18
19 after_all do |lane|
20 say ["after all"]
21 end
22
23 error do |lane, exception|
24 say ["エラー"]
25 end
26 end

fastlane [lane名]で実行します
そうするとbefore_all→[lane名]→after_allの順番で走ることがわかります
因みにsay[]はボイスが流れるactionです
エラーが発生した場合はerrorの中身が走り、after_allは実行されません

test:fastlane test$ fastlane test
[12:06:55]: -------------------------------------------------
[12:06:55]: --- Step: Verifying required fastlane version ---
[12:06:55]: -------------------------------------------------
[12:06:55]: fastlane version valid
[12:06:55]: ------------------------------
[12:06:55]: --- Step: default_platform ---
[12:06:55]: ------------------------------
[12:06:55]: Driving the lane 'ios test' 🚀
[12:06:55]: -----------------
[12:06:55]: --- Step: say ---
[12:06:55]: -----------------
[12:06:55]: $ say 'before all'
[12:06:56]: -----------------
[12:06:56]: --- Step: say ---
[12:06:56]: -----------------
[12:06:56]: $ say 'テストですよー'
[12:06:58]: -----------------
[12:06:58]: --- Step: say ---
[12:06:58]: -----------------
[12:06:58]: $ say 'after all'

+------+-------------------------------------+-------------+
| fastlane summary |
+------+-------------------------------------+-------------+
| Step | Action | Time (in s) |
+------+-------------------------------------+-------------+
| 1 | Verifying required fastlane version | 0 |
| 2 | default_platform | 0 |
| 3 | say | 1 |
| 4 | say | 1 |
| 5 | say | 1 |
+------+-------------------------------------+-------------+

[12:06:59]: fastlane.tools finished successfully 🎉
test:fastlane test$ fastlane test2 hoge:aaa
[17:53:38]: -------------------------------------------------
[17:53:38]: --- Step: Verifying required fastlane version ---
[17:53:38]: -------------------------------------------------
[17:53:38]: fastlane version valid
[17:53:38]: ------------------------------
[17:53:38]: --- Step: default_platform ---
[17:53:38]: ------------------------------
[17:53:38]: Driving the lane 'ios test2' 🚀
[17:53:38]: -----------------
[17:53:38]: --- Step: say ---
[17:53:38]: -----------------
[17:53:38]: $ say 'before all'
[17:53:39]: -----------------
[17:53:39]: --- Step: say ---
[17:53:39]: -----------------
[17:53:39]: $ say 'aaa'
[17:53:40]: -----------------
[17:53:40]: --- Step: say ---
[17:53:40]: -----------------
[17:53:40]: $ say 'after all'

+------+-------------------------------------+-------------+
| fastlane summary |
+------+-------------------------------------+-------------+
| Step | Action | Time (in s) |
+------+-------------------------------------+-------------+
| 1 | Verifying required fastlane version | 0 |
| 2 | default_platform | 0 |
| 3 | say | 1 |
| 4 | say | 1 |
| 5 | say | 1 |
+------+-------------------------------------+-------------+

[17:53:41]: fastlane.tools finished successfully 🎉

今回はここまで
次回はgymを入れてipaファイルを作ってみようと思います

Facebooktwittergoogle_pluslinkedintumblrmail

cordova でプラットフォーム固有の orientation を指定する

最近ハイブリッドアプリを検討する機会があり、cordova 由来のプロジェクト、PhoneGap や ionic 等を触っています。

さて、これらのアプリも基本的には Web の技術で実装するとはいえプラットフォームとの協調を設定する部分はあり、それらが記載されているのがプロジェクトルートにある config.xml です。

よく設定が必要となる項目に画面回転があると思います。アプリの要件で縦固定となることは少なくありません。ゲームであれば横固定となることもあるでしょう。config.xml では以下の項目を指定します。

    

この orientation にはプラットフォーム固有の値を持たせることが出来、Android であれば一例として sensorLandscape という値があります。sensorLandscape は横固定だが上下はセンサーに従うという設定です。
これをドキュメントに記載されているコードを参考に追記すると、以下のようになります。

    
    
        
    

これで画面横向き、Android においては sensorLandscape が適用され…るかと思いきや、どうもそうでは無いようです。
少なくとも今試している cordova (v5.4.1) では通常の preference があるとそちらが優先されるようなので、プラットフォーム固有のコードを適用させたい場合は共通の設定は削除する必要があります。

    
        
    

上記でビルドが通り、orientation が適用されます。他プラットフォームでもビルドは可能で、その場合プラットフォーム指定が無ければ default 指定が適用されるようです。

該当箇所っぽいコードを見るとプラットフォーム固有の指定がある場合はそちらを優先させてくれるような実装に見てとれます。恐らく意図しない挙動だとは思うのですが、軽い気持ちで issue でも投げに行くか〜と覗きに行くと JIRA でキッチリやっている様子で思わず身が竦んでしまいました。いい感じに直ってくれるといいんですが…。


Facebooktwittergoogle_pluslinkedintumblrmail

iOSのクラッシュログにシンボル情報を追加する

Appleの審査でリジェクトされた際に、「*.clash」や「*.ips」といった形でクラッシュログが添付されていることがあります。
中身を確認すると以下のような内容になっていますが、このままだとコードのどの部分でクラッシュしたのかが分かりません。

〜一部抜粋〜
Thread 5 Crashed:
1  CoreFoundation                   0x24936b62 0x24831000 + 135152
2  Foundation                       0x255e49f5 0x25575000 + 21531
3  SampleApp                        0x000341d2 0xb000 + 55521
4  libdispatch.dylib                0x32a107b6 0x32a0f000 + 1235

そこで、「symbolicatecrash」というツールを利用してログにシンボル情報を追加することで、クラッシュ箇所を特定出来るようにします。

必要なファイル

  • クラッシュログファイル
  • appファイル
  • dSYMファイル

appファイル及びdSYMファイルはクラッシュログを出力したものと同じものを使う必要があります。
私は以下の方法で取得しました。

1. XcodeのOrganizerを開く
2. 該当ビルド上で右クリックし、「Show In Finder」を選択
3. Finderで選択されているファイル上で右クリックし、「パッケージの内容を表示」を選択
4. 「dSYMs」ディレクトリ内に「*.app.dSYM」が「Products/Applications」内に「*.app」があります

symbolicatecrashの実行

実行環境
・OS X 10.9.5
・Xcode6.1

「symbolicatecrash」は私の環境では以下のパスにありました。

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

長過ぎるのでシンボリックリンクやエイリアスを作成しておくと便利です。

あとは下記コマンドを実行する事で、クラッシュログにシンボル情報を追加したログファイルを作成できます。

    # このコマンドを実行しないと「Error: "DEVELOPER_DIR" is not defined at symbolicatecrash line 60.」といったエラーメッセージが表示されます。
    export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"

    symbolicatecrash クラッシュログファイル dSYMファイル appファイル > crash.log

作成されたcrash.logを確認してみるとシンボル情報が追加され、 SampleController.m の121行目辺りが怪しいことが分かるようになりました。

〜一部抜粋〜
Thread 5 Crashed:
1  CoreFoundation                   0x24936b62 +[NSException raise:format:] + 108
2  Foundation                       0x255e49f5 +[NSJSONSerialization JSONObjectWithData:options:error:] + 62
3  SampleApp                        0x000341d2 __35-[SampleController startSample:] (SampleController.m:121)
4  libdispatch.dylib                0x32a107b6 _dispatch_call_block_and_release + 8
Facebooktwittergoogle_pluslinkedintumblrmail

iOSでプッシュ通知時の挙動を確認したい

今回はiOSアプリを開発している際にプッシュ通知時の挙動を確認したい時に使えそうな「houston」というライブラリを紹介したいと思います。

nomad/houston

1. インストール

gem install houston

2. 送信用のrubyファイルを用意

ほぼREADMEにあったサンプルの通りのものです。
また、事前に開発用の「push_dev.pem」を同じディレクトリに置いています。

push.ruby

require 'houston'

# Environment variables are automatically read, or can be overridden by any specified options. You can also
# conveniently use `Houston::Client.development` or `Houston::Client.production`.
APN = Houston::Client.development
APN.certificate = File.read("push_dev.pem")

# An example of the token sent back when a device registers for notifications
token = "<《ここにプッシュ通知を送信したい端末のデバイストークンを指定します》>"

# Create a notification that alerts a message to the user, plays a sound, and sets the badge on the app
notification = Houston::Notification.new(device: token)
notification.alert = "ハロー, ワールド!"

# Notifications can also change the badge count, have a custom sound, have a category identifier, indicate available Newsstand content, or pass along arbitrary data.
notification.badge = 1
notification.sound = "sosumi.aiff"
notification.category = "INVITE_CATEGORY"
notification.content_available = true
notification.custom_data = {foo: "bar"}

# And... sent! That's all it takes.
APN.push(notification)

3. push通知を送信

ruby push.ruby

以上で、指定した端末にプッシュ通知が飛びます。
READMEにはデバイストークンの取得方法や証明書の作成方法なども載っておりすごく分かりやすいです。
この他にもコマンドラインからプッシュ通知を送信することが出来るようです。

apn push "<デバイストークン>" -c /path/to/apple_push_notification.pem -m "Hello from the command line!"
Facebooktwittergoogle_pluslinkedintumblrmail