Meblog

このブログ記事は個人の見解であり、所属する組織の公式見解ではありません

AndroidアプリからiOSアプリに移る君たちへ

前座

とある担当アプリがバージョンアップすることになった。自分はAndroid専門なんだけど、上司がやってきて、
Androidアプリの設計がわかるなら、iPhoneアプリもわかるよね^^ じゃあ、次から担当ね!」
なんていうふうに言われ、まんまとiOSの担当になってしまった。

そんな同じような境遇に置かれた悲しき君たちへ贈る。

前提

今回はスクラッチではなく、バージョンアップ。
なので、過去の遺産がある。あるんだけど、残念ながらObjective-c。慣れてくれば悪い言語じゃないが、今更モチベーションの上がらない言語ではある。

Object-c自体は学生時代に少しいじった記憶があるんだけど、もうさすがに忘却してしまっている。まあ、それでも、OS-Xもいじったことのない周りの方々よりも幾分かマシなスタートが切れそう、っていう目論見もあったんだろう。

AndroidからiOS

せっかくAndroidの心得があるんだから、ある程度はショートカットしたい..
さすがに今から「はじめてのiPhoneアプリ」みたいなのをやる気はない、というより、間に合わない。

写経

とはいえ、やはり感覚をつかむための「何か」がほしい。
この目的でApple公式資料を用いて写経した。ところが最近はSwiftに移行し、Appleのドキュメントもそちらよりになってしまっている。そのため、少し古めの資料を使うしかなかった。土日を使って写経したが、やはり資料が古いところもあり、結構時間がかかった。それゆえ、全て写経はできなかったが、それでもかなり役に立ったと思う。特にX-Codeの使い方とか。
http:// https://developer.apple.com/jp/documentation/SecondiOSAppTutorial.pdf

JavaObjective-c

JavaからObjective-cに入るQiitaが何件かあった。正確なところはわからんのだけど、ノリを理解するには十分。こういうのが欲しかったんですよ。
visible true: Java脳でもわかるObjective-C入門
qiita.com

Reactive Cocoa

こうして、X-codeとObjectve-Cのノリをなんとか掴んだのだが、なんと要所要所にReactiveCocoaが使われている。これがなかなか理解を妨げる。
確かに非同期通信するには相当便利なんだけど、Objective-cがままならない時期のReacitiveCocoaは相当きついものがあった。参考資料以外にも色々読んだが、かなり参照したのが以下に示したもの。
qiita.com

以下の記事は公式の翻訳。うまく翻訳されている。
qiita.com

以下が公式のドキュメント。もうObjective-cはLegacyフォルダに入ってしまっている。
github.com

X-code

あと、おまけでX-Codeのショートカット集。X-codeって通常備えておくべき機能が微妙に隠されてたりして、わかりにくいんよね..インデントとかさあ..そのあたりを解決した。
Xcodeでショートカット覚えてないと効率低すぎ | iii ThreeTreesLight

おわりに

で、このプロジェクトはなんとか終焉を迎えた。ReactiveCocoaがReactiveなプログラミングでほとんどはじめてだったので、いい経験だった。Javaだと、こうは書けないよねっていう。
AndroidでもRxJavaが使われていたんだけど、通信部分は違うライブラリが使われてたりして、あんまり運用されていない様子だった。ボタンも全部インタフェースだったし。一方でiOSはボタンのイベントや通信部分まで至るところにReactiveCocoaが使われていた。ふうむ、親和性が高いのかねえ。

今回は、Androidアプリの対応をし、iOSアプリの対応をこの順で行った。上司はAndroidユーザなので、iOSアプリには興味を示さなかったというオチ..


VSS RSS PSS USS の説明

android - Is this explanation about VSS/RSS/PSS/USS accurately? - Stack Overflow
StackOverFlowより

Androidのメモリ消費量を調査したいとき、毎回困るのが、このvss,rss,pss,ussの概念だ。Linuxにおいては一般的な概念らしいんだけど、Linux開発なんて通らずにAndroid開発にいったものだから、この概念については全くの門外漢だった。

メモリ調査

メモリ調査に関して、軽く触れておく。

どれを使えばいいんだ..

一般的な調査だとMAT(Eclipseに付属のもの)なんかを使ってみたり、adbで見てみたりすると思う。でも、これがメモリ消費量だ!みたいなものが出てこない。だいたいのものがpssを出力してくれるんだけど、pssって一体何なんだってのがよくわからないまま進めるのは危険な気がしてくる。

VSS RSS PSS USS の説明

で、掲題の話題。
PSSが何なのか、を知るためには結局他のRSSやUSSなどの算出方法を知っておく必要がある。件の記事では、それを非常にうまく説明してくれていた。

以下に訳をおいておく。

    • -

Androidのprocrankと呼ばれるツールがある。これはLinuxのプロセスのメモリ使用量を多いものから順に出力してくれる。メモリ使用量はVSS, RSS, PSS, USSの値をプロセス毎ごとに出力する。

ここでは簡単のために、Byteではなく、「ページ」という単位を使うことにする。LowレベルのLinuxのシステムでは4096Byteを単位とするページがよく用いられる。

VSS(psコマンドではVSZと表現される)はプロセスがアクセスできるアドレスの総和である。このサイズはプロセスがまだ使用していない領域もふくむ。例えばmallocされて割り当てられたものの、まだ書き込まれていないようなメモリだ。したがって、VSSはプロセスの実メモリの使用量としては、あまり使われることはない。

RSSはプロセスが実際に使用しているRAMの総メモリ量である。RSSは誤解を招くことがある。RSSはプロセスが使用しているものと、共有ライブラリが使用しているものを合計し算出するからだ。共有ライブラリは、それを使用するプロセス数とは関係なく、一度しか読み込まれないのにもかかわらず、だ。RSSはある単一のプロセスのメモリ使用量としては正しい表現とはいえないだろう。

PSSは共有ライブラリを適切なサイズに分割し算出する点がRSSと異なっている。例えば、3つのプロセスがある30ページのメモリをもつ共有ライブラリを用いている場合、各プロセスのPSSには、10ページの使用量として計算される。PSSはとても扱いやすい数値だ。システム中の全てのプロセスのPSSを足しあわせた場合、それは実際のシステム中のメモリ使用量に相当するからだ。あるプロセスをキルした場合、各PSSに当分して計算されている共有ライブラリは、依然としてライブラリを用いている他の残っているプロセスの等分に分配される。この場合、PSSはわずかに誤解をまねく。プロセスをキルした場合にシステムに戻るメモリ量としてはPSSは正しい指標ではなくなってしまうからだ。

USSはプロセスに完全に一意であるようなプライベートなメモリ使用量である。USSは動作中のプロセスが使っている真のコストを表しているため、かなり使いやすい数値である。プロセスがキルされた場合、USSで表されたメモリ量はシステムに還元される。そのため、USSはプロセスのメモリリークを疑った場合に最初に見る値としては最も使いやすい。

風立ちぬ

風立ちぬ」が好きで何度か鑑賞している。

色々なところで色々な風に言われている「風立ちぬ」だが、僕がこの作品を好きな理由は、堀越二郎のエンジニアとしての美しさだ。

    • -

この作品は宮﨑駿が引退すると宣言したものであってか、公開前から相当盛り上がっていた記憶がある。特に、試写中に宮﨑駿氏が涙ぐむ場面もあり、感動作という印象もあるのだけど、涙もろい僕だが特に感涙はしなかった。

僕がこの映画を好きなのは、儚い結核文学であるからではなく、メロウなラブストーリーであるからでもない。単にものづくりに携わっている人がもつクリエイティビティへの畏敬の念が、この作品にはこもっているからだと思う。

    • -

要するに作中の堀越二郎に自分を重ね合わせているんだと思う(非常に恥ずかしい話だが!)。
モノを作っていくエンジニアリングってのは、クリエイティビティを伴う行為だ。彼はエンジニアとしてのクリエイティビティを具現化した存在だ。それゆえ、二郎は”呪われた夢”である美しい飛行機を夢見て、あまつさえ作ろうと奮闘している。

「エンジニア」というと、どうも泥臭いイメージがつきまとう職業なのだけど、実のところ、技術的な視点に立脚し、意見を出さないといけない場面も往々にしてある。自分としては、この想像的な面こそエンジニアの本質であると考えている。二郎の存在は、エンジニアの泥臭い面を隠蔽し、創造的な面のみを押し出した存在としても見ることができる。

自分もエンジニアの端くれとしていくばくか創造的な仕事を求められることがある。しかし、それは泥臭い面を持ったエンジニアだ。理想的であるとは言いがたい。

この映画を見ると、ある意味で最高潮を迎えようとしている航空技術に、創造力で打ち克とうとする二郎の姿から、やはり純粋なエンジニアはかくあるべき、という理想像を夢見ることができるのだ。

    • -

ところで、興味深いのは、同僚である本庄の言葉だ。
現在の日本は技術立国とも揶揄され、技術力の高さでは世界を席巻しているとも言われている。しかし、個人的には、その技術には国際的な競争力が欠けているように思う。流れの早い分野では依然として世界についていけていないセンスや技術があるように思う。

特にソフトウェアの分野では、日本の実情に合わせたガラパゴス化が顕著である、と肌感覚であるが、思うことがある。本庄の作中の言葉で引用すると次のような感じか。

俺達がExcelで管理しているバグを、やつらはAsanaで管理している。
俺達は10年は遅れているんだ。

恐るべき後進性だよ。

Androidアプリにおけるプライバシー

App privacy controls still missing from Android 5 / Lollipop There is a lot of…

Androidアプリをダウンロードするとき、必ずその権限についてきかれる。

実装としてはAndroidManifest.xmlにuses-permissionでアプリに権限を与えているんだけど、この内容の確認はGoogle Playからダウンロードするときのポップアップによって行われる。ユーザに注意喚起するためだ。セキュリティ上のリスク回避手段だと考えられる。

しかし、これには色々まずい問題を含んでいる。

まず、UI上の問題が挙げられる。ユーザによるポップアップの内容の無視だ。これはどのアプリで言われていることだが、どんな重大な警告であろうと、あまりに何回も出るとユーザは慣れてしまうのだ。とりあえずどんな問に対しても'はい'を押してしまうように学習し、内容を熟読しなくなる。

件のポップアップは毎ダウンロード時に出現する。これではユーザはいちいちポップアップを確認はしないだろう。

2つ目には、警告を理解しても、取るべき手段が非常に限られているということだ。使用したいアプリであっても、セキュリティ上の問題があれば、全機能がつかえなくなってしまう。これは上記記事でも触れられている。

インストールしたアプリの全ての機能が動くわけではないが、自分でリスクを細かくコントロールするか、現在の「全てを受け入れ、インストールする」か「インストールしない」の完全なクロとシロの選択肢しかないか。

例えば、電話帳アプリがあったとしよう。素晴らしいUI・UXを持ち、検索機能もシンプルで使いやすい。デザインもクールで申し分ない。ただ、クラウドに自動同期してしまう。そして、この機能が好ましくなかったとする。これはもちろん、この機能自体をoffにすることはできるだろう。しかし、ポップアップの’はい’をクリックし、ダウンロードすると、クラウドとの同期がはじまってしまう可能性がある。一部の好ましくないと思っている機能のために、ダウンロード自体を諦めなければならないのだ。

アプリのパーミッションの粒度を(多少煩雑になるのは覚悟の上)細かくすれば、これはすこしマシになると考えるかもしれない。しかし、警告だけではどんなリスクをはらんでいるのか十分に予想できない問題は残る。事前にリスクの具体的内容がわからないのだ。電話帳の例だと、「電話帳へのアクセス」と「インターネットへの接続」権限が求められた場合、これがクラウドとの同期のことを指しているのか、アプリベンダーのサーバーに送信することを指すのか、はたまた勝手に全世界の人間の連絡先がダウンロードされるのか、見当がつかない。

やはり使用の際に、どのようなアクセスがなされているかを知り、コントロールすることが必要に思われる。

これに対し、googleは「App Ops*1なるツールをかつてAndroidプリインの機能として提供していた。この機能はアプリごとに権限をコントロールできるツールだ。しかし、現在このアプリは提供されておらず、Android5.0の現在も復活の兆しがない。

どうもGoogleはこういったプライバシーの問題にあまり積極的でないように思える。おそらく彼らのビジネスモデルがまさに「個人プライバシーを売る」行為だからなのだろう。Gmailの内容だって実はコンピュータによって解析がされている*2

我々のプライバシーを売ることにより、たくさんの金をかせげる方法がある。それこそが、あなたのプライバシーを侵すアプリ開発者のビジネスモデルだ。

昔のブログ

ふと昔のブログを見返してみた。なんとなくで目的はないんだけど。

ひとつのサービスに長く居座ることがなくて、昔っから自分に合うスタイルの日記サービスを見つけられずに転々としていたみたいだ。

最初にBlog始めたのは2006年で、そのときは忍者ブログ使ってた。久々に自分の文章見てみたら、ひどいのなんのって。文章が破綻してた。まあ、それぐらいの気合の入れ具合で書いてたのかな。当時高校生だったのかなあ。

そんで、次mixiだった。2008年3月が最初の記事だ。ちょうど全盛期だったので、面白かったけど、この時の文章もひどいもんだ。この頃独特の青臭いというか、厨ニっぽい文章で見てられない。黒歴史ってほどでもないけど。2012年2月が最後の記事みたいだ。

この後、再び忍者ブログにもどって、2012年9月まで記事を書いてる(といっても月に一個書くかどうかだけど)。

こうやって、自分の日記をあとから眺めてみるのもいいもんだ。僕はWeb上に公開してはいるものの、ブログをやっているほとんどの理由を、そのとき考えていることをダンプすることにおいている。Webに公開するのは、緊張感というか、推敲する必要性を求めているわけで。

    • -

その後空白期間を置いてはじめたのが、Tumblrだった。
2013年1月30日が最初の記事で、2013年11月が最後の記事だ。10ヶ月しか続かなかったのか。

結構おもしろげなサービスで、現行のSNSの中では昨今もっともユーザ数を伸ばしているもののひとつらしい。ただ、海外のサービスらしく、なかなかUIが使いにくい印象だ。ブログでいつも苦労するのが、URLの貼り付けと画像貼り付けなんだけど、どちらもなんとなく使いづらかった。特にURLなんてのは、記事のテーブルを無視して横に長く貼りつくもんだから、なかなかたまったもんじゃなかった。

さらにデザインテーマのカスタマイズも難しく、結局放棄してしまった。ただ、やはりユーザ数を伸ばしているだけあって、独特のサービスの展開は魅力的である。今でもUXが改善されたら戻りたいとおもっているSNSだ。

決してはてながダメといってるのではないけどね。やっぱり今後伸びそうなwebサービスってのは使ってみたくなるもんだと思うし、あの類のサービスは長く使ってみないと、なかなかわからないことが多いように思う。

物欲関係

社会人になって2年目だが、あんまりモノを買わなくなったというか、物欲自体が若干失せた気がする。もともと欲はないほうだけど。

それでもちょくちょく欲しいものはあったんだ..

タクティクス・オウガ

PSP版のやつ
タクティクスオウガ 運命の輪 | SQUARE ENIX

発売当時からほしかったんだけど、正直SFC版の焼き直しだし、わざわざPSPまで買うほども食指が延びなかった。で、久々にゲームやりたいな、と思って、最近になってPSPを手に入れた。

PSPが中古で約6000円で手に入って、タクティクスオウガが数百円。送料がほとんどだねえ。さすがに値が下がってた。

まだ序盤だと思うんだけど、これ、やっぱり難しい。SFC版は鬼のように難しかった記憶がある。明らかな難度調整として、

  • 味方は3度まで死ねる(SFC版は一度死んだキャラクタは二度と生き返らなかった)
  • 操作履歴が50手まで遡れる

この2点がある。後者のほうなんて、タクティクスゲームにしては、禁じ手だとおもうんだけど、さかのぼったとしても依然難しいんだ。簡単にキャラが死んでいく..

LOUNGE LOVER

長岡亮介氏(ペトロールズ)のソロ・アルバム。

ペトロールズは好きで何度も足を運んでいるんだけど、ソロも良さげね。

それで、初のソロ・アルバムなんだけど、全然情報をフォローできてなかった。長岡さんのツイートをたまたま見て、そのまま渋谷のタワレコまで行って買ってきた。全然情報なかったけど、3曲入りなのね。

01 DAZEDS
02 LOUNGE LOVER
03 LOWDEN

なんとなくインストルメンタルなかんじ。ところで、この3曲めって、SoundCloundにあがってるやつじゃ...

1曲損した気分になってしまった。なんか全体的にオマケ感ただよう作品なんだなあ。バックグラウンドについては何も知らないんだけど、遊びでつくったかんじ。それはそれでいいんだけどね。

AndroidのメーラアプリにGmailを設定する

Android端末のメーラにGoogleimapを設定したところ、つまった話。

http://www.flickr.com/photos/75259057@N00/221051486
photo by rovlls

イントロ

Androidの中にGmailアプリはプリインされているし、端末に紐付けられているアカウント使えば、特に設定せずに使えてしまうGmail。なんとなくサードパーティ製のアプリを試したくなって、適当なメールクライアント(K9とNX!メール)を落としてきて使ってみた。ところが、簡単には設定できず、なんかはまってしまった。

1.imapサーバ設定

imapってのは、メールを受け取ってくれるサーバ側のプログラムのことだ。スマホやPC側(クライアント側という)はimapに問い合わせてメールを受信(サーバからダウンロード)するのだ。

たぶんGmailimapは初期設定だと有効になっているんだけど、一応ちゃんと確認しておく。

IMAPを有効にするには、Gmailのブラウザ版サイトにアクセスする。PCのブラウザでGmailにログイン、もしくはスマホでデスクトップのレイアウトでログインする(モバイル版のGmailだと、ブラウザから使いに行っても全ての設定が使えるわけでないようだ)。ここで設定よりimapが有効であるかどうかを確認する。

  1. 右上の歯車アイコンから設定を選択
  1. 「メール転送とPOP/IMAP」タブを選択
  1. IMAP」アクセスから「IMAPを有効にする」を選択

これでとりあえずIMAPは有効になる。ここで一度Androidアプリで設定を試みるが、なぜか弾かれてしまう。うーむ

2.セキュリティ設定を確認する

ここから「安全性の低いアプリ」からのアクセスを許可する
https://www.google.com/settings/security

ここから「アカウント権限」カードの「安全性の低いアプリのアクセス」を設定し、「許可」する。
※もちろん、セキュリティが脆弱になる可能性があるので、注意して設定すること。

シメ

これで試すと、とりあえずアプリにGmailを設定することができた。いろいろ調べると、Outlookのトラブルシューティングなんかにも同じ事が書いてあったので、おそらくほとんどのメーラがここで弾かれてしまうんじゃないかと思う。

困ったときの参考に。