2015年2月19日木曜日

今回は、プログラミング関係で 先人達に学んだことを、つらつらと。


●写真編集系アプリでよくある 他のアプリとの連携はどうすればいいか?
UIDocumentInteractionControllerは、instagramと他のアプリとの両立方法が難しかった。参考になるのはこれ!

Stackoverflowの記事「UIDocumentInteractionControllerDelegate methods not called when open system apps like Mail, Messages, Twitter or Facebook
この記事で、 instagramには 「**.ig」ファイルを 他のアプリには 「**.png」ファイルを渡せるようになります。 質問者と回答者が同じなのが面白いw
Option付き(presentOptionsMenuFromBarButtonItem+ documentInteractionControllerWillPresentOptionsMenu)だと、なぜか うまくいかない…

Cocoaの日々の記事「UIDocumentInteractionController にファイルを別名で渡す」
ファイルが二ついるのだけど、二つセーブするのは非効率なので。ハードリンク使えばいいじゃん!という思いつきにつながった記事。 結局うまくいかなかったけどww

※Instagramアプリが 拡張子igだけでなく pngなどをサポートすればすむことなのだけど。。。w
※UIActivityViewControllerは、出てくるアプリの数が少ない。 LINEやInstagramを加えるにはカスタムを追加しなければならない。。。


●Flurry SDKを Swiftから使う
アプリの分析を無償で出来ることで有名なサービス。知らなかったけど、Yahooが買収したのですね。

Qiitaの「iOSでFlurry Analyticsを使ってみる」
makotton.com の「iOSにFlurry SDKを導入する」
この2つの記事は Objective-Cの場合ですが iOSで Flurryを使う手順が書いてあります。

AdMax Tech Blog の「【iOS】BridgingHeaderの使い方と設定方法」
この記事は、Objective-Cのライブラリを Swiftから使えるようにする手順が書いてあります。


●SpriteKitを使っているときの Pauseの話
バックグラウンドからの復帰時などに Pauseしない。。。 という障害を直すのに参考になった情報のリストです。

CODE NINJAの「Pausing a Sprite Kit Game, Correctly」
この記事がパーフェクト! ほかにも下記のような記事がありました。
http://stackoverflow.com/questions/19014012/sprite-kit-the-right-way-to-multitask


stackoverflowの「Difference between paused property of SKScene and SKView」
これは、タイトルのままですが pauseプロパティを持つものが2つあるので 何が違うの?という話。

shinyaohira / App States and Multitasking.mdの「アプリの状態とマルチタスキング」
アプリの状態遷移の話。 AppDelegateの各関数がどのタイミングで呼ばれるか?という話。





2015年1月21日水曜日

今回は、お勉強中のプログラミングの話。

レスポンシブとかアダプティブとかが流行ってるし(細かな違いは分かってないのですがw)、iOSのプログラミングもマルチ解像度時代ということで、ぼやっとしか理解できていなかったAutolayoutをお勉強しました。

かなり個人的なメモですが、いろいろ先人の情報を見て やっと腑に落ちたので公開します。

PinだとかAlignとかイロイロあるけど、分かりやすい解説はいっぱいあるし(例えばこれ)、バラバラには分かる。 分かるけど何か もやっ と引っかかっている。  理系なので、根底の原理原則のレベルで理解したい :-)
どの制約も制約編集画面(「Attributes Inspector」)を見ると 「First item」、「Relation」、「Second Item」、「Multiplier」、「Constant」が出てくる。 結局、どの制約も最終的に これらのパラメータで表せるっぽい。


FirstItem = multiplier × SecondItem + Constant

分かってみると簡単で、これらのパラメータは上式のような関係になっていて、等式だけではなく Relation ≦ ≧ という不等式も表せる。というものでした。 

Aspect Raitoも muliplierに1:2とか表示される。 これは 1/2 = 0.5 ということで、View.Width = 0.5 * View.Height つまり W:H=1:2となるわけですね。 簡単カンタン

で、Leadingは 左側のx座標で、Trailingは右側x座標だから、View.Leading = 0.5 * Superview.Trailing とかすると、親ビューと左右中央に 子ビューの左端が揃うわけですね。(multiple = 0.5 のときは View.Leading = Superview.centerXの方が直観的ですけどねw)。 で、20pixelマージンが欲しければ、View.Leading = 0.5 * Superview.Trailing + 20 とかすれば良いんだ。

最後に、size classと組み合わせた例が moving gifもあいまって、英語だけどわかりやすかったのでリンクを貼っておきます

もしかしたら続くかも… なので、その1ww 


2014年10月26日日曜日

こっそり、普段使いのシンプル電卓 malc(マルク)のバージョン: 1.21が公開になってます。 iPhone6/6Plusの画面解像度に最適化しました。


今日は、レビューへの誘導の話

ストアに★をつけてもらったり、コメントを書いてもらうレビューを書いてもらえたら、開発者として励みになるし、マーケティング効果も高いことは有名ですね。
有用なコメントをもらったり、好意的なレビューをしてもらうテクニックとして、レビューへの誘導タイミングや誘導方法が重要という情報もよく目にします。

いろいろ見てて、参考になる と思ったのは たとえば下記のようなWebページ
レーティング誘導で好評価を貰うには
アプリのレビュー評価はASOに効く!

「誘導は ある程度使ってもらってから」「ゲームならステージクリアしたときなど気分が良い時に」「好評価の工夫として”面白いので評価する/つまらないので評価しない”という誘導の文言にする」などがなるほど!と思いました。


私は、他のアプリを使っていても、起動直後にダイアログを出すものしか見たことがなく、とにかくウザイという認識でした。  そもそもmalcではAdも計算結果を表示した後に出すようにして、邪魔しないように気を付けているし、レイティング誘導は もっともっと 「とにかく邪魔しないように!」「余分なスペースを使いたくない! ということで、Adの領域に誘導バナーを出すことにしました。

iAdのようなデザインでレビュー依頼のバナーを相方に作ってもらい、2%の割合でレビュー依頼を出すようにしました。 これならモーダルダイアログではないのでユーザの作業に割り込みませんし、専用のスペースも取りません。また、何度も誘導されるのもウザイので、一度タップしてもらえれば二度と出ないようにしてあります。

そして、タップされたら、SKStoreProductViewControllerを使って AppStoreに誘導します。 ストリームで飛ばしてしまうとストアアプリに移動してしまいますが、この方法なら、アプリを出ないので元の画面にすぐに戻れ、わざわざ協力してくれた人に負担が少なくていいかと思います。

たくさん、★がつくといいなぁww

2014年10月13日月曜日

今回は まだ検討中のアプリの話

このアプリではいわゆる世界時計機能が必要なんです。
タイムゾーンが分かれば、日時を表示することは簡単。たとえば、America/Los_Angelesなら下記のようにすればできます。
    NSDate* date = [NSDate date] ;
    NSDateFormatter *formatter = [[NSDateFormatter alloc]init] ;
    [formatter setTimeZone:[NSTimeZone timeZoneWithName:@"America/Los_Angeles"]] ;
    [formatter setDateFormat:@"dd a HH:mm (zzz)"] ;
    NSLog(@"%@",[formatter stringFromDate:date]) ;

課題になるのは、国名・都市名からタイムゾーンを調べられる辞書が必要なのこと。
今回はそれについて調べました。

iOSが持っているタイムゾーンのリスト

主要都市のタイムゾーンはNSog(@"%@",[NSTimeZone knownTimeZoneNames]); で表示できます(iOS8で425タイムゾーンのデータが表示されました)
Africa/Abidjan
Africa/Accra
・・・
Pacific/Wallis
でもこれには、San Franciscoも載っていないレベル。 また、国名が分からないので、同名都市もあるし、国名から検索もできないので不便です。

tz database

このDBは、パブリックなタイムゾーンのデータデータベースで、America/Los_Angelesというような命名規則を作った おおもとデータなんですね。いろいろ工夫した末の命名規則のようです。いろんな所からD/Lできるようですが、ここから落としてみました(2014/9/24時点で415タイムゾーンのデータが格納されていました)
1,     AD,  Europe/Andorra
・・・
390, US,  America/Los_Angeles
・・・
415, ZW, Africa/Harare
zone.csvが上記のような国名の省略形とタイムゾーンの組の形式になっていて、国名の省略形と通常形の組のcountry.csvと合わせるとタイムゾーンの国名が分かります。knownTimeZoneNamesと比べて10都市くらい足りないけど、これくらいなら自力で調べられる範囲ですね。

City time zone

このDBは、千都市以上のタイムゾーンが載ってます(2014/10/3時点で1310都市のデータが格納されていました)。ただ、タイムゾーンが Tokyo Standard Timeなどの表記で iOSで使える形式ではないので、国名と都市名をもとに変換する必要があります。ただ、2つの都市が同じタイムゾーンだということが重要な情報で、Tokyo Standard TimeのOsakaのタイムゾーンが Asia/Tokyoに出来るわけです。

結合と変換

knownTimeZoneNamesと tzdataから、"国名/都市名"とタイムゾーン名のペアを作ります。
Ivory Coast/Abidjan, Africa/Abidjan
Ghana/Accra, Africa/Accra
・・・
Wallis and Futuna/Wallis, Pacific/Wallis
これを city time zoneと混ぜ(等価結合、VLookup)ます。 Japan/Tokyoが一致するので Tokyo Standard TimeをAsia/Tokyoに変換でき、同じタイムゾーンのOsakaも Asia/Tokyoと変換できます。 knownTimeZoneNamesにしかない都市や、city time zoneにしかないゾーンもあり、最終的には1478都市の辞書ができました。 そのうち、適当な場所で公開したいと思っております。

2014年9月29日月曜日

無事、ストア申請に通り、 9/24から公開始まりました!

malcのアイコン
普段使いのシンプル電卓 malc(マルク)
無料
バージョン: 1.2


レビュー待ちが長く、いつもより少しかかりましたね。iOS8対応の申請ラッシュでしょうから、仕方ないですね。(AppStoreの中の人ありがとうございます)

公開されたら、次にやるのは宣伝です。
いつもお世話になってる iPhonePlusさんに記事を投稿しました

投稿後、一日に700人以上の方からダウンロードされていました。すごい!


今回は、Searchmanを参考にして、キーワードを見直したりして、検索知名度も急上昇。
「メモリー電卓」 とかでストアで検索すると5位に出てきたりします。

ぜひ、多くの方に試していただきたいです。


2014年9月18日木曜日


他のアプリのiOS8版アップデートを横目に、ストア申請結果を待つ毎日です。

今日は、C(Clear)キーの話しです。


これは市販の電卓や 標準の電卓アプリにもある機能で、直前の数字入力をなかったことにします。
つまり、1080×30と入力した後に、Cキーをタップすると 1080× までしか入力されていない状態に戻ることになります。

malcの場合も同じように動きます。ただ、malcには BS(BackSpace)キーや カーソルキーもあり、「直前の数字入力」を消すだけでは 何か物足りない。。。 ということで、カーソルキーの左側にある数字を消去するという仕様にしました。 要するに、下図のような編集操作ができるということですね。(上段の状態でCを押すと、中段の状態になる。 そしてそのまま数字を打つと下段の状態になる)


このスクリーンショットは iPhoneのカメラや解像度の進化を題材にしていたりします。早くiPhone6欲しいなぁww


プログラム的には、[myTextField offsetFromPosition:toPosition:] でカーソルの位置を求め、先頭からカーソル位置までを対象にして、正規表現[0-9.]+$にマッチする文字列を空文字に置換をかけることで実現できます。 一つ注意としては、myTextFieldに置換結果をセットする前後で、右からのカーソル位置を保存して、戻してやらないといけないことです。これを怠るとカーソルが一番右端に動いてしまって、消した位置に数字を入れ直す操作がしづらくなってしまいます。
int pos = [myTextField offsetFromPosition:myTextField.beginningOfDocument  toPosition:myTextField.selectedRange.start] ;
NSRegularExpression *rex = [NSRegularExpression regularExpressionWithPattern:@"[0-9.]+$" options:0 error:nil] ;
[rex stringByReplacingMatchesInString:text options:0 range:NSMakeRange(0, pos) withTemplate:@""] ;


malcは答えだけでなく 式もメモリーしているので、式の一部の数字を変えて計算しなおすことが簡単です。 そのようなときに、BSキーだけでなく Cキーを使うと便利だと思っています。 




photo by 

2014年9月17日水曜日



週末に「普段使いのシンプル電卓 malc」 のバージョンアップ申請をしました。 iOS8対応、iPhone6対応を含む多くの機能強化、新しいiTunesConnect と 盛りだくさんのアップデートです。 (申請しちゃったら、あとは すんなりレビューを通ってくれることを祈るしかありません)

さて、今回は、キーボードの進化について


きっかけはACキーとBSキーの切り替える機会が多くて面倒だったこと。これを何とかできないかを考え始めました。

最初の思いつきでは、
  • ACキーとBSキーを縦に並べ、その代わりにカーソルキーとして使うキーを1つに減らす 
  • カーソルキーを長押ししたら、すぐ上に、4つのカーソルキーすべてが表示される
という仕様でした。これならACキーとBSキーはとても使いやすくなります。
ただ、色を変える上下キーは滅多に使わないけど、左右キーは良く使うし同時に使う事が多いので、切り替えは面倒そう。 ということでボツにしました。

さきほどのアイディアを改良して、OS標準の日本語入力キーボードのように、フリック入力する方法で解決しようと思いました。
  • 長押しで、キーの上下左右に、隠れていた上下左右のカーソルキーが表示される
  • 表示前でもフリックで入力できる
という仕様です。 ただ、カーソルキーを左端や右端に置けなくなるのでボツ。

ここでいったん検討のキッカケまで戻って、なぜACキーとBSキーを切り替える機会が多いのかを考えました。 
まず答えを求めた直後に、ACを使うことが多いのは想定どおり(ここはACが表示されているのでOK)。 問題は、答えの数字を再利用しないのに、続けて数字をまちがって打ってしまった場合にACを使うこと、しかもその頻度が多いことだと気が付きました(その場合は、BSキー表示から ACキー表示に手動で切り替えないとダメ)。
自動的に答えが再利用されるより、計算結果を使う場合にはメモリをタップして、直前の答えを入力してもらう方が自然のような気がします。 そこで次のような仕様にしました。
  • 「答えの再利用をするか? しないか?の仕様を選んでもらう。デフォルトは「再利用しない」
  • 再利用されない時の答えを、式入力の時より明るい色の表示色にする
2つ目の仕様は、よく見ると答えが再利用されるかが見た目で区別できるようにという目的です。
プログラム的には、UITextViewのtext色よりplacehold色を明るくしておきます。そして再利用されない場合は答えは placeholdに代入します。これでキーを打つと答えが消えるというのが自然に実現できます。

これでおしまいにしてもよかったのですが、Cキーを付けたかったこともあり、キーボードはやはり進化させることに。ACやCキーは、他のキーに比べて誤って押しづらい方がいいということもあり、結局ACキーを独立させました。 場所は、キーボードの領域内ではなく、この記事のトップ写真のように、主表示(物理的な電卓でいうとLCDの部分ですね)領域の左上端にキーを置くことにしました。

さらにさらに、キー配置のカスタマイズができるようにしました。
大昔にCASIOが決めたという電卓型レイアウトは、下から0,1,2,3 ...と配置されます。 一方、 電話型(もう誰もそんな言い方しないプッシュフォンですねw)レイアウトは、上から 0,1,2,3 ...と配置されます。どちらが良いかは人により違うかもしれません。 テンキー以外も、デフォルトでは 演算子が左端 カーソルや=が右端ですが、逆に配置したり、両方とも右側に集めるというレイアウトも選べるようにしました。
具体的には 次のようなプログラミングにしています。
  • ボタンの生成と、配置を同時に行うのをやめ、分割して行う。
  • ボタンを生成(フォントサイズの調整、イベント登録)し、キートップの文字列をkeyとするNSDictionaryに ボタンオブジェクトを格納しておく。
  • 配置パターンは、キートップの配列を複数パターン作っておいて、設定でそれを選択する。
  • 全体レイアウトとテンキーレイアウトが入れ子関係なので、上記配列も入れ子関係で表現しておくき、その2つでボタンを配置を行う。


おまけと言ってはなんですが、キータッチを改善するために、BSとAC/CはUIControlEventTouchUpInside、それ以外はUIControlEventTouchDownでイベント処理するようにしました。 UIControlEventTouchDownにできるのは、ボタンが大きいデザインならではの修正です(ボタンが小さいとミスタッチが増えでかえって使いづらいと思います)。 この修正で、式の入力などはボタンを押したタイミングで反応するので、即応性が高まりました。修正系は押し間違えを防ぐため、わざと即応性を落としボタンを離したタイミングで反応するようにしています。
標準アプリも含めて他のアプリではあまりされていないようなとても細かい修整ですが、キモチ良く使っていただけると嬉しいです。



photo by