OSの機能（cmd + x、cmd + v）ではなくIdeaVimのddを使う場合に、移動先にゴミがあったのでxキーで削除して、いざペーストしようとしたら、xキーで削除したゴミが貼り付けられてしまった。「なんでだよムキーっ」とイラッとした経験を持つ人はきっと多いはずです。
そんなことにならないように、xキーで文字削除する際にレジスタを書き換えないようにする設定です。正確に言うと、IdeaVimではなくVimの設定の話ですけどね。
~/.ideavimrcを作成して以下の2行を書くだけ。
nnoremap x "_x vnoremap x "_x 意味としてはノーマルモードとビジュアルモードにおいて、Xキーのキーマッピングを"_xに書き換えるという意味です。
"_とはなんぞやという話ですが、これはブラックホールレジスタという特殊なレジスタを表しています。Xキーのデフォルトの挙動は、1文字デフォルトのレジスタに移動するというものですが、この移動先をブラックホールレジスタに指定してやるという意味になります。
エディタタブがたくさん開かれていくと、編集したい対象を探すのに苦労します。タブを1つずつショートカットキー使って移動していくのもいいのですが、それはそれで現在地を見失いがちで困りモノです。
Android Studioで現在開かれているファイルの一覧を表示したりできないのかなと思ったのですが、そのものズバリな機能は見当たりませんでした。とり得る対策は以下の2つかなと思います。
隠れているタブを表示する Android StudioのメニューのWindow > Editor tabsの中にshow hidden tabsというものがあります。これを選択することで、ウィンドウ中に表示しきれていないタブを表示させることができます。
ちなみに初期設定ではショートカットが割り当てられていないので、私はcmd + shift + Pを割り当ててみました。タブの移動ショートカットの隣にあるので押しやすいかなと思っただけなんですけどね。
ファイル一覧から選択する cmd + oを押すとこのような検索窓が開きます。ここで編集したいクラス名を入力してやると、対象のクラスに移動することができます。
レイアウトXMLをいじりたいといった場合には、検索対象をクラスではなくファイルにしてやると選べます。ショートカットはcmd + shift + oです。ただしファイルにすると、画像ファイルなども引っかかるようになるので、逆に探しにくいかもしれません。
さらにcmd + opt + oではSymbol検索になります。これはメソッド名やフィールド名などで検索を行うことができます。いじりたいメソッド名がはっきりしている場合はこれを使うと楽かもしれません。
Androidのコーディング規約で、非Publicかつ非staticなフィールドは、先頭にmつけるというものがあります。これに従ってコーディングしていくわけですが、そのままだととあることをしようとしたときに困ったことになります。それは、Getter,Setterを自動生成する時です。
ソースコードエディタ上でcmd + nもしくはctrl + enterを入力すると、Generateというポップアップが出てきて、そこでGetterやSetterの生成を行うことができます。
例えば作成しているクラスがmHogeというフィールドを持っていて、Setterを生成するとしましょう。
ここで何も考えずにSetterを作成すると、生成されるメソッド名はsetmHoge()となります。そう、余計なmが一緒についてくるのです。この場合、通常はsetHoge()としたいでしょうから、これでは非常に面倒くさいことになります。
これはAndroid Studioの設定を変えることで対処できます。
cmd + ,でPreferenceを開き、Code Style > Javaを選択、Code Generationのタブを開きます。そしてFieldのName prefixの欄にmを入力してやります。これだけでオッケー。
ついでにコーディング規約でstaticフィールドの先頭にはsをつけるという規約があるので、Static fieldにsも追加しておきます。
これでSetterを生成した際にsetHoge()と解釈してくれるようになります。
Android Studioと銘打っているのに、なぜコーディング規約に従った設定になっていないのか不思議で仕方ありません・・・。
Android Studioで作業していると、エディタのタブがどんどん増えていきます。タブが画面内に収まりきらなくなったらマウスで選択するのが非常に面倒くさくなります。そんなときはキーボードショートカットを利用しましょう。
cmd + ,でPreferencesを開き、キーマップを選択します。そのままだとキーマップ全てが表示されて非常に見づらいので、検索窓にtabと入力してやると、タブ関連のキーマップのみに表示を絞ることができます。
キーマップの表示上はcmd + shift + ]で順送り、cmd + shift + [で逆送りですが、キーボードの配列がJIS配列の場合この通りに動きません。これはAndroid StudioのベースとなっているIntelliJ IDEAのキーマップがUS配列に依存しているからだそうです。（他のキーマップでも同様のことが起こる）
実際にキーマップを変更してみるとわかりますが、[を入力すると]が表示され、]を入力すると\が表示されます。なんとややこしいことか・・・。
JIS配列のキーボードの場合、タブの移動のショートカットはcmd + shift + [が順送りで、cmd + shift + @が逆送りになります。
レイアウトXMLのファイル名、drawableに用意する画像のファイル名、自分で作ったカスタムスタイルの名前などなど。これらの名前の中にハイフンを使うとビルドが通らないことがあります。
ハイフンを使ってもビルドをかけるまでエラーと表示されなかったり、名前にハイフンが入っているせいでレイアウトプレビューがうまく表示されなかったりすることがあります。この原因がファイル名等にハイフンを使っているせいだとはなかなか気づけません。
命名規則には、例えばレイアウトXMLのファイル名に大文字が使えないというのもありますが、これはAndroid Studioがちゃんと指摘してくれるので分かりやすいです。ファイル名なら指摘してくれるのでわかりますが、例えば独自のスタイル名については指摘してくれません。
私は普段ファイル名の区切りにハイフンをよく使うので、エラーだと直接指定されないとついついハイフンを惰性で使ってしまいます。レイアウトのレンダリングプレビューがちゃんと表示されないな、なんでだろう・・・とすごい悩んでいたのですが、原因は使用しているスタイルの名前にハイフンを使っているせいでした。
Android開発で名前をつけるのには、ファイル名にかぎらずスタイル名などでもハイフンは使わないよう気をつけましょう。
Android Studioでコーディングしている時に、何らかのメソッドを叩くと引数の一覧が表示されます。
これが非常に便利なんですが、能動的にこれを出す方法が分かりませんでした。コード補完で入力していると勝手に出てきてくれて便利なんですが、ちょっとカーソルをよそにやると消えてしまう。再度出す方法が分からないので、いちいち今まで入力したものを消してメソッド部分から再入力してました。
すごい便利なのにこれなんなんだろう・・・とモヤモヤしていたのですが、ようやく正体がわかりました。この機能はParameter Infoという機能で、Android Studioの上部メニューのViewの部分から呼び出せます。
ショートカットキーはCmd + pです。これでコーディングがかなり捗ります。
Android StudioにはVimプラグインがあり、これを導入することでVimキーバインドでの入力が可能になります。
私はVim小学1年生くらいのレベルですが、そのレベルでもVimを使わない場合と比べてプログラミングが捗るなと思っています。
インストール方法は簡単で、Android StudioのメニューからPreferencesを開き、Pluginsを選択、IdeaVimというプラグインのインストールボタンを押すだけです。
タグなどの書き換えが簡単 Vimを利用することで便利になったことの1つに、タグなどの書き換えが非常にやりやすくなったことが挙げられます。
例えばandroid:layout_width="match_parent"のmatch_parentをwrap_contentに変更しようと思った時。Vimを使う前の私は、match_parentをマウスで選択肢てバックスペースキーで削除する、もしくはカーソルを最後に持って行ってバックスペースキーを連打して削除していました。
マウスを使う場合は余計なダブルクォートまで選択してしまうこともあり、微妙にイライラしてしまいます。バックスペースキーで削除する場合は、消さなくてよいところまで削除してしまい、Ctrl+zで取り消しをするとまた最初から消し直しになることがしょっちゅうありました。とても効率が悪いです。
Vimを使えば、キャレットをダブルクォートの中のどこかに置いてci"と入力するとmatch_parentが消えて書き換えができるようになります。なんとスムーズなんでしょう！
私がVimを便利だなと実感し始めたのは、この機能を知った頃からです。
慣れるまでは大変かもしれない まったくVimに触ったことのない人だと、慣れるまでが大変かもしれません。私も最初の頃はしょっちゅう間違えておかしなことになっていました。文字を入力しようと思ったら入力できない（挿入モードに入っていない）、カーソルの動かし方がよく分からず、lキーを押して一文字ずつカーソル動かしていたり。慣れるまでVim不便すぎと思ってました。
ただある程度Vimの機能を覚え始めると、その魅力の虜になります。Vimがプログラマーに人気というのも頷けます。「範囲選択？ マウスでやった方が早いじゃないか」とずっと思っていたのですが、いざVimを使ってみると想像以上に快適です。キーボードとマウスを行き来するのがこんなに邪魔だったなんて思いもしませんでした。
Android StudioでVimプラグインを導入すれば、マウスでの操作も併用できます。Vim触ったことないという人は、とりあえずAndroid StudioでVimに触れてみるのもいいのではないでしょうか。
アプリを開発する上で、コーディングを始める前にペーパープロトタイプを作るといろいろなメリットを享受できます。
どんな画面が必要になるか検討できる 作り終わってから使い勝手の悪いところに気づいて、実装をやり直す事態を未然に防げる可能性がある 必要な機能の絞り込みができる 作ろうとしているアプリのイメージがはっきりしてくる などなど デザインに疎いとどうしてもコーディングを優先してしまいがちです。画面設計よりシステムを作っている方が性に合ってますし。ついついデザインを後回しにしてしまいます。
しかしその作り方をすると、アプリ完成したけれど残念な見た目だったり、使い勝手が悪くて使えないアプリになってしまったりしているかもしれません。それを後から直そうとすると、せっかく実装したシステムも作りなおしになる可能性もあります。せっかく作ったコードを、使い勝手が悪いからと泣く泣く切り捨てることになったら、目も当てられません。
POP ありがたいことに、ペーパープロトタイピングを簡単に行うことのできるツールが世の中には存在しています。
POPというアプリを利用すると、紙に書いた画面デザインにいとも簡単に動きをつけることができます。ここを押したらこの画面に移動して・・・なんていうのが簡単に作れて非常に便利です。
Android版のPOP2.0だとジェスチャーを設定する項目があるものの、設定しても動かなかったり、スマホで撮影した画面を削除しようとしたらゾンビのごとく復活してきたりと、使い勝手が微妙なところがあります。私の使ってる端末固有の問題なのかもしれませんけれども・・・。
ただこれがあるだけでも画面の動きのイメージがつきます。この画面遷移は使いづらいとか、こういう画面も用意しないといけないなというのが簡単に分かります。このアプリ、便利なのは間違いありません。
Androidからだけでなく、パソコンのブラウザやiPhoneなどからも使うことができるので、ブラウザで編集してスマホで動作を確認するなんて使い方ができます。
テンプレート 紙にアプリのデザインを書くのに、さり気なくネックなのが画面を描画するところです。画面の外枠です。私はこれが面倒くさくて、画面を紙に書けないでいました。
枠を決めるのが難しいのであれば、最初から用意されているものを利用すればいい。そこで私は、iPhone5のワイヤーフレームに使えるアイデアシートをイラレで作りましたさんで公開されているアイデアシートを利用させていただきました。 現在はリンク切れで見れなくなってますね・・・。
iPhone5向けのテンプレートではありますが、画面の比率はAndroidとそう大差ありません。画面の外枠が決まっているだけでも、やりやすさが段違いです。
どう実装するかはとりあえず考えない とりあえず考えるのは、ボタンをどこに置いて、どの画面に移動するのかだけに絞った方がいいと思います。できるだけシンプルに考えるのが大事です。どうやってコーディングしようかと考えだすと、何も書けなくなってしまいます。
実装方法を考えながらやってしまうと、実装しやすさを優先するあまりに使い勝手が犠牲になるのが悲しいです。とりあえずアイデアシートを印刷して、どしどし書くべしです。書いていればいいアイデアが浮かんだりします。紙に書くだけなのでやり直しも簡単ですしね。
せっかくアプリを作るのであれば、多くの人に使ってもらいたいです。そのためにも、せめて使い勝手がよくなるような努力はしておきたいですよね。
アプリ開発をしていてバカにならないのが、デバッグにかける時間です。頻繁にエミュレータを起動して動作確認を行うわけですが、デフォルトのエミュレータ（Android SDKのエミュレータ）はとにかく起動が遅いです。さらに動作ももっさりしていて、お世辞にも動作確認しやすいとはいえません。
そこで動作確認の時間をできるだけ短縮するためにも、Genymotionを導入しておくことをおすすめします。起動も早く動作もスムーズなので、デフォルトのエミュレータを使うのが馬鹿らしくなります。
私の環境で実際に両者を比較した動画を撮ってみました。
Genymotionをインストールする Genymotionを利用するためには、ユーザー登録が必要になります。
また、エミュレータを動かすために別途Virtual Boxが必要になります。
端末を登録する Genymotionをインストールできたら、端末の登録を行いましょう。Genymotionは実在する端末のエミュレーションを行うものなので、よく使う端末をとりあえず登録しておけばいいと思います。
サポートするAndroidのバージョンに合わせて登録しておくといいでしょう。私はとりあえず、Android2.3の端末と、自分の持っているGaraxy S3を登録しています。
端末の追加はそんなに難しくありません。予め用意されている端末から、エミュレーターとして使いたいものを選択するだけです。
Android Studioでプラグインを導入する Android StudioからGenymotionのエミュレータを起動するためにも、Genymotionのプラグインも一緒にいれましょう。別に入れなくても使用に問題はありませんが、入れておいたほうがエミュレータの起動が捗ります。
こんな感じでAndroid Studioから起動しやすくなります。
インストールの仕方はAndroid StudioのPreference > PluginsからGenymotionを探してインストールするだけです。そうすることでAndroid Studioの右上にGenymotion用のアイコンが追加されます。
万能ではないものの使わないのは損 Genymotionではデフォルトのエミュレータと比較して、画面サイズやAndroidのバージョン、SDカードの有無など細かなところまでカスタマイズすることができません。特にFreeライセンスでは利用できる機能に制限があるため、Android SDKのエミュレータを完全に置き換えるものではありません。
ですが基本的なデバッグ・動作確認にGenymotionを利用することで、アプリ開発における動作確認の時間を短縮することができると思います。基本的にはGenymotionを使うようにすれば、開発がだいぶ捗るのではないでしょうか？
確認方法 手順としては、ProGuardを適用していないapkファイルと、適用したapkファイルの2つを用意しました。そしてリバースエンジニアリングを行い、apkファイルからソースコードの抽出を行い確認を行いました。
ProGuard適用前 こちらがProGuard適用前のソースコードです。ほぼ自分で作ったソースコードのままで、Android Studioで作り上げたソースコードと大差ありません。
ProGuard適用後 こちらはProGuardを適用した後のソースコードです。一部の変数名やクラス名、メソッドなどがa,bといった意味のない文字列に置き換えられています。
全てが書き換わっているわけではなく、forやifなどの命令文はそのままですし、解読しようとしてできないレベルではありません。
ProGuardのお仕事 私は難読化というからには、もっと複雑な変換が行われているのだとばかり思っていましたが、意外にシンプルな難読化でした。確かに読みづらくはなっていますが、解析しようと思えばやってできないレベルではありません。
変数名やメソッド名等は、一部意味のない文字列に置き換えられているものの、処理の流れなどはそのままであるため、アルゴリズムの解析は比較的しやすそうです。
よく考えてみれば、解析不可能なほどに難読化が行われると、今度はプログラムとして動作しなくなるので本末転倒になってしまうのでしょう。そのためProGuardによる難読化は、変換をしてもプログラムの動作に影響のない範囲で難読化が行われているようです。
注意点 まずはProGuardによる難読化はあくまで気休めレベルであるということを認識しなければなりません。私も実際にこうやって中身を確認するまでは、ProGuardを適用していればソースコードの盗用などは防げるものだとばかり思っていました。
またソースコードの書き換えが行われるため、以下の様なことに注意が必要です。
別途動作確認が必要 ProGuardはメソッド名やクラス名を書き換えてしまうため、プログラムによってはProGuardを適用することにより誤動作を起こす可能性があります。
私はまだそのようなプログラムを作ったことはありませんが、クラス名やメソッド名を文字列等を使って参照するようなプログラムは動作しなくなるでしょう。そのため、ProGuardを適用したapkファイルを用いた動作確認を別途行う必要があります。これはちょっと面倒臭いですね・・・。
文字列リテラルの中身は変換されない ProGuardは文字列リテラルの中身の変換は行いません。ここを変換すると、プログラム実行時に表示される内容や動作に影響が出てしまうからです。ここは逆に変換されないということに注意が必要です。
これは、例えばソースコード中にパスワードを記述してしまうと、そのまま見えてしまうということです。まぁ、そもそもソースコード中にパスワードを平文で書くこと自体が悪手ですけれども。
難読化以外の効果 ここまで難読化について書いてきましたが、ProGuardは難読化と一緒にソースコードの最適化も行っています。
例えばapkファイルの軽量化です。これは変数名等を短い文字列に変換することも寄与しているでしょう。今回使ったapkファイルであれば、ProGuardを適用することにより、適用していないapkファイルと比較して、ファイルサイズが600kb削減されていました。
その他にも処理の最適化を行ったりするようで、基本的にはProGuardを適用した方がいいのだと思います。ただ、難読化のために適用するという観点では「適用したほうがマシだ」というレベルであって、完全なものではないということを念頭に置いたほうがいいでしょう。
むしろ余計なデバッグの手間をかけるくらいなら、最初からProGuardを使わないという選択肢もありなのかもしれません。
