xcconfig を使い本体アプリと Embedded Framework を同じ環境設定でビルドする

iOS Xcode

本体アプリを Build した時に、本体アプリの CONFIGURATION を Embedded Framework 側に渡したい。

  • 本体アプリを Debug Build
    • Embedded Framework も Debug Build
  • 本体アプリを Release Build
    • Embedded Framework も Release Build

というように、本体アプリのビルド環境によって自動で Embedded Framework のビルド環境も変えたい。

xcconfig を使う

  1. Embedded Framework 側で xcconfig を作成する
    • New File から Configuration Settings File を選択
    • Targets は Embedded Framework を選ぶ
  2. hoge.xcconfig に下記を追記
    • OTHER_SWIFT_FLAGS = "-D" $(CONFIGURATION)

これでビルドすると、本体でビルドした環境を Embedded Framework 側に渡せる。

参考

The Unofficial Guide to xcconfig files

ここにサンプルやユースケースなど色々書いてあって便利。 今回は CONFIGURATION を渡したが、他にも色々な設定ができる。

TodayViewController の viewDidLoad が呼ばれるタイミングについて

iOS Swift TodayExtension

iOS の TodayExtension を実装していて、 TodayViewController の viewDidLoad が走るタイミングが最初はわからず苦労した。

viewDidLoad が呼ばれるタイミング

画面に表示されたタイミングで ほぼ毎回 viewDidLoad が呼ばれる。
TodayExtension を 10 こくらい並べて、スクロールして画面外から表示させても viewDidLoad が呼ばれる。

開発し始めた最初は

  1. 端末起動後/Widget 追加後に viewDidLoad が 1 度だけ呼ばれる
  2. 画面表示時に widgetPerformUpdate(completionHandler:) が呼ばる
    • 更新の必要があれば completionHandler(.newData) を実行する

だと思って開発を始めたため、何度も viewDidLoad が呼ばれて戸惑った。

TodayExtension の高さを変えるような時に問題が生じる

TodayExtension Widget 表示時、こう動く。(TableView で、 List の要素 1 つにつき 50px 使うようなコードだとする。)

  1. 一瞬だけ前回取得したデータが表示される
    • 要素が 4 つあったので、 height が 200px くらいある
  2. Extension の表示が初期表示になる
    • 初期は要素数が 0 なので、 height がデフォルト(110px)になる
  3. 取得されたデータが表示される
    • しかし、 Show More になっているのにデータが2つしか表示されない…

Show More の状態は変わらないが画面はリセットされてしまい、表示がおかしい…。
こんな感じ。

f:id:star__hoshi:20170720140917g:plain

表示を改善するためには？

初期表示時に前回取得したデータを表示すれば良い。

  1. 一瞬だけ前回取得したデータが表示される
    • 前回の height が 200px だったので、それがそのまま表示される
  2. Extension を初期化する
    • 初期化時にローカルに保存しておいたデータを表示する
      • 画面に変化がないので height 200px を保つ
  3. 取得された最新のデータを表示する
    • 要素数が 4 つだったので、 height が 200px になる
    • 取得したデータをローカルに保存しておく

つまり、前回取得したデータを保存しておいて、 viewDidLoad 時にそのデータを描画するとユーザとしては画面がチラチラせずに違和感なく使える。

そうすると初期化時に高さが前回と同じに設定されるので、突然小さくなったりしないですむ。

↓のは画面に変化がないように見えるが、実際には画面が初期化されたりしている。

f:id:star__hoshi:20170720140853g:plain

ローカルにデータを保存

保存したいデータが String だけとかなら楽でいいけど、実際は JSON Mapping されたクラスだったりするので、そのクラスに NSCoding を継承して data 型として保存すると楽。

UserDefault などに class を保存するサンプル

ちなみに TodayExtension で UserDefaults を使うには AppGroups の設定が必要。

おわり

最初は viewDidLoad が呼ばれまくることに違和感があるが、 UserDefaults などを使って適切にデータを管理すればそんなに難しくなかった。

しかし Show More / Show Less の挙動とかうまくいかないところとかあってなかなか難しい…。

EdTech Engineer Meetup #1 で「学校の iOS 端末事情」について話した #edtech_ja

勉強会 iOS EdTech

Education×Technolog 業界の3社 Classi, LITALICO, Studyplus が集まって会社紹介やらパネルディスカッションやら LT やら懇親会しましょう、という会で LT してきた。

edtechem.connpass.com

Lightning Talks

教育業界、というか BtoB 業界のモバイルアプリは辛い話が結構あって、その 1 つに MDM がある。

やっぱり他の会社の人も同じ悩みを抱えている人がいて「その辛さわかる…」と言ってもらえて、共感してもらえたっぽくて嬉しい。

「ウチはめっちゃテストして安定している Version を MDM で提供するようにしている」という話を聞いて、うちも MDM 提供バージョンは固定したほうがいいのかもなあと思った。

今回は MDM によるアプリバージョン固定化問題について話したけど、他にも

  • 端末共有問題
    • 複数人の生徒が1台のデバイスを使う
    • 端末使い終わった後にログアウトし忘れると…?
    • Keychain Sharing しちゃうと、意図しないユーザでログインしてしまう
  • MDM で Safari 無効化しているはずなのに Safari 使えちゃう問題
  • 強制アップデートがめっちゃ大変

など、 toC だとあまり考えなくて良いことが toB だと大きな障壁になるケースがあり、なかなか大変な業界である。

勉強会それ自体について

開始が 18:20 予定だったのが、実際には 18:40 開始になった。人の入りがあまりよくなかったので開始を遅らせたらしいが、特にアナウンスなどはなくただ gdgd と開始が遅れているように見えて、参加者だったら印象良くないだろうなあと思っていた。開始遅れるならそのタイミングでアナウンス入れたり、画面に理由を表示したりとかしたほうが良さそうに思った。

また、勉強会の運営側を初めて目の当たりにしたが、とても大変そうだった。昨今騒がれている勉強会をドタキャンする人は運営側になったことがないのだろう。
自分は LT 参加者の軽い気持ちで参加してしまったのであまり貢献できなかった、もうちょっと能動的に動ければよかったと反省である。

しかし懇親会は盛り上がっていた? ように見えたので、終わりよければ全てよし。

Firebase, Google Analytics, Fabric, Apple App Analytics の個人的使い分け

iOS Android Firebase Google Analytics Fabric Crashlytics Apple App Analytics

昨今モバイル界隈ではアクセス解析に色々なサービスがあるが、それぞれにメリット/デメリットがあるため、複数併用するようにしている。4 つのサービスの個人的使い分けについて、iOS エンジニア視点で雑に書いていく。

なお、どれも無料枠での利用とする。

最初にまとめ

  • ざっくり見たいときは Firebase を使う
  • 細かく見たいときは Google Analytics を使う
  • クラッシュ情報とリリース直後の状況を見たい場合は Fabric を使う
  • 上記以外のデータが見たい場合は Apple Analytics 使う

Firebase

メリット
  • モバイルに特化しているので見やすい
  • バージョン、コホート、デバイスなどデフォルトで多くの情報を取ってくれる
  • ぱっと見いい感じにデータを見してくれる
  • 最近入った STREAMVIEW というのがリアルタイムで使っている人を見れる
デメリット
  • Screen Transition が見れない
    • GA で補完
  • 詳しい情報を見たい場合は BigQuery 連携が必要
    • ぱっと見はいいけど詳しいところまで見れない
      • 例えば iOS8 のユーザ数が見れない

Google Analytics

メリット
  • 細かい情報まで見れる
    • このカテゴリの人のこの情報 みたいな細かい指定ができる
  • Screen Transition が見れる
  • リアルタイム View が見れる
デメリット
  • 細かい情報まで見れるけど、気が利かない
    • iOS8 のユーザ数見たかったら、8.0 と 8.1 の数字出してくれてあとは自分で計算するとか
  • なんかぐちゃぐちゃしてて見づらい

Fabric

メリット
  • Crashlytics のクラッシュ情報が見やすい
  • Latest Release でアプリのリリースに問題ないかが確認できる
デメリット
  • Growth でユーザ分析ができるが、Firebase の方が見やすい
    • なんかいまいち直感的に見れない
  • Google に買収されてそのうち消える

Apple App Analytics

メリット
  • ソースから、どこ経由でインストールされたかが見れる
  • アプリのダウンロード数(ユニット数)が見れる
  • リテンションやセッション数、アクティブ数など結構情報が見れる
デメリット
  • まず iTunes Connect 開くのが面倒
    • ログインしてアプリ開いて分析ページまで遷移して...がだるい
  • オプトインのみの情報しか見れない
    • 30%がオプトインだから3倍ちょっとすれば数字が出るな...
      • と頭の中で計算している

おわり

どれも便利なんだけど、いいところもあれば足りない機能もあり、結果として色々なサービスを使ってしまっている。
Firebase には一番期待していて、Fabric は Google に買収され Crahslytics が Firebase と統合されると発表があったし、STREAMVIEW というのが素晴らしく便利な気がしている。
STREAMVIEW があれば Screen Transition を取る必要もなくなるかもしれないので、とにかく Firebase に頑張ってほしい。

Mac の環境構築手順を整備した

homebrew dotfiles 環境構築

今までも dotfiles と Brewfile を Github に置いて環境構築手順を整えていたが、 dotfiles は homesick、 Brewfile は homebrew-file というのを使っていたため管理がややこしくなっていた。

しかもそれらは全然 commit してなくて古くなってしまったため、エイヤで色々整えることにした。

Brewfile

homebrew-file を使うのはやめ、素の Brewfile を Github で管理するようにした。
下記コマンドで Brewfile を吐き出すことができる。

$ brew bundle dump --force

次回 brew のセットアップをするときは下記コマンドでいける、はず(試してないので本当にいけるかわからない…)。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile

dotfiles

必要な設定ファイルをレポジトリ管理するようにした。karabiner, hammerspoon の設定ファイルは実際には dotfile ではないかもしれないが、難しいことを考えるのはやめた。

これらの設定ファイルは↓のコマンドで install できる、はず。
zsh がすでに install されているのが前提なので、 brew の後に実行する必要がある。

$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

dotfiles の設定では Deploy と Initialize を分けろとあるが「そこまでガチ勢じゃないしこのままでいいか」と思い， install.sh すればいい感じになるようにした。

まとめると

次回のセットアップでは、

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile
$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

これで環境が整うようになった。

レポジトリ

参考

Swift2 から Swift3 への移行がだるすぎて諦めた

iOS Swift Xcode

1年前くらいにリリースしたアプリ があるのだが、動かなくなったというレビューがきたので修正しようと思ったのだがだるすぎる。
何がだるいかというと、 Swift3への対応が一番だるい。ライブラリを更新して、マイグレーションして… ってやらないといけないけど、そもそもライブラリがSwift3対応してなくて諦めた。

だるさ

  • Swift3移行がだるい
  • Swift3対応していないライブラリがある
  • xml, html の parse がだるい
  • 過去の自分のコードがイケてなくて読むのがだるい
  • 利用者があまり多くないので作り直してもメリットが小さい
    • レビューで「動かなくなってつらい」ってきたので利用者はいる

結局

Xcode 7.2.1 をダウンロードして、Swift2 で修正することにした。
いつまでも Xcode7 で修正できるわけではないし、Swift3の移行はだるすぎるし、そのうちこのアプリは死ぬだろう。

悲しいが、 Apple 様の進化に追従できなかった者の末路である。しょうがない。

英語の五文型

英語

中学・高校6年間の英語をこの1冊でざっと復習する

中学・高校6年間の英語をこの1冊でざっと復習する

本を読んで英語の勉強を始めた。英語めっちゃ苦手なので、とりあえず中学英語から学び直している。

1章は五文型なんだけど今まで雰囲気でやっていたので全く理解できていなかったし、本読んでもあまり理解できていない。
なので思考の整理も兼ねてまとめてみる。

本の例文など引用しているが、引用しすぎな気もする。問題があれば消します。

文型

S, V, O, C らへんのはなし。

第2文型

S + V + C (主語 + 動詞 + 補語)。

  • である(be動詞)
    • He is a singer.
  • になる(become, get など)
    • She became a doctor.
  • のように見える[聞こえる、感じる などの五感が中心]
    • She looks young.
  • の(状態の)ままである
    • I kept quiet.

第5文型

S + V + O + C (主語 + 動詞 + 目的語 + 補語)。
目的語と補語の間に「主語 + 述語動詞」の関係がある。目的語と補語の間に be 動詞を入れてみて意味が通れば良い。

  • 〜を…にする
    • He made me happy
  • 〜を…と呼ぶ
    • He calls me Micky.
  • 〜に…するよう要求する
    • I want you to go there.
  • 〜を…にしておく
    • Keep your room clean.
  • 〜が…だと思う
  • 〜を[に]…させる(使役動詞)
    • You made me happy.
  • 〜が…するのを見る[聞く、感じる]
    • I saw him walking.

第3文型

S + V + O (主語 + 動詞 + 目的語)。

補語 / 目的語

補語は He is a student. のように、 He と student がイコールで結べる。
目的語は He wrote a letter. のように、 He と letter はイコールで結べない。

自動詞 / 他動詞

目的語は動詞の動作の影響を受ける語。
他動詞は目的語が必要で、自動詞は目的語が不要。
I went. だと「私は行った」で意味わかるが、 I play. だと「私はした」で訳がわからんので I play baseball. など目的語が必要。

第4文型

S + V + O + O (主語 + 動詞 + 関節目的語 + 直接目的語)。
第4文型の順番を入れ替えると第3文系にすることができる。
とりあえず O + O は 人 + 物 というふうに覚えておくのが良さそう。

I’ll give you a pencil. -> I’ll give a pencil to you.

第1文型

S + V (主語 + 動詞)。
第一文型 にあるように、完全自動詞のみのは少ない。

There is ~ . は S が後ろに来たりする。

古い iOS アプリが Apple に削除された

iTunes Connect iOS

www.itmedia.co.jp

これの対象になったようで、4年くらい前にリリースしたけど全くアップデートしていなかったアプリが削除された。

削除されたアプリは Anison Tube というやつで、AppStore ではもう見れなくなっている。

作ったアプリがアプリストアに14個並んでるんですよ〜って言ってたけど、13個になってしまった。

削除されるまでの流れ

2017年5月6日

Your app, Anison Tube (733552119), does not comply with one or more App Review Guidelines.

For details, or to directly contact the App Review team, go to the Resolution Center on iTunes Connect.

というメールが届く。

ああ、ついに自分のアプリも粛清対象になったのだなと感慨深い思いになる。

Apple に抗議をするかアプリを更新するかが必要のようだ。しかしこのアプリは動かないと言っても過言ではないし、まあ消えてもしょうがないという思いだったので放置した。

2017年6月10日

前回のメールから1ヶ月とちょっと後に、削除に関する2通のメールが届いた。

1通目

削除したよって内容。

Your app, Anison Tube (733552119), has been removed from the App Store due to an unresolved issue.

2通目

アプリのステータスが変更されたという内容で、これはよく見るメール。

The status for the following app has changed to Removed From Sale.

App Name: Anison Tube
App Version Number: 1.0
App SKU: com.anisontube
App Apple ID:733552119

iTunes Connect

iTunes Connect の該当アプリを見ると、 ストアから削除済み というステータスになっている。なんとかしてステータス変えようと思ったが無理そう。再度アプリをストアに出したいときは新しいバージョンを出すしかない。

価格および配信状況 > 配信可否は「すべてのテリトリで配信可能」になっているので、ここをいじってもダメだった。

どんどんやってくれ

自分が開発したアプリがストアから消されるのは悲しいことなんだけど、ユーザから見たらノイズでしかないようなアプリが消えていくのはいいことである。

Apple はどんどんやっていってほしい。

寂しさ

しかし 32bit アプリも消えていくのだろうな、と思うとちょっと悲しい。
web だと00年代のサイトとかまだ全然動いてるし、そういうサイト見ると懐かしさが込み上げてくる。ネイティブアプリはプラットフォーム依存だししょうがないけど、やっぱり悲しい。

血便がでた

昨日の夜になんかお腹の調子悪いな〜ってトイレ行ったら血便が出ていた。血便にも色々あるのだが自分のは鮮血で、痔とかじゃなくて腸がやばそうな感じがしていた。

allabout.co.jp

これを読むと良くて痔とか腸炎で、ヤバいと癌らしいので戦々恐々として病院に行った。

検査入院とか言われたりしたけど、結論から言うと癌とかではなく普通に食中毒的なやつなので何事もなく明日からも行きていける、良かった。

診察の流れ

オフィスビルの病院で診察

1. 痔じゃないか確認する

肛門に指を入れられて確かめられる、たぶんなんか変な声出た。

触診の結果「入り口すぐのところに膨らみがありそれが痔っぽいですけど念のため午後に大腸にカメラ入れる検査もしますか」という流れになる。

2. 採血

ヘモグロビンの量を測りたいので血を取ります、と言って血を抜かれる。しかし血便ですでにかなりの量を出血していたせいか採血後に失神して、起きたら知らない天井だった。

3. 大腸カメラ準備

下剤をひたすら飲む、10 分間に 200ml 飲むのを9回繰り返して 1800ml 飲まねばならない。しかし下剤はアクエリアスみたいな味がして全然飲めた。

下剤を飲み始めて 30 分後くらいにトイレに行き、やっぱり血便なのだが、それを看護師さんにみてもらう。なんか看護師さんが「こりゃ痔じゃない、大腸だわ…」みたいな空気を醸し出すも下剤は飲み続けろと言われる。

4. でかい病院に行くことになる

主治医っぽい人が「便を見ましたがこれは痔じゃなくてもっとヤバいやつなので、今からでかい病院を紹介するのですぐに検査入院してください。タクシーでいけますか？救急車乗りますか？」といきなり言ってくる。いきなりすぎて少し混乱したが、救急車ってほどヤバい体調じゃないのでタクシーで行く。

5. タクシー

乗車10秒で酔った。5分しか乗らなかったけど病院ついた時は吐きそうだしトイレ行きたいし最悪な気分だった。

でかい病院で診察

6. 採血・CTC検査

また採血した、今度は失神しないよう寝ながら採血してもらった。CTC で大腸のレントゲンもとった。

7. 大腸内視鏡検査

肛門からカメラ入れて、大腸でおかしいところないか確認するやつ。人生初浣腸をした。
カメラ入れながら腸を広げるために空気も入れるので、お腹が張ってめちゃくちゃ辛かった、お腹もずっとギュルギュルいっていた。

カメラでみてると大腸の奥の方に数カ所の出血があった。

8. 診察完了: 食中毒

カメラでみた感じ癌とかではなさそう、というか普通に食中毒じゃないですかねと言われた。おととい電子レンジで生の鶏肉をレンチンして食べたんだけど、それっぽい感じだった。レンチンなので、局所的に火が通ってなかったりとかあったのかもしれない…。

ちゃんとした病名はナントカカントカ腸炎だったけど忘れた。

9. 支払い

21000円だった、高い…。自炊なんかして適当に飯食べるより外食した方が安全で安上がりなのでは？

血便が出たらどうすべきか

  1. メシを食べない
    • 大腸内視鏡検査をするためには腸を綺麗にしないといけない
    • 血便が出た以降は診察を受けるまでメシを食べない
  2. ちゃんと病院にいく
    • 気合いと根性で治るやつと、治療しないと治らないやつがある
    • それは診察しないとわからないので安心感得るために病院にいけ

人生

癌かも？とか思った時にちょっと人生について考えて、やっぱパン屋さんいいよなというのを昔から思っている。パン屋さんというか接客業をやってみたいのかもしれない。

迷走にも書いたけど、ソフトウェアエンジニアじゃない職もやってみたい。人生長いようで短い気がしているのでやるなら今なのかもしれない。

見たくない画像を置換する Chrome Extension を作った

Chrome Extension JavaScript HTML

chrome.google.com

Image Switcher という、指定した画像を別の画像に置き換える Chrome Extension を作った。

仕事で GitHub とか Google とか使うじゃないですか、それに自分の見たくないアイコンを使っている人がいるじゃないですか、でもその人に「そのアイコン嫌いなんで変えてもらえますか」なんて言えないじゃないですか、だから自分でなんとかした。

設定画面で from: に見たくない画像の URL を指定して、 to: で新しく表示する URL を入力する。to: はデフォルトで Image Switcher のアイコンが指定されるので、実際は from: だけ指定すれば良い。

Extension の中身は何をやっているかというと、 img.src を書き換えているだけ。

しかしこれには問題があり、

  1. "run_at": "document_idle" のタイミングで実行しているので一瞬元の画像が表示される
  2. SPA とかで DOM を後読みされると document_idle が発火せず置換されない
  3. background-image: url(image/hoge.gif); に対応していない

というのがあるが、まあ今のところ利用に支障はないのでいいか、となっている。面倒だしたぶん自分しか使わないだろうし。

Chrome の拡張を作ったのは2年半ぶりだったが、大きく仕様が変わっているわけでもなさそうでサクっと作れた。

ソースコードも公開している。
starhoshi/ImageSwitcher

他にも作りたい Chrome Extension あるしやっていきたい。