Cocoaの日々

Todayeeシリーズのカメラアプリ Todayee silent をアップデートしました。
変更の大きな点は、非マナーモードでシャッター音が鳴るところ。最初のバージョンでは完全無音で審査が通ったが２回目ではダメだった（PLA 3.3.8 というやつに引っかかった。これは被写体に撮影していることを知らせる条項）。単純にシャッター音を復活させるとこのアプリの存在意義が無くなってしまうため、少し悩んだあげく非マナーモードのみ 単純に AVAudioPlayerでシャッター音の .aif ファイルを再生するようにしてみた。その結果、無事に通過。実際にはもう一点指摘があって、スクリーンショットに入れていたテキストの「無音」を消すようにとの指導もあった。そこは別のテキストで置き換えた。そんなこんなで、ここ数日で３回ほど申請と却下を繰り返したあげくようやく今朝リリースできた。

iOSのシェア機能を利用してEvernoteへ投稿を行うアプリです。他のアプリで↑ボタンを押すと Todayeeアイコンが出てきます。




テキスト・ＵＲＬ・画像（１枚）が投稿可能です。カメラロールの写真はもちろん、SafariやRSSリーダー、メッセージなどで気になる情報があった時のURLの簡易クリップアプリとしても使えます。

投稿したテキストは左に線が表示される引用スタイルとなります。またURLは「リンク」という文字のリンクとなります。


Todayeeの特徴である複数アプリ・デバイスからの投稿を１つのノートへまとめる機能も、もちろん健在です。

他の Todayeeシリーズのアプリと一緒に使っていけます。


他の Todayeeアプリの記事

【アプリ】Todayee Text / Photo 1.0 をリリースしました
【アプリ】Todayee Silent 1.0 をリリースしました

開発メモ

Extension で UIAlertController / ViewController

Extensionでは実行中に普通にUIAlertControllerが使える。Todayee Exntesionではエラーや注意メッセージを出すのに使っている。注意点はメインスレッドで呼び出すところ。
                    dispatch_async(dispatch_get_main_queue(), {
                        let controller = UIAlertController(title: ...
                        controller.addAction(UIAlertAction(title: ...
：
                        self.presentViewController(controller, animated: true, completion: nil)
                    })

同様に必要なら ViewControllerを作り画面を覆うような UIも作れる（同じくメインスレッドで）。Evernote投稿中に少し時間がかかりその間画面が固まってしまうので、このアプリでは ActivityIndicatorを表示するのに使っている。

起動後に説明画面

ネット上の情報で Extensionメインのアプリの場合、本体に操作方法の説明が無いとリジェクトされるとのことだったので、起動直後にヘルプのページを表示するようにした。

ビルドエラー

アップロードエラー

最後にハマったのが AppStoreへのアップロード。Xcodeのオーガナイザでいつものようにアップロードするとエラー。
リトライということなので、数日時間を開けてなんども実行。が、同じエラー。これはおかしいと思い調べたところ App Uploaderを使うと良いとの情報があったので使ってみた。ちなみに App Uploaderは Xcode7のメニューから呼び出す（知らんかった）。
App Loaderを使うともう少しマシなメッセージが出てきた。

調べると Extensionや Frameworkで CocoaPodsを使う時の既知の問題らしく、対処としては Extensionフォルダ内にできる Frameworksフォルダをビルドの最後に削除すること。※最後のWARNINGは Containing App と Extensionの Build番号（BundleVersion）が一致しない為のメッセージ。

そこで下記をExtension側の Build Phase の Run Scriptへ追記して実行したところ確かにエラーが減った。

が、まだ最後の１つが消えない。

スクリプトに ls > /tmp/ls.txt など追加して状況を調べるがディレクトリはあっていて Frameworksは存在する（ので、rm -frで削除されるはず）。原因は結局わからず時間ももったいないので、今回は自分で消すことにした。オーガナイザから作成した Archiveビルドをファインダで表示し、Extension配下の Frameworksを手で削除した。それをアップロードしたところ無事に完了。うまくいったので、まあこれでいいや。

あとがき

申請まで持っていくのに結構苦労させられたアプリだったが、申請自体は一発で通った。これはちょっとうれしい。今回もTodayeeプラットフォームがベースにあったのと、アプリの機能自体は少なかったので短期間で開発できたと思う。自分自身SafariやRSSリーダのURLを投稿するのに結構重宝している。

今後検討中のアプリ
・Place
・Pics
・Map
・Voice
・Viewer
：

写真を撮影して送信するだけのシンプルなアプリです。特徴はシャッター音がしないこと。

防犯上の理由からカメラを上にした状態（iPhoneの液晶面を下にした状態）では撮影ができないようになっています。またiPhoneの場合、撮影時にバイブレーションが動作します（これは停められません）。

Todayeeの特徴である複数アプリ・デバイスからの投稿を１つのノートへまとめる機能も健在です。他の Text と Photo と一緒に使っていけます。

画質は同シリーズの Photoと比べると劣ります（例 iPhone6の場合、最大 750 x 1000）。このあたりは用途に合わせて Photoと使い分けてもらえればと思っています。

開発メモ

無音カメラの実装はビデオキャプチャの原理で、これはネットを探すとたくさん情報があるので苦労はしなかった。開発で時間が取られたのはその周辺。
・裏返しの判定（ここ）
・AVCaptureVideoPreviewLayerの回転対応

また申請では１度リジェクトされた。この時は２点指摘があった。

・位置情報確認のダイアログに説明を入れなさい
　今まで Info.plistのNSLocationWhenInUseUsageDescriptionは空文字列のまま放置していたのだが、今回はそれが指摘されたので利用目的を入れるようにした。なお Todayeeはたくさんのアプリを１つのプロジェクトで扱っていることから SIlent_Info.plistなどとしている。この場合の多言語化は通常どおり InfoPlist.stringsだった。

・クラッシュする（IPv6に対応しなさい）
結果からすると IPv6は関係なかったが、EvernoteのSDKが IPv6未対応かと当初思って少々焦った。ただApple推奨の IPv6検証環境（これ）で問題ないことと、Crash Logの解析から別の箇所が問題とわかった。状況からすると審査担当がアプリ起動時にカメラの利用を不許可にし、それが原因で AVCapture* 周りの初期化に失敗してクラッシュしていた可能性が高い。そこで AVCaptureDevice.authorizationStatusForMediaType() でカメラの利用可能状態をきちんとチェックすることで対処し、無事に審査を通過できた。

あとがき

Todayee Platform のおかげで開発開始から審査通過までなんと 20日、と自分自身の過去最短のリリースとなった。前回のTextとPhotoが５ヶ月近くかかったのとはえらい違い。ベースがあるとこんなに楽かとしみじみ。今後も Todayee Platformで動くアプリを量産して毎月リリースを行うつもり。しばらくは Todayee開発が続く。

今後検討中のアプリ
・Extension
・Pics
・Map
・Voice
・Viewer
　　：

motionManager.deviceMotionUpdateInterval = 0.2
        motionManager.startDeviceMotionUpdatesToQueue(NSOperationQueue.mainQueue()) { (motion, error) in
            if motion?.gravity.z < 0.75 {
                print("up side")
            } else {
                print("down side)
            }
        }

gravity.z の値は、液晶面が上（天）を向いている時は -1.0近辺
Optional(-0.99992328882217407)
Optional(-0.99992173910140991)
Optional(-0.99992197751998901)
　：


液晶面が下（地面）を向いている時は +1.0近辺
Optional(0.99968743324279785)
Optional(0.99974864721298218)
Optional(0.99976813793182373)
　：

垂直に立っている時は 0近辺
Optional(-0.039904400706291199)
Optional(-0.038459554314613342)
Optional(-0.035526838153600693)
　：

新アプリ２本 Todayee Text / Photo をリリースしました。読み方は「トゥデイー」。どちらもエバーノート投稿専用アプリです。名前の通り２つのアプリは関係があって Todayee プラットフォームという共通の仕組みで動作しています。このプラットフォームで動作するアプリで投稿した内容はすべて同じ１つのノートにマージすることができます。他の iPhoneやiPadからの投稿であっても同じノートにマージされます。※同一のエバーノートアカウントを使っていることが前提。


ノートは１日単位で自動的に切り替わるので、１日の複数のアプリ、複数のデバイスの複数の投稿がすべて１日のノートにまとめられることになります。

エバーノートで見るとこんな感じ。PhotoとText 両方からの投稿が１つのノートにまとまっている。


上の例に記載のある花子や太郎はアプリ毎に設定できるテキスト。色も付けられる。

Todayee Photo

写真を撮影して送信するだけのシンプルなアプリ。

起動と同時にカメラが立ち上がり、撮影ボタンを押すだけ。




撮影後にプレビューが表示され、送信か取り消しを選べます。ここでコメントを付けることもできます。


カメラロールへの保存設定はその場で選択できて、デフォルトの制御は設定画面で指定することが可能です。送信後はカメラの画面へ戻り撮影をストレスなく繰り返せます。

Todayee Text

テキストを送信するだけの超シンプルなアプリです。

こちらも起動直後からテキスト入力が可能。


１日のノートを作るという大前提があるので、日付の挿入もリマインダも要らない、と不要な機能をそぎ落としたらこんな画面になりました。


唯一機能らしい機能は真ん中のスターボタン。これをつけて投稿するとエバーノートでの見え方が変わる。なおスターは Todayee プラットフォーム上のアプリ共通の機能で Photoにもある。

Todayee プラットフォーム共通仕様

アプリに関わらず共通にできることはこんな感じ。

• 今日１日のすべての投稿を１つのノートに集約
• 投稿ごとに時刻、地名、位置情報、天気、気温を掲載
• 投稿は１日のノートの中で時刻順にソート
• ノートの切替基準時刻を変更可能（通常は 0:00）
• ノートブックとタグの設定
• ノートのタイトルは用意された日付形式から選択可能
• 名前やデバイス名を登録すると投稿を区別可能
• 投稿はバックグラウンド
• スターを付けて投稿を目立たせる

なおネットワークがオフラインや接続状況が悪い場合は地名や天気、気温は表示されない。また天気は最短でも１０分に１回しか掲載されない。

開発について

エバーノートの APIと EML（HTML互換のエバーノート専用マークアップ言語）という制約の中で、どうやって複数のアプリ、複数のデバイスからの投稿を１つにマージするかが技術的な課題でした。それぞれの投稿は非同期に行われるのでソートする必要もあるし、ノートブックやタグなどの共通設定をどこに保存するのか、と色々悩ましい。

今回は投稿ごとのメタ情報（日時や位置情報ほか）を EMLの特定のタグの属性情報に持たせ、それをＤＢのレコードのように扱う簡易的な仕組みを構築しました。１種のテキストデータベースだね。投稿直前に、前回の投稿をパースしてメモリ内にＤＢを構築した後、今回の投稿を適切な場所へ挿入してそれを最終的に EMLとして書き出して APIへ渡す、といったことを内部実行するようにしてみた。また共通設定（ノートブックやタグ、切替時刻ほか）はノートのメタ情報に埋め込むことにした。これによってエバーノートの APIの枠組みの中だけで数アプリ・複数デバイスへの対応を実現することができました。共通設定などは iCloudの KeyValue Storeへ保存することも検討しましたが、依存サービスが増えすぎると運用サポートで死ぬのでこれはやめた（１人でやってるんで）。

ただ投稿の排他制御だけはエバーノート APIが提供しておらずどうにもならなかった。 これは AWS上に仕組みを構築することにした。LambdaとAPI Gatewayを組み合わせたサーバレスアーキテクチャ。基本メンテフリーなのが１人運用ではかなり嬉しい。
（参考）【番外】AWS Lambda / API Gateway / DynamoDB を使ったサーバレスなネットワークロック機構

Today プラットフォームの実体は単なるコードだが、Xcodeの複数ターゲットをフル活用して一つのプロジェクトで複数のアプリを開発している。



さて Todayee プラットフォームという共通基盤による１番のメリットは、用途に合わせて機能を絞り込んだアプリを提供できるようになったこと。いままでだと一つのアプリで色々やろうと思うと、機能がてんこ盛りになって使い方が複雑になってしまうという宿命があった。てんこ盛りアプリだと写真を取って送信するためだけに起動も含めると４タップも５タップも必要になってしまう。これをいい加減やめたかった。あと機能が肥大化していくと、モードも多くなって使う側も大変だし、作る方もメンテが大変になる。そうこうしているバージョンアップを重ねるにつれ利用者にとっても開発者にとっても望ましくない方向へ動き始める。この辺りで一旦この流れをリセットしたいというのが Todayeeを作った動機の一つだった。アプリを垂直に掘り下げるのではなく、水平方向へ展開した、と言えるかもしれない。副次的な効果としては、アプリが軽量化されたことで iOS上で生き残り続ける率が上がったこと。メモリ常駐量が減ったので、他のアプリを使った後にアプリを使おうとした時に再起動せず以前の起動が生きていて起動を待たずに使えるようになった。これは感覚的なものだが。

開発情報

ツール：Xcode7 / swift 2.2
期間：５ヶ月
要員：１人

あいも変わらず Evernote 用の iOSアプリを作っているのだが、複数端末からの更新競合を防ぐ為にロックが欲しくなった。Evernote の APIには欲しい機能が見つからず、苦肉の作としてネットワーク越しにロックを管理する仕組みを試してみた。今回 iOSの話ではないが番外編として記録を残す。

ネットワークロックサービス

アーキテクチャ

AWSの LambdaとAPI Gateway、そして DynamoDB を使ったサーバレスアーキテクチャで組み立てる。

サーバ(EC2)を立てる必要がなく楽ちん。
Lambda Function は JavaScript (node.js)でコーディングする。

ロック取得に対する排他制御

ロックを保管管理するストレージ（ＤＢ）が排他的な操作に対応しているかどうかが鍵になる。今回の用途を考えると RDSのような大げさなものは使いたくない。またLambdaから容易に操作できるものということで、 DynamoDBを採用する。最小構成で使えば安価に運用できるのも魅力的。この DynamoDBについて排他制御を調べいるとまったく同じことを考えている人が居た。参考になる。
DynamoDBをロックマネージャーとして使う

DynamoDBではアイテム（レコード）作成時の前提条件を定義することができて、これが成り立たないと更新処理を失敗させることができる。この前提条件に、これから操作を行いたいリソースのIDの非存在を使えば、排他制御が可能になる。

アイテム作成実行（情報：リソースID）
前提条件：リソースIDの非存在
もし前提条件が
満たされる場合：
リソースIDを主キーとするアイテムの作成成功
満たされない場合（既にリソースIDが存在する場合）：
アイテムの作成失敗（エラー）

さらにアイテムにタイムアウト時刻を入れて、前提条件に時刻も盛り込めばタイムアウトが働くようになる。最終的にはこんな感じ。

アイテム作成実行（情報：リソースID、タイムアウト時刻）
前提条件：リソースIDの非存在 OR タイムアウト時刻 < 現在時刻
もし前提条件が
満たされる場合：
リソースIDを主キーとするアイテムの作成成功
満たされない場合（既にリソースIDが存在する場合）：
アイテムの作成失敗（エラー）

設定

設定の流れは次の通り。※細かいところは省く。

1. DynamoDB テーブル作成

2. Lambda Function 作成

先ほどの排他制御をJavaScriptで実装する。１つの関数でロック取得とロック解放に対応する。



ロック取得のところだけ抜粋するとこんな感じ。

dynamo.putItem({
                "TableName" : tableName,
                "Item" : {
                    "hash" : {"S" : hash},
                    "expirationTime" : {"N" : expirationTime.toString()},
                    // "created" : {"S" : now.toString()}
                },
                "ConditionExpression" : "expirationTime < :nowTime OR attribute_not_exists(#hash)",
                "ExpressionAttributeNames" : {
                    "#hash"  : "hash",
                },
                "ExpressionAttributeValues": {
                    ":nowTime": {"N": nowTime.toString()},
                },
            }, function(err, data) {
                  :

ConditionExpression の箇所がキモ。DynamoDBは予約語が多くて、それを回避するために #の別名を定義したり、プレースホルダとして :を定義したりと、慣れていないとハマる。他にも ”N"は数値だが、文字列で数値を渡さないと行けないとか...。

3. API Gateway作成

- - - -
しばらく iOSアプリからこのネットワークロックを使ってみることにする。

おわり。

新アプリ IconTimer をリリースしました。決めた時間をカウントダウンしてアラームを鳴らすだけのシンプルなタイマーアプリです。見た目にも音にもこだわりました。


特徴的なのは時間の選び方。
タップしたボタンの数字を足した合計が計測時間（分）になります。


以下は紹介動画。




時間・アイコン・色を自由にカスタマイズ。




以下は開発メモをつらつらと書きます。

ユーザインターフェイスめも

既存のタイマーアプリを使っていて毎回不満に感じていたのは、時間を選ぶ時に頭の中で「ひっかかり」があるところ。うまく説明できないのだけれど、あえて言えば時間を選ぶ時に注意を払わせるのが苦痛だった（どんだけものぐさと言われそうですが。。）
アプリを使うのがちっとも楽しくない。


例えば電卓式の時間を直接入力するタイプの場合、目的の数字を押してスタートするだけ....なんだけど打ち間違えたらクリアしないといけない。だから無意識のうちに間違えないように注意を払う。それがひっかかる。一方あらかじめ時間がリストで選べるタイプの場合、たくさんの選択肢から目的の時間を注意を払って探さなければならない。これもひっかかる。

そんな気を遣わずにポン・ポン・ポンと選ぶだけで時間が選べる UIはできないのか？それが開発の出発点だった。注意を払わ無くて良い UIって、きっと失敗しても直すのが苦にならないものだろう。試行錯誤がしやすいUI はどんなものか。





最初イメージとしてあったのは、少ないボタンを配置してそこから時間を選んでスタートするデザイン。どうせよく使う時間は決まっているだろうから、あらかじめ好きな時間を割り当てておけばボタンは少なくていいだろう。数が少ないのでひと目で把握できて判断もしやすそうだ。ただ問題なのはボタンが少ないと時間のパターンが物足りないこと。さらに使う前に時間を決めて設定するのはいちいち面倒。もしパターンを多くしようとボタンを増やせば選択方式と同じ罠に陥る。


そんなことを思いつつプロトタイプをひたすら弄ってた。ふとボタンを排他的に扱うではなく「足し算」にしたらどうかと思いつく。タップした時にONだった他のボタンをOFFにするのではなくそのまま残す。その残ったONボタンの数字の合計がタイマーの時間とする。逆にもう一度押すとOFFになり、その分タイマーの時間が減る。つまりタップのON・OFFがちょうど足し算・引き算の意味を持つことになる。これなら間違っても何度でもやり直せる。そして何よりもこの方法だとボタンの数以上の時間パターンを作り出すことができるのに気がついた。