ダメなアプリを作るための10の優れたルール　パート1：技術編

2016/08/25

ダメアプリのための10のルール　パート1：技術編
素晴らしいアプリのアイデアが浮かんで、フィードバックを集めて、なんとかチームすらも作って、app storeを席巻するために全力を注ぐ・・・というのは誰でも経験があるだろう。で、君が最高にイケてると思ってるエッグタイマーアプリの開発に取り掛かる1秒前に、君がこれから何をしようとしているのか、少し考えてみる価値はあると思う。

Chet Haase氏のすごく面白い投稿、「ダメAPIのための10のルール」を受けて、僕はダメアプリを作る方法についてのリストをまとめてみることにした。でも、いくつか最初に断っておきたいことがある：

世の中にはダメアプリがごまんとあって、それぞれダメなところがあるので10個にまとめるのは本当に難しい。最悪のパターンをまとめられるように最善を尽くしたけれど、ここに書いたよりはるかにダメなアプリを君たちが作り続けてくれると信じている。
アプリを作成する上で素晴らしい点は、製品のあらゆる面で間違った方向に行くことができるのと、それによって各チームメンバーが君のアプリを台無しにする可能性をもたらしてくれることだ。だから僕はこのブログを技術面、UI/UX、製品という3つに分けた。
良いアプリでも悪いところの1個や2個は持ち合わせているものだし、完全に良いか悪いかというわけではない。
これらの悪い習慣は、現時点での悪い習慣だ。なぜなら、Googleはすでに、習慣をいつでも変えられると証明しているからだ（例えばボトムナビゲーションが今来てるって？なんてこった！）。
アプリの良し悪しについて、僕なんかが言えた義理じゃない。だってここに書いてあることをほとんどやってきた挙句、それがいかにダメだと分かったんだから。
リストは優先順位別に分かれているわけではない。なぜなら君のアプリをストアリストから葬り去ったものが何だったかを比べるのは難しいから。
僕はChet Haase氏じゃないので、彼のブログ記事の半分も面白くないし為にもならないけど、ごめん。

よし、もう十分かな。リストを始めよう。

1.可能な限りの許可を求めよう

君のアプリに値打ちがあることは君がよく知っているから、ユーザプライバシーみたいな小さなことにまごついていてはだめだ。ユーザはシステム起動時に送信する重大な分析を切に求めているんだから、BOOT_COMPLETEDの権限を求めよう！もし君がこの素晴らしいURLを友達にシェアする必要があるなら、そいつの携帯からコンタクトリストを引っ張り出して君のサーバに送って、そいつら全員にスパムを送っちゃおう！データは権力で、他人のデータは金だということをお忘れなく！

ボーナスポイント：Android Mの権限を実装するときは、君の許可を得るまでユーザには何もさせちゃいけない。たとえいくつか承諾してくれていたとしても、負けちゃだめだ。

2.ロード中はUIスレッドをロックしよう

なあ、今ロード中なんだ。くだらないUIイベントで僕たちを邪魔したりしないで、ロードに集中させてくれると本当に幸いだ。おとなしく座って3.4Mのconfig.xmlファイルの処理が全部終わるのを待ってろ！分かったか！？

0-5OQPKeNGS2fEcaCV-

3.永遠に再試行しよう

ええ、僕らはまだconfigファイルを待ってますが、こんな接続環境のくそ悪い地域に住んでるのはお宅のせいですよ。データプランとバッテリーを食うのを僕らのせいにしないでくれます！？

4.Activity や Fragment の状態を保存するな

ぼんやりしてると痛い目見るぜ。画面を回転させただろ？ブーン…あなたのフォームは失われました。これはアプリから絶対に離れちゃだめだとユーザに分からせるには、もってこいのやり方だ。単に電話がかかってきただけの時でさえも。

5.AlarmManager に setExact と RTC_WAKEUP を使おう

AlarmManagerは未来のある時点でコードを実行させることができる、Android のGet ツールだ。どういうことかというと、まずタイミングがすべてだということと、次にAlarmManagerには選択肢がいくつかあって、携帯の状況、バッテリー、ネットワークやその他ピギーバックできるタスクに応じてコードを賢く走らせたり、リスケしたりすることができる。でもおそらく君にはこんなにしゃれた機能なんていらないかな。「アプリをアップデートしてください」っていう通知が朝の6時に起こしてくれるに越したことはないからね。

ボーナスポイント：全ユーザ向けにsetExactとRTC_WAKEUPを同時に組み合わせれば、サーバへのネットワーク要求で君のロードバランサをギリギリまで追い込むことができるぜ。

6.アプリケーションコンテクストをところかまわず使おう

だってやらない理由がないでしょ？アプリケーションコンテクストをonStartのアプリケーションクラス内に静的メンバーとして保存して、それをところかまわず使うんだ。超簡単、超単純、超モジュラーっぽくない。テーマエラーをデバッグしたいときに最悪にしてくれるし、テストを悪夢にしてくれる。まさにWin-Winだね！

7.エラーはできる限り専門用語にしよう

そうすれば、ユーザ側で何か不具合があったときにすごくラクになる。だからユーザは君にメッセージを送ってくるだろうね。あと、そうすることで君のアプリが開発者に優しいものにもなるね。だから、僕みたいな人にとっては、https接続への証明書がなくて、そのせいでアプリが写真をシェアするときに機能停止したままなんだな～っていうことが容易に理解できる。

8.自分で全部実装しよう

サードパーティのライブラリ用スペースをほとんど残してくれないサポートライブラリとGoogle Playをインポートしてからというもの、Androidには65kという非常に厳しいメソッド制限がある。とにかく、Jsonのパースを扱うのはどのくらい難しいんだ？Gsonライブラリはいらない。若手の開発者にとっても、就職面接でへたくそな文字列照合の実装を練習する素晴らしい機会になる

9.時期尚早な最適化

よかった、ソートを自分で実装したんだろ？おそらく、バケットソートで…｡だって均等に分散されるデータを君は知ってるから。多分そう思ってるね…。Romain Guy氏とChet Haase氏（また彼？）のトークも見て、全てのenum型を定数int型に切り替えて、オブジェクトをところかまわず引っ張り出すのに使う。たとえそれが一時的な機能だったとしても。だって何が起こるかやってみなきゃわかんないもん。

よく言うでしょ、早まった最適化は全ての悪の根源だが、ある偉大な女性はこうとも言った。「善と悪なんてない。あるのは権力と、それを探し求められない弱い者だけだ」。だから、こうしたグラフアルゴリズムの実装の際はN（変数）の威力を知ってほしいと思う。

0-ex5-vbW5KkfT_bYt-