NavigationBar が View に重なる対応について

今更ながらのところでもあるけど、UINavigationController を使用している場合に、storyboard 上で、NavigationBar が View に重なる対応についてどうすれば良いかを考えて見ることにする。

この内容は iOS7 から View がフル画面表示に変わった時から発生した内容なので、なぜ今頃という面があるかもしれないが、今一歩良い対応方法が見つからないので、調べてみることにした。

ちなみに、今までは、先にビューのデザインをして、オブジェクトを配置後に、座標0, 0 の位置にずらす方法で対応していた。
よって、最終的にはナビゲーションバーの下にオブジェクトが配置される様になる。
この方法で、実行時には問題なく表示されるのだが、問題点はメンテナンスを行う際に、ナビゲーションバーの下のオブジェクトを見逃す場合があると言うこと。
(そんなバカなと思うかもしれないが、焦って対応をする場合などは案外見落としがちになる)
その他、あえてナビゲーションバー分下にビューをずらす方法も考えたが、Autolayout の制約が難しくなるので却下した。

この問題に対応すべく storyboard を使用した場合の良い方法を調べてみることにした。
調べてみると、みんなどうやってこの部分を対応しているかよく分からない。
この内容でよく引用されているのが以下の記事。

やはりお前らのiOS7対応は間違っている(解説編)
http://qiita.com/yimajo/items/254c7cebab7864678246

上記や、その他のサイトを見る限り以下の方法がある。

1. ViewController の Extend Edges の Under Top Bars と、Under Bottom Bars のチェックを外す
2. 上としっしょだが、コードで指定する
   self.edgesForExtendedLayout = UIRectEdgeNone;
3. NavigationController の Navigation Bar の Translucent のチェックを外す

いずれも、ビュー開始位置がナビゲーションバーの下からになる。
(すりガラス的な効果が消えたふうに見える)
その他、各 ViewController の Extend Edges の Under Top Bars のチェック、
同じく、ViewController の Adjust Scroll View Insets のチェックを外すなどもある。

うーん。
調べてみた結果自分の困っている内容(Xcode での視界性の悪さ)とは別の内容(アプリの仕様というか不具合対応)での回答が多いようだ。

ここいら辺を踏まえて、自分の問題に対するベターと思われる方法を考えてみた。
方法は、上記のいずれのチェックも外さずに、NavigationController の Attributes にある Shows Navigation Bar のチェックを外し、コード上でこの属性を有効にする方法。
これであれば、Storyboard からは、ナビゲーションバーの表示が消えて、作業・確認しやすくなる。
制約等も直感的に付けることが出来る。
この場合は、ナビゲーションバー先頭の ViewController の viewDidLoad で

[[self navigationController] setNavigationBarHidden:NO animated:YES];
// Swift
self.navigationController?.setNavigationBarHidden(false, animated: true)

とするか、サブクラスを作成して、上記のコードで指定するなどが必要。
難点は、画面上からナビゲーションバーが消えてしまうので、ナビゲーションバーが存在しないかと思ってしまう点か。
(storyborad に UINavigationController が出ているから大丈夫とは思うが)
あくまで、ベターなのでベストがわからない。。。

しかし、なぜこんなに苦労が必要なのだろうか？
storyboard で見えたとおりに表示されないという Xcode 側に問題がある気がするのだが(ナビゲーションバーとフル画面を表示したいなら storyboard でナビゲーションバー部分を別表現すればいいのに)、Xcode 作っている開発者は違和感覚えないのだろうか？

Written with StackEdit.

デジタルノート環境について

文具ネタ

年も押し迫ったということで、資料というかメモ紙の整理をしていた。
普段は、A4 のコピー用紙をメモ紙にしているが、物凄く大量に紙を消費してしまう。

これはアカン(経済的にも、環境的にも、情報整理的にも)と思って、iPad で使用できるデジタルペンとアプリに移行しようと目論んでいた。
その時に買った内容とその時のレビューが以下の内容

BAMBOO STYLUS fineline を買ってみた
http://tizio1976.blogspot.jp/2015/09/bamboo-stylus-fineline.html

結果をいうと、実務ではかなり厳しかった。
厳しかった内容は以下のとおり

• 拡大領域で書くので感覚が慣れない(紙とペンは1対1)
• 考え事や、タイピングをしているとその間にペアリングが切れてしまう
• パームリジェクションが今ひとつ

慣れの部分もあるかもしれないが、慣れる前にストレスがたまりまくり効率が悪くなった。
結局、紙とペンのに戻ってしまった。

あれから、iPad Pro + ペンシルが良いとのレビューを見たが、割りかし高価なため、用途を考えるとちょっと手が出せない。

そんな中、アナログとデジタルのハイブリッド?というのか、コクヨの CamiApp S を記事を発見した。

CamiApp S(コクヨ)
http://www.kokuyo-st.co.jp/stationery/camiapp-s/index.html

どうやら手書きで入力したものがスマートフォンへ保存といった代物のようだ。
この手の物は、以前から発売されているが、今回はコクヨからといった感じか。

ということで、他のメーカーの同コンセプトの製品を調べてみた。

livescribe
http://www.livescribe.com/ja/
Boogie Board SYNC9.7(KING JIM)
http://www.kingjim.co.jp/sp/boogieboard/bb6.html

airpen pocket++
http://www.airpen.jp/
phree(KICK STARTER より)
http://otmtech.com/

結構ある。
いずれも、専用器具を用いて Bluetooth 等で通信する仕組み。

いずれの製品もレビューを見ると、専用ペンというのがネックのようだ。
どうやらこの分野はまだまだ発展中の様でもう暫くしないと普及しないかもしれない。

購入して開発費に貢献したいところだが、なかなか現実のお財布状況が厳しいため今一歩が踏み出せないのであった。。。

結論としては、今のところは、手書きで必要な情報を清書＋スキャナが良いのかもしれない。

Xcode 7.1.1 で iOS7 のシミュレータを動かす方法

覚書として Xcode7 から、シミュレータの対応する iOS のバージョンが 8.4 以降になったようだ。
実際、iPhone4s iOS7 の組み合わせでシミュレータを実行しようとすると、

The iOS 7.1 simulator runtime is not available. Unable to open liblaunch_sim.dylib. Try reinstalling Xcode or the simulator runtime.

のエラーがでて実行できない。
Apple 自体が古い OS のサポートは切っているので、古い OS に対応したアプリなんか作るなと言うことだろうか。
確かに、古い端末をずっと使われたら商売上がったりだもんね。

とはいえ、世の中そう甘くない。
慣れ親しんだ端末をアップデートせずに使う人もいるわけで、最近では買い替え後の端末を有効利用してやろうと考える人もいる。
だから Apple よもう少し寛容になってくれ。。。
(MS なんて VB6 のサポートまだやってるんだぞ)

さて、本題だが、この状態が発生したが、自分では実機を持っているので最悪シミュレータを使用しなくても良い環境にある。
なので、調査はしたけど試してないので、どうしても必要になったら実行に移そうと思う。
参考にしたのは以下のサイト

Xcode 7 付属のシミュレータに iOS 7.1 シミュレータを登録する
http://qiita.com/msa_uccky/items/f6ed080e5d723d4c0793

How can I run the iOS 7.1 Simulator in Xcode 7.0 beta 2?
http://stackoverflow.com/questions/31056634/how-can-i-run-the-ios-7-1-simulator-in-xcode-7-0-beta-

安定の Qiita と Stackoverflow 凄いサイトだ。
この記事を読むと、エラー文にも有った liblaunch_sim.dylib が古い OS に対応していないので、Xcode7 アプリ内にある iOS7 のファイルを使用するように変更する手順が書かれている。

というかみんなどうやってこういう情報を得るのだろうか。探究心が足らないのだろうか？

最終的には以下の様にすれば良いらしい

1. 現在 /Library/Developer... にある liblaunch_sim.dylib をバックアップ

$ sudo mv "/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 7.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/host/liblaunch_sim.dylib"{,.bak}

2. Xcode アプリ内にある liblaunch_sim.dylib を上記の /Library/Developer... にシンボリックリンクを張る

$ sudo ln -sf "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/system/host/liblaunch_sim.dylib" "/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 7.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/host/liblaunch_sim.dylib"

これで、iOS7 のシミュレータが動くはず。

(Mac)Nokogiri のインストールでエラーが出る

Rails のインストールをしようとした所、エラーが発生してインストールできない状態になった。
よくよくログを見てみると nokogiri のインストールで失敗しているようだ。

---

$ gem install nokogiri
Building native extensions.  This could take a while...
ERROR:  Error installing nokogiri:
    ERROR: Failed to build gem native extension.
    /Users/zeonic/.rbenv/versions/2.2.3/bin/ruby -r ./siteconf20151129-59395-c8vrlu.rb extconf.rb
checking if the C compiler accepts ... yes
checking if the C compiler accepts -Wno-error=unused-command-line-argument-hard-error-in-future... no
Building nokogiri using packaged libraries.
checking for gzdopen() in -lz... yes
checking for iconv... no
-----
libiconv is missing.  Please locate mkmf.log to investigate how it is failing.
-----
*** extconf.rb failed ***
...

---

この場合は、nokogiri を個別にインストールしてから、rails のインストールを行えば良いとの記事を各所で見かけたが、nokogiri の単体インストールがうまくいかない。
ところで、nokogiri とは？
Ruby のスクレイピング(HTMLやXMLの構造を解析して、特定の要素を指定しやすい形に加工する)ライブラリのことらしい。
よく書かれている内容にそって、実行してみたんだけどなぁ。。。と思ったのがエラーは変わらないので、内容を再度咀嚼しながら確認。
結果的に必要なライブラリパスを直接指定する方法でうまく行ったので経過を載せておきます。

1. Homebrew のアップデート
   
$ brew update
$ brew upgrade

   
2. 必要ライブラリ用のリポジトリを取得
   
$ brew tap homebrew/dupes

   
3. ライブラリのインストール
   
$ brew install libxml2 libxslt libiconv

   
4. ライブラリをリンク
   
$ brew link --force libxml2 libxslt libiconv

   
5. nokogiri のインストール
   
$ NOKOGIRI_USE_SYSTEM_LIBRARIES=1 gem install nokogiri --
--use-system-libraries
--with-iconv-dir="$(brew --prefix libiconv)"
--with-xml2-config="$(brew --prefix libxml2)/bin/xml2-config"
--with-xslt-config="$(brew --prefix libxslt)/bin/xslt-config"

   
6. rails のインストール
   
＄ gem install rails

   

ひとまず上手く行ったけど、一発目の環境設定でつまずくと、やる気なくすなぁ。

Written with StackEdit.

uni-ball AIR を買ってみた

先日、Facebook にどなたかが uni-ball AIR の紹介をあげていた。
uni-ball AIR とは、三菱鉛筆が出している水性ボールペンの事。
特徴としては、非常に軽く書くことができ、かつ筆圧によって線幅を変えることが出来るとのこと。

ユニボール エア
http://www.mpuni.co.jp/products/ballpoint_pens/roller/air/cap.html

すばらしい。
是非手にとって見ないとということで、購入してきました。
価格は 200 円。
まあ、高くて手がでないという金額ではないが。。。

まず外観


写真が今一つで申し訳ない。
イメージとしては、万年筆を髣髴とさせる形状としたらしい。
確かに、先端が万年筆のように見えなくはない。

次に、実際に筆記した結果を
 
これまた、字が汚くて申し訳ない。
軽い力でということで、自重でかけるかと思ったが、流石に無理だった。
ということで、線幅を確かめるべく力を入れるが、コントロールが難しい。
このインクの出方が変わる事を利用して、止め払いなどが表現できるとどこかで見たので、永字八方ってことで書いてみたが、自分のような下手くそには表現ができないみたいだ。
ただ、今回買ったのはボール径が 0.5 mm なので、0.7 mm の物を使えば表現ができるかもしれない(最初から2本買えばよかったな。。。)

あと、水性ボールペンなのでどうしても裏写りが発生する。
良い紙なら気にならないかもしれないが、普通の紙に書くと裏抜けがあるので、注意が必要。

というわけで、簡単に触った感想をかいたが、もうちょっと使ってみないと良さが分からないかもしれない。

最後にツッコミを。
ホームページを見ると、使い込むほど書く人になじむペン先とある。
これは、某メーカーのインジェニュイティの時も同じ内容を見た気がする。
あの時も思ったが、インクが切れたらペン先ごと(または本体ごと)交換するから、なじんだ頃にはまた新しいペン先になっているので、こういうのは意味のない特徴と思う。
たぶんメーカーもわかっているのになんで書くのだろう。。。