ラベル bucho- の投稿を表示しています。 すべての投稿を表示
ラベル bucho- の投稿を表示しています。 すべての投稿を表示

2020年6月30日火曜日

アップデートから、すごく時間がたってしまったのですが...。

カシオの「余り計算電卓」が品薄になったワケ』という記事が最初だったと思います。 この用途はあるなと。
そして、もともと作っていた電卓アプリmalcをもとに、余り電卓を作りました。おやじギャグで amalc(あまるく)とか命名w。

しかし、完成して提出するも、あえなくリジェクト。理由は Design4.3「ほとんど同じアプリを複数出すとかスパムじゃん」。少し食い下がりましたが、お返事は「元のアプリの機能強化にしたら?」というもの。 ググると、みなさんお困りの様子。 これは闘ってもダメだなと。

ただ、シンプルさがウリなので カシオさんの電卓のように専用キーを足す場所はないし、設定で切替などすると台無しだし、ということでしばらく悩みました。(というか、その課題認識があったので別アプリにしたのだが、何とか突破するしかない状態に)
カシオさんの事例のように薬剤師さんが使うとすると、錠剤が何個かまとまっているシートの数<商>と、バラの錠剤の数<剰余>を計算するときもあれば、普通に有効成分のパーセンテージ計算<小数表記が知りたい>もするでしょうし…

そこで思いついたのが、普通に整数で割り算すると 小数表記 と 余り表記 を両方表示する というもの。整数以外で割ると少数表記のみ。

そして、一旦無事通過したのですが、致命的バグを直後に発見。一旦公開停止し、すぐにバグ修正。そしたらリジェクト。理由は Design4.0 your app were crowded or laid out。 スクリーンショットも付いていたのですが、どこが悪いのか全く分からない…。 iPadで何かレイアウトなどが悪いということなのだろうが....。
バグあり版は、気づいて直ぐに公開停止したのだが、既に500人位の方がアップデートして下さっているので焦る。

もしかしたら?と思ったのは UITableViewで、式と答えの履歴を表示していて、最新のものを一番下に配置していて、当然そちらは全部見えるように気を付けているが、画面の一番上は上部が途切れていても (過去の情報だし)スクロールしてもらえばいいよね?という割り切りをしていること。読みやすいフォントサイズなどは気にしているが、画面解像度やアスペクト比はイロイロあるし、ステータスバーの高さも固定ではないので、テーブルの表示行数は割り切れない場合を許容している。
もしこれだとすると、スクロールしてくれれば問題ない。 ということで、スクロールできることを表現するUIにしてみた。具体的には、起動すると、一瞬スクロールして最新履歴が表示されるようした。

単に再申請したからなのか、上記の修正が良かったのかは不明だが、合格でき、公開することができた。
よかった。

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



2016年11月25日金曜日

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

前提

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

通勤

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

仕事中

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

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

休日のおでかけ

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

家で

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

まとめ

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

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

2016年11月4日金曜日

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

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


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

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

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




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


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

2016年9月7日水曜日

ハマったことシリーズ 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とかがズレるのでしょうか。。。
ちょっと疑問点が残りますが、上手く行ったということでwww

2016年8月30日火曜日

今回は、iTunesConnectでのアプリスクリーンショットの簡易提出関連の覚書です。

iPhone、iPadとも最大サイズのスクリーンショットをアップロードすればよくなりました。

  • iPhoneは 5.5inch サイズの1242×2208
  • iPadは Proサイズの2048×2732

当然、最近はAutolayoutで作っているので、640x960、640x1136、750x1334、1242x2208、・・・などと解像度が違えば、表の表示個数が変わったり、細かな違いはあるものの大枠は同じです。 ありがたく使っちゃいましょう。(新しく作ったアプリが、ユーザの方にウケたら、イロイロ凝るという戦略もアリでしょうw) 

解像度の違うマシンも画面かも知れないことのヒントも兼ねて、iPhoneへのはめこみ合成をしましょう。  現在、LaunchKitが使えないので、そーいう時は iPhone Screenshot MakerなどでiPhoneへのはめ込み合成をします。
文字入れとか凝ったレイアウトなんかは power pointとか使うこともあります。 そのときは21.03cm×37.389cm(iPadは proの1/2サイズで17.37cm×23.13cm)の画像を作って、多少解像度が違うところは Macのプレビューでサイズ変更すのが楽ちん。 どうせ、プレビューの書き出しでαチャンネル無しにしたるするしねw


2016年8月26日金曜日

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

今回は、swiftでiOSのバージョンが特定値以上かを判定するお話です。

以下のようなコードで iOS8系か、iOS9系かを判定していました。
ios8VersionFlag = Float(UIDevice.currentDevice().systemVersion) < 9

しかし、バージョンが 9.1などならいいのですが、9.3.4などとなると Float("9.3.4")というのはFloatに変換できず、nilとなる。 つまり、(nil < 9)の結果として、Flagがtrueとなってしまい、障害の原因となっていました。(see→補足)
最終的には、こんなコードにしました。 これなら安心。
ios8VersionFlag = UIDevice.currentDevice().systemVersion.compare("9.0.0", options:.NumericSearch ) == .OrderedAscending

2016年8月24日水曜日

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

今回は、UITextFieldのinputView に穴のあいたキーボードを設定しようとした話しです。


下のUIButtonが操作できるように、穴があいているキーボードをUIViewを継承して作ろうと思いました。 穴の部分は、そのUIView自体で、色をclearColorにして、タッチイベントをnextResponderに伝えようにしすればいいかなと。
穴でない部分は、普通のボタンなどを貼るつもりでした。

が、実際に作ってみると、ダメじゃん!! 

穴ない(ブラー??)、タッチイベントも通らない。 きっと、下地として UIViewがあるんですね。 


つまり、この方法はムリっぽいのね。 自力でやるしかないか。。。

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

今回は、複数Macでの開発に伴う試行錯誤の覚書です。

証明書のコピー




Organaizerで、「何度も キーチェーンのアクセスのID/PW入力がでる現象」


  • iOS Developer、Apple IDの秘密鍵のアクセス制御を、「これらのアプリ~常に許可」に ”xcode”を指定
  • iOS Distributionの秘密鍵は xcodeで常にではなく、全てのアプリに許可にする。(なぜ?w)
  • 証明書は 信頼 > 「システムデフォルトを使用」 にしておかないと、iTMS-90034エラーが出る。(上記現象を直す試行錯誤として、「常に信頼に」したらダメだった)


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