2017年10月31日火曜日

「壁ごよみ」の開発日記の二回目です。

Appleさんの申請にパスしました。出荷日の11/3の前にパスして良かった!!
iPhoneX対応もしているので、スクリーンショット登録できるようになったらしいので、やらねば。


今回は、操作方法の設計についてです。

このアプリは、ロック画面用のカレンダー付壁紙写真を作成するアプリです。
目的としては、かなり単純な部類なので、それにマッチしたサクサクした使い心地にしたいと考えました。

ただ、操作手順としては沢山のステップが必要です。
  1. カメラロールから写真を選ぶ
  2. 表示する月を選ぶ
  3. 写真の拡縮をする
  4. 写真の主題に被らないカレンダーの配置をする
  5. カレンダの拡縮をする
  6. カレンダーの文字の配色を決める
  7. カレンダーの文字フォントを決める
  8. カレンダーの文字の枠内の配置を決める
  9. 写真を保存
  10. 写真アプリで、壁紙に設定する
サクサクした使い心地にするために、この操作手順をできるだけ簡略化したいと考えました。
1は、写真変更のボタンを押す手間を削減するために、アプリの起動後に写真選択画面をすぐに起動する設定を設けました。
2は、起動日にもとに表示月を自動計算することにしました。少し工夫したのは、来月1日と同じ週に起動した場合は、今月ではなく来月のカレンダを表示することにしたこと。
3、4,5は、利用頻度は低いと想定し、ピンチなどで操作できるようにしつつ、元のサイズ・配置に戻せるようなUIにしました。
4,6,7,8は、利用頻度が高いと想定し、自由に設定するのではなく、いくつかの選択肢を順に提示することにしました。
10は、9の操作後に写真アプリを起動するダイアログをつけました。

その結果、かなり操作ステップが少なくなり、ほとんどボタンのタップだけで壁紙をつくることができるようになりました。


2017年10月27日金曜日

今回は、「壁ごよみ」の開発日記です。

このアプリ、一言でいうと、ロック画面の壁紙にカレンダーを表示する専用の画像編集アプリという感じでしょうか。 まぁ、先人達のアプリがたくさんあります。

電卓のmalc、 世界時計的なWTimeCalc、タイマーアプリのadj.timer など なんでレッドオーシャンばっかり攻めるのか?と、企画部門のシニアマネージャをしていた経験から、自分自身を小一時間説教したくなるところですw

当然、開発に至った経緯というのがあります。

まず、自分自身、iPhoneを買ってからずっと、ロック画面にカレンダーを表示していたのです。 そのために、たくさんのアプリを使ってまいりました。
古くは Q Calendar 、つい最近までは L.S.Calendar など。

なのですが、開発者の皆様 使われていないのか、現在の機種/OSに未対応とか、写真が90°回転してしまうとか、致命的な状態です。 その他のものも、デザイン的にどうしても気に入らない。。。

つまり、最初は 仕方なく という理由でした。

ところが、いつものように デザインを美しくとかだけでなく、何か新しいアイディアが伴っていないと、開発できないタイプでして。 

ちなみに、
malcは、メモリー(M+とかM-とか)の分かりやすい概念を思いついた。
WTimerCalcは、ある瞬間の世界時計ではなく、飛行機旅行のようなスケジュールを扱える世界時計が欲しかった。
adj.timerは、カウントダウン中に時間を足し引きできるタイマーが欲しかった。
という、something newがございます。

で、壁ごよみのsomething newは、標準カレンダアプリ上の予定を読み込んで、マークをつけられるという機能になります。 例えば、誰かの誕生日には●を、デートには♥を、と印をつける機能になります。


っと書いておいてなんですが、Appleさんに申請したばかりで まだパスしておりませんw
デザイナーが購入予定のiPhoneXにも対応させたので、予約日の10/27に申請できるように頑張ってみました。11/3の前にパスしますよーに。


2017年10月26日木曜日

ハマったことシリーズ No19

今回も、開発の細かな話です。ハマったシリーズNo18では、UILabelに影付き文字列を設定していてハマった話をしましたが、今度はフォントによってUILabelが欠ける(特に、斜体系の場合)という現象に出くわした話です。

影付き文字列なので前後にスペース文字列を足して影の領域を確保していました。
左揃えの場合は、ちゃんと影もクロッピングされず綺麗に表示されています。 しかし、右揃えの場合は、文字が途中でクロッピングされてしまいます。スペース文字の個数などを増やしても表示に変化がありません。
なぜだ?? ということで、Debug view Hierarchyで見てみると、右揃えの場合、末端のスペース文字(全角・半角とも)が無視されるようです。(怒!! w)

Google先生に伺っても聞き方が悪いのかお答えが聞けず 散々悩んだ末、透明の文字列を末尾に追加することにしました。


let shadow = NSShadow()
shadow.shadowColor = .black
shadow.shadowBlurRadius = offset
let aStr = NSMutableAttributedStrings(string:"text")
aStr.addAttributes([NSShadowAttributeName:shadow], range: NSMakeRange(0, aStr.length))

let rStr = NSAttributedStrings(string:"-")
rStr.addAttributes([NSForegrounddColorAttributeName:UIColor.clear], range: NSMakeRange(0, rStr.length))
aStr.append(rStr)


という感じ。無事、期待通りの表示となりました! 先頭のスペース文字は無視しないが、末尾は無視するとは。。。 いや~、ハマった。


2017年6月29日木曜日

ハマったことシリーズ No18.

今回も、開発の細かな話です。アトリビュート付の文字列の描画がとても遅いという現象に出くわしました
やろうとしていた状況としては、40個位のUILabelがあって、それらに影つき文字列を設定しました。 その文字列の生成は、


let shadow = NSShadow()
shadow.shadowColor = .black
shadow.shadowBlurRadius = offset
let aStr = NSMutableAttributedStrings(string:"text")
aStr.addAttributes([NSShadowAttributeName:shadow], range: NSMakeRange(0, aStr.length))

という感じで作っていましたが、表示がえらく遅い。。。 この表示が遅いという点に囚われてしまい、小さな文字だったので気づかなかったのですが、実は影も表示されていませんでした。

半ば表示が遅いことを諦め、しばらく後に気が付いた影が表示されていないことに着目して調べていくと、offsetに想定の10倍の値を入れていました。つまり影の長さが長すぎる場合、描画が遅い現象になることが分かりました。ほとんど視認できないくらい薄い影を、真面目に画像計算をしていたという事なのでしょう。

プロファイラ―で調べたりイロイロしても、なかなか気づけませんでした。 いくら道具が優秀でも、視点がそこにないと分からないという典型でしょうか。 ハマりました。

2017年3月23日木曜日


ひさしぶりに malcを強化し、先日アップルさんに申請してみました。

今回のアップデートは2つ。

  1. 「答えの再利用」を「する」場合の挙動を変えました。
  2. 「=」直後のカーソルの位置を常に右端に。


まず1つ目。
再利用できたら便利なこともあるかもと思って作ったオプションですが、自分自身使わないなと。確かに、再利用したいときもあるんです。( )カッコの機能が省かれているので、必然的に式が2つに分かれるので、そーいうときには。例えば、(1+2)x3=という計算をしたいときは、1+2=3 3を再利用して、3x3=9と計算したい。 
ただし、別の計算がしたいことの方が多く、再利用したくない場合の方が多すぎるのが問題です。
で、今回、再利用したいときと、したくないときの違いに思い当りました。

再利用するときは、「=」直後に入力するのは”演算記号”だなと。先ほどの例だと、再利用したい「3」の後には「×」を入力する。 逆にしたくないときは、新しい式を入れるので、”数字”から入れ始めます。 つまり、”演算記号”なら再利用し、”数字”なら再利用しないようにすればいい。 細かくいうと、% や カーソル、BSは再利用する側に入れ、小数点はしない側にしました。

これなら使えそうと、自分自身も「答えの再利用」を「する」設定に替えました。


2つ目は、仕様バグの修正に近いかもしれません。 数字だけの状態でカーソルを動かし、「=」を押すと、カーソル位置が動かない仕様でした。たとえば、「123|」という状態でカーソルを動かし数字を入れ、「125|3」として、「=」をおすと、「125|3」という状態でした。
このままでは、再利用の場合に不便なので、カーソルを必ず右端にすることにしました。


はやく審査とおるといいなぁ…

#objective-c も時々さわって、忘れないようにするのだww

2017年3月16日木曜日

ハマったことシリーズ No17.

今回は、Swiftでの開発で文字コードを文字に変換するという細かい話です。

文字コードから文字へ変換する場合、 "\u{2665}"という記述で文字コードを指定します。
これは知っていたのですが、はじめて実際に使いました。 そこでドハマリしました。
なぜか、思った文字が出ない。

原因は…
\u{nnnn}は 0xとかつけなければ10進数かと思っていたのです。 強制的に16進数だったとは!

いや~ お恥ずかしいw