UILabelの文字が欠ける現象にハマった

ハマったことシリーズ 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)

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

Read More

影付き文字列でハマった…

ハマったことシリーズ 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倍の値を入れていました。つまり影の長さが長すぎる場合、描画が遅い現象になることが分かりました。ほとんど視認できないくらい薄い影を、真面目に画像計算をしていたという事なのでしょう。

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

Read More

malc更新日記 その５

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

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

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

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

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

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


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


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

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

Read More

文字コードから文字への変換 － "\u{nnnn}"の話

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

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

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

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

いや~　お恥ずかしいｗ

Read More

Apple Watch

Apple Watchについては下記のような意見をよく目にします。実際に使われてのコメントなので、正直な感想だと思います。
"iPhoneがあればWatchは不要。通知もiPhoneで見ればいいし。"
"iPhoneを運べないようなきついスポーツ用に単体で使えるアプリない現状ではWatchは無意味。"
ただ、万人がそうだと断定しているように読めるのが気になりましたので、違う意見を書いておきたいと思います。

前提

前提として、Apple Watchが役に立つかどうかは、生活スタイルによるところが多いのではないでしょうか？
特に、公共交通機関の乗り降り、乗り換えを含む、徒歩移動が多いか少ないかではないかと。　仕事中も殆どずっと自席に座っていると、仕事中はPCだけでも充分かもしれません。

通勤

私の場合は、１回乗り換える電車通勤があり、電車内だけでなく徒歩移動中もかなりの人口密度になります。
そのような時は、Watch+Y!乗換案内で、都合のよい電車に乗るのに急ぐべきかが分かるのは、とても便利です。おかげで急いだのに、途中駅どまりの電車だった　といった残念なことが防げています。
これにいちいちiPhoneを鞄やポケットから出していると、急げないし、急いでそれをすると危険です。時刻を確認する程度の動作でできるのがポイントです。

仕事中

仕事中も１日３～５回の会議があります。会議室の数も数十室あり、PCや飲み物をもって移動することになります。
こちらも要点はさきほどと同じです。ここで使うのはWatch+Outlookです。会議だ！と席を立ってから、会議室はどこか？をサクッと知りたいのです。PCなどで手が塞がっているので、iPhoneを出して起動するのが面倒なんです。
（立つ時に見たはずの会議室を覚えてないという短期記憶の悪さが原因の気もしますがｗ）

通知は、緊急さでアプリ毎にOn/Offすると結構便利です。
PCには仕事系は全部、iPhoneにはほぼ全部、Watchには緊急度の高いものだけが通知するように設定しています。　そうすると、集中しているときでも、通知を今すぐ見るべきかが分かります。

休日のおでかけ

iPhone運べない程の きついスポーツなどしないｗ。　かる～いスポーツでもiPhoneを出さずに確認できるのは、とてもラクちん。サイクリングで走りながらでも難なく確認できる。
地図の確認など、必要性がとても高いなら、信号待ちなどでiPhoneを出してもいいのですが、どの程度のworkoutかな？とかはやらない。ウォーキングとかもそう。それこそ、お散歩ならいつでもiPhoneを操作できるのですが、あまりやらない。（1人ならするかもですが、1人で散歩はしないし）
ラクにできるのがキモチ良い。
そうそう、標準のアクティビティとかワークアウトとかでもいいけど、Flask LLPさんのZonesがリアルタイムで運動強度の確認ができて結構いい。　センサーの関係でiPhoneだけで同じことは出来る訳ないが、万が一できても利用シーン的に不自然で使わないかな。

家で

itunes(musicね)のリモコンも便利。　実際には家の広さは関係ない。食事初めてから席を立たずに音楽をかけられるのはキモチいいですね。

まとめ

そういえば、スマホが出始めのころ、PCがあればスマホは不要と言われていました。実際には、いつでも使えるというところが棲み分けポイントでした。(最近はスマホあるからPC要らないになってますが。。。w)
Watchとの棲み分けは、もう少し微妙で、キモチよいかどうかという程度なのかも知れません。
Watchでないとできないキラーアプリが必要という意見もありますが、スマホにもそんな機能はなかなかない気がします。いつでも！とか、キモチいい！　なのかなと思います？

蛇足ですが、実は一番良く使っているのはiPhoneを探す機能かも。家の中で、すぐどっかに行くのですｗ　　（いや、毎日8回は必ず使うsuicaが一番か？ｗ）

Read More

いつでも調整できるタイマー － Adjustable Timer

また新しいアプリをストア公開しました。　タイマーアプリです。

今回は、このアプリのメイキングオブ的なお話です。


実は、はじめからタイマーアプリを作りたかった訳ではないのです ^^;;

別なアプリを考えている時に、数字の入力方法の新しいUIを思いつきました。
新しいUIというのは、ボタンです。　タップするとボタンに書かれた数字が入力できます。　そして、ドラッグすると大きくなり、大きくなるにつれて、入力できる数字も大きくなります。　その状態で指を離すと　その時の数字が入力されます。
あまり見たことがない操作方法なので、ドラッグ＆リリースとか勝手な名前を付けています。^^;;

先ほどのアプリ自体は、行き詰ったというか、少し飽きてほったらかしです。（最近、そのパターンが増えましたｗｗ）
でも、このUIを試してみたくて、簡単に作れそうで、数字の入力が主であるモノとしてタイマーを思いついたという次第です。

流石に、これだけでは つまらないので、タイマー自体の機能も少し工夫してみました。
タイマーって、スタートさせると、一時停止ぐらいしかできませんよね？　それを、カウントダウン中にも　時間を調整できるようにしてみました。
出来上がって自分で使ってみると、この逆転が ちょっとキモチいい。　とりあえず、タイマーを開始して、それから何分にするかをゆっくり考えられる。　ただそれだけなのに、ラクちんなんです。


という訳で　タイマーアプリができました。
いつものように無料アプリですので、よろしければ是非お試しください。

iTunesで Adjustable Timerを見てみる

Read More

Autolayout＋UIScrollView＋UINavigationBarで 不要な余白

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

今回は、Stroryboardで UIScrollViewを貼ったときに 不要な余白が入っちゃったお話です。

ヘルプ的なものを縦に長い画像で作り、それを縦スクロールで見てもらうことにしました。　このくらいはコード不要で出来るかなと調べると、とても参考になる記事が！　ありがたや。

　[iOS]　Storyboard上で UIScrollViewを設定する

基本的には　このとおりやれば出来ます。　少し悩んだのが、UIImageViewの"高さ"の制約。　画像は事前に用意したものですが、参考記事のように高さの制約を絶対値で入れると、画像のアスペクト比が狂ってしまいます。UIImageViewにAspectFillを設定してもAutolayoutの計算には使ってくれないようで、UIImageViewのAspect比の制約を自分でちゃんと設定する必要があります。

これで出来上がりと思ったら、上部に不思議な余白が。。。　　UIScrollViewの地色が見えていました。

UIScrollViewの上部制約をいつもの調子で Top Layout Guideに合わせたのが原因でした。　ただ、storyboard画面では綺麗にレイアウトされて見えるし、というか逆にSuperviewの上部に合わせると　下図のように 画像の上部が見えないし・・・、しばらく悩みました。

余白の高さは　ナビゲーションバーの高さっぽいところでピンッと来て、試しにUIScrollViewの上部制約をSuperviewの上部に合わせてみると解決しました。

ナビバーがあるとUIViewControllerのルートに乗ってるUIViewが、縮み　さらにTop Layout Guideの位置が、すなわち UIScrollViewの上部が下がるのでしょうかね？　　　っと言っても…、スクロールビューが下がり　ルートViewが見えてるわけでもなく。。。。　ちょっと意味不明。　　contentSizeとかがズレるのでしょうか。。。
ちょっと疑問点が残りますが、上手く行ったということでｗｗｗ

Read More