Floobitsというのはリアルタイムコラボレーションを実現するためのサービス。 VSCodeのVisual Studio Live Shareみたいなやつで、リモート経由でのペアプログラミングとかを実現するためのサービスである。

リモート経由でペアプロしたいが、Android開発でそんなことできるのかというのが出発点だった。 Android StudioのベースとなっているIntelliJ IDEAでもそういう機能があるのか調べたところ、今の所ないというのが結論。 要望自体ははるか昔からあるみたいだが、実現するにはコラボレーション用のサーバ用意したりとハードルがあまりに高いだろうことは想像に難くない。 公式には用意されていないが、見つけたのがこのFloobitsというサービスである。

別にIntelliJに限らず、他のプラットフォームでもプラグインが用意されている。 https://floobits.com/help/plugins Emacs, Sublime Texxt, Neovim, IntelliJ, Atomと多数のエディタに対応している。 Free planであれば5つのWorkSpaceを持てる。 Android Stuioでいえば1つのプロジェクト＝WorkSpaceになるだろう。 Free planではprivateなWorkSpaceを持つことはできないので、ソースコードは誰でも見れる状態になる。 Edit権限を与えなければ勝手に編集されることはない。 ちなみにWorkSpaceはActive Workspaceで確認できる。

どんな感じなのか気になったので、パソコン2台使ってとりあえず試してみた。 試した環境が同一LAN内にあるPCではあったことが関係している可能性はあるけれど、遅延はほぼないと思っていいだろう。

Summonなる機能があって、これを使えば他のコラボレーターを自分が編集しているファイルに瞬時に招集することが可能。 「このファイルがさー」「どれだよ？」 なんてときに活躍しそう。 とりあえず試したのはコード編集だけではあるが、他にもチャットができたりコラボレーションのための便利な機能が盛り込まれている。

ただ、ペアプロに便利とはいうものの、Floobitsはあくまでリアルタイムでのペアプロ目的に使うにとどめた方がいいだろう。 Floobitsにアップロードしたプロジェクトを、Floobitsに接続しない状態で更新→FloobitsのWorkSpaceに接続という流れになると、リモートのファイルを上書きするか、リモートのファイルでローカルを上書きするかの2択になってしまう。 Gitでバージョン管理していても、FloobitsのWorkSpace自体はGitで管理されているわけではないので、下手するとGitの履歴自体が上書きされてなかったことにされる恐れもありそう。 プロジェクトはGitで別途管理して、サブ的にFloobitsを使うという感じがいいのかもしれない。 ゼロからいきなりFloobitsのWorkSpaceにジョインして開発を進めるとおかしなことになりそう。

gitと併用してFloobitsを使う場合のFAQがあった。 https://floobits.com/help/faq 運用でカバーする必要があるっぽい。

リモート経由でペアプロするのには非常に便利だと思う。 またFloobitsはAndroidに限らず使えるというのは便利な点だろう。 セキュリティ的にどうなんだというところがクリアできるなら、普通に便利な気がする。

いつもOverwrite local/Overwrite remoteが、どっちがどっちなんだっけと使うときに混乱するのでメモ。

どっちがどっち、というのはovwerwrite localが、現在の設定をリモートリポジトリの設定で上書きするのか、現在の設定でリモートの設定を上書きするのか混乱してしまうのである。 Overwrite localは現在の設定をリモートの設定で上書きする、が結論なんだけど。 これがわかりにくいと思うのは私の英語力がないせいなのだろうか。

Settings repositoryの設定について

ちなみにSettings Repositoryをご存じない方向けに簡単に紹介。

IntelliJ IDEAで使える設定共有用のプラグイン。 私の場合で言うと、Android Studio（stable/canary）とIntelliJ IDEA community editionを行ったり来たりすることがあるので、このプラグインを使って設定を共有している。 バージョンアップする際に以前の設定を引き継ぐというのはできるが、同時に運用しているときにAで行った設定変更をBでもまたやらないといけない、というのが起こらなくなるので非常に便利だと思う。

利用しているプラグインによっては、そのプラグインの設定ファイルもバックアップ対象になるらしい。 例えば私はIdeaVimを利用しているが、どのファイルのどの位置にカーソルが移動した、という情報までバックアップ対象になってしまっている。 そのため必要に応じて不要な設定ファイルは.gitignoreで管理対象から外すなど工夫が必要。 （私はvim_settings.xmlは管理対象から外している）

MacであればFileメニューのところにSettings Repositoryがあるので、GitHubなりBitbucketなりで管理用リポジトリを用意してそのURLを設定すれば使えるようになる。

ちなみにどうもエディタでタブを使わないとか、キーマップの設定でどれを使うかなどまでは合わせてくれないようだ。 例えば私の使っているキーマップはMac OS X 10.5+ copyとなっているのだが、このキーマップ設定自体は共有してくれるものの、これが有効な状態にまでは復元してくれない。 そのため、どのキーマップを使うか、コードスタイルはどれを使うかなどは手動で直さないといけないようだ。

DroidKaigi2017の会場には行かなかったけれども、参加した人や公開されたスライドなんかは一通りチェックしている。そんな中でこちらのスライドでSave Actionsなるプラグインを知る。

少し幸せになる技術

Android Studioで保存時にフォーマットを自動で揃える

Save Actions – JetBrains Plugin Repository

Save Actions – GitHub

Android Studioでビルドしたりファイルの保存が行われた際に、自動的にoptimize importやreformat codeを実行してくれるプラグインである。

ファイルの保存時にrefomart codeを実行する方法として、cmd+sにマクロを割り当てて行うという方法は以前から知っていたのだが、私は導入していなかった。というのも、私はAndroid Studioを使っていてただの一度も自分からファイルの保存を行ったことがないからである。そもそもcmd+Sを押す習慣がなかったのだ。それだったら気がついたときにalt+cmd+lでreformat codeを実行するのと大差ないなと思って導入しなかった。なのでreformat codeを実行することもよく忘れていた。（droidkaigi2017のリポジトリにフォーマットしてないコードをプッシュしたりしていた、申し訳なかった）

しかしこのSave Actionsプラグインに出会えたことで、今後そんなミスは起こさないだろう。

このSave Actionsは、Android StudioのPreference > Pluginsからは検索することができない。作者の方がAndroid Studioによる動作確認が取れていないのがその理由らしい。

導入するにあたっては、JetBrainsのPlugin Repositoryからzipファイルをダウンロードしてきて直接インストールする必要がある。

ちなみに、今のところAndroid Studioだからきちんと動作をしないという事象には出くわしていない。

素晴らしいなと感じたのが、ファイルが自動保存されるタイミングやビルド（デバッグ実行）したタイミングで、自動的にreformat codeが走ってくれること。しかもそのSave Actionsのreformat codeで修正された部分は、自分が修正したコードとは異なる色で表示される（新規が緑、変更が青、Save Actionsによるreformat分はグレーみたいな感じで色分けされる）。あくまでAndroid Studioのエディタ上での表示の話なので、コミットする際に別れてくれるわけではないけれども。

なお、Save Actionsを導入する場合は、必ずFile path exclusionsに.gradleファイルを追加する必要がある。

https://github.com/dubreuia/intellij-plugin-save-actions/issues/51

Gradleファイルをいじる際に、キーをタイプするたびにreformat codeなどが走るというバグがあるからだ。

個人的にはプラグインのバグというより、IntelliJ系IDEの仕様なのではないのかと思っている。gradleファイルはspaceを追加するだけでも「syncしろ」と言ってくるので、このあたりの動きが関連しているようにも思う。ともあれ、当座のところはgradleファイルをSave Actionsの対象外にすることでしのげる。

ともあれ、個人的にとても便利なプラグインだと思う。あまりに感動して作者にお礼のツイートを送ってしまうほど、ドンピシャなプラグインだった。

少し幸せになる技術というスライドで紹介されていたが、私は少しどころではなくかなり幸せになれた。ありがたい。

以前から作ってみたいなぁとは思っていたのですが、このたびやや必要性が増したこともあってAndroid Studio用のプラグインを作りました。

作成時間の半分くらいは環境構築に手間取っていたと思います。

ソースコードはGitHubで公開していますが、クローンしてもそのままビルドしたりできるのかよく分かりません。一応自分でgit cloneして確認したりしてみましたが、Androidのプロジェクトと比べると一手間必要で面倒くさい感じです。

参考にさせていただいたプラグインはほぼほぼgit cloneしただけでは動かせなかったので、Gradleは偉大だなということを再認識しました。

ADB Friendlyという名前ですが、現状では端末の画面を回転させることしかできません。どんな感じかはYouTubeをご覧ください。

私は端末の画面を回転させながらメモリ使用量のグラフを見て、作成したアプリがメモリリークしていないかどうかを確認することがあります。グラフが右肩上がりに上がり続けていると、それはメモリリークが発生しているということです。

今までは端末を手に持って、縦横縦横・・・とやっていました。ところがつい最近、こんなものを買いました。Macbookのモニタ横に、スマホを固定するクリップです。

便利なのはいいのですが、モニタにスマホを固定していると、画面を回転させることができません。そもそも手で画面回転させるのも面倒くさいです。そこでプラグインを作ってやることにしたわけです。

参考にさせて頂いたサイトは最後にまとめました。偉大な先達たちに感謝です。

私はSDKを準備するところからつまづきました。開発に使っているのはIntelliJ IDEA 2016.1.1になるのですが、このバージョンをもとにIntelliJ Platform Plugin SDKを作るとInternal Java Platformに1.6を指定することができませんでした。

これに関しては開発に使うIntelliJと、SDKに使うIntelliJのバージョンは別物であると考えたほうがよいのだと思います。

IntelliJ Platform Plugin SDKを追加するには、プラグインを作るにあたって対象とするバージョンのIntelliJ IDEAを別途インストールし、それを指定してやるのが正しいのだと思います。

プラグインを作成する際に、AndroidでいうminSdkVersionのような指定がIntellij pluginにもあります。（私の場合<idea-version since-build="141.0"/>と指定しました）

このバージョンはIntelliJ14.1を意味するので（参考：Build Number Ranges）、実際にコーディングする最新のIntelliJとは別に14.1.6をダウンロードしてインストールしました。

Previous IntelliJ IDEA Releases

また、プラグインを開発していくにはソースコードがないとつらいと思います。別途IntelliJ-Community – GitHubをクローンしてソースコードを入手しておく方がいいでしょう。ちなみにcloneする際には自分がSDKに指定したブランチになっているかを確認しましょう。SDKで利用するclassファイルとソースコードの中身で食い違いが生じて余計に混乱します。

正直な所、公式のDeveloper Guideはお世辞にも分かりやすいとはいえないので、ソースコードとすでにある先人たちのPluginこそがお手本でした。

このプラグインはKotlinとGradleを使って作りました。既にやってくださっている方がいらしたので非常に助かりました。

Android Studioは常に最新を追いかけるんだ、なんてやっていた私ですが、最近ではそれもやや保守的になりつつあります。その理由の一つに、アップデートでプラグインを入れなおさないといけないというのがあります。

例えば1.4から1.5にバージョンを上げると、今まで使っていたAndroid Studioのプラグインは入れなおしになります。設定項目は引き継いでくれるのに、なぜプラグインは引き継いでくれないのか不思議です。マイナーバージョンアップによってプラグインが誤動作する可能性を考慮して、プラグインだけは引き継がないようにしてるのでしょうか？

GoogleのMaterial Design Iconをプロジェクトに取り込むのに便利なプラグインです。

ちなみに余談ですが、Android Studio 1.4からVector Assetなる機能が追加されています。Vector Assetを使うとMaterial Design Iconを取り込むことができるのですが、これを使うためには条件があります。minSDKを21以上にするか、それができない場合はgradleのandroid pluginのバージョンを1.4以上にする必要があります。SDK21未満だとvectorを扱うことができないので、これをpngファイルとして書き出してやる必要があるのですが、それをするためにはandroid plugin 1.4以上が必要なのです。ちなみにgradleのandroid plugin1.4以上（これを書いてる時点では最新が1.5）はbeta版であり、気軽には導入できません。

結局Material Designのアイコンを取り込もうと思うと、こちらのプラグインを利用するのが楽なのです。

とりあえず入れてる系プラグイン。そもそも私自身がDashを使いこなせていないのが問題。

Crashlyticsを導入するのに使っているというか、それ以外の使い方をよく知りません。発生したcrashなどを確認するのに便利なんでしょう、たぶん。

私の場合、アプリを作ったらそのまま放置してしまっているので、いかんなぁ、改善せんとなぁと考えているところです。たぶん、今後お世話になる機会が増えていくプラグインだと思います。

Android StudioからGenymotion使ったエミュレータを起動するのに使うプラグインです。

しかし最近は実機でデバッグすることが多いので出番があまりありません。動作の軽快なエミュレータといえど、貧弱な私の開発環境では実機で確認した方が早いんですよね。久しぶりに起動したらGenymotionがちゃんと動かないという状態になっていて、余計に出番が遠のいてしまいました。

Android StudioでVimキーバインドを有効にするプラグインで、私の中でなくてはならないプラグインの1つです。

OSの機能（cmd + x、cmd + v）ではなくIdeaVimのddを使う場合に、移動先にゴミがあったのでxキーで削除して、いざペーストしようとしたら、xキーで削除したゴミが貼り付けられてしまった。「なんでだよムキーっ」とイラッとした経験を持つ人はきっと多いはずです。

そんなことにならないように、xキーで文字削除する際にレジスタを書き換えないようにする設定です。正確に言うと、IdeaVimではなくVimの設定の話ですけどね。

~/.ideavimrcを作成して以下の2行を書くだけ。

nnoremap x "_x
vnoremap x "_x

意味としてはノーマルモードとビジュアルモードにおいて、Xキーのキーマッピングを"_xに書き換えるという意味です。

"_とはなんぞやという話ですが、これはブラックホールレジスタという特殊なレジスタを表しています。Xキーのデフォルトの挙動は、1文字デフォルトのレジスタに移動するというものですが、この移動先をブラックホールレジスタに指定してやるという意味になります。

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に触れてみるのもいいのではないでしょうか。

アプリ開発をしていてバカにならないのが、デバッグにかける時間です。頻繁にエミュレータを起動して動作確認を行うわけですが、デフォルトのエミュレータ（Android SDKのエミュレータ）はとにかく起動が遅いです。さらに動作ももっさりしていて、お世辞にも動作確認しやすいとはいえません。

そこで動作確認の時間をできるだけ短縮するためにも、Genymotionを導入しておくことをおすすめします。起動も早く動作もスムーズなので、デフォルトのエミュレータを使うのが馬鹿らしくなります。

私の環境で実際に両者を比較した動画を撮ってみました。

Genymotionを利用するためには、ユーザー登録が必要になります。

また、エミュレータを動かすために別途Virtual Boxが必要になります。

Genymotionをインストールできたら、端末の登録を行いましょう。Genymotionは実在する端末のエミュレーションを行うものなので、よく使う端末をとりあえず登録しておけばいいと思います。

サポートするAndroidのバージョンに合わせて登録しておくといいでしょう。私はとりあえず、Android2.3の端末と、自分の持っているGaraxy S3を登録しています。

端末の追加はそんなに難しくありません。予め用意されている端末から、エミュレーターとして使いたいものを選択するだけです。

Android StudioからGenymotionのエミュレータを起動するためにも、Genymotionのプラグインも一緒にいれましょう。別に入れなくても使用に問題はありませんが、入れておいたほうがエミュレータの起動が捗ります。

こんな感じでAndroid Studioから起動しやすくなります。

インストールの仕方はAndroid StudioのPreference > PluginsからGenymotionを探してインストールするだけです。そうすることでAndroid Studioの右上にGenymotion用のアイコンが追加されます。

Genymotionではデフォルトのエミュレータと比較して、画面サイズやAndroidのバージョン、SDカードの有無など細かなところまでカスタマイズすることができません。特にFreeライセンスでは利用できる機能に制限があるため、Android SDKのエミュレータを完全に置き換えるものではありません。

ですが基本的なデバッグ・動作確認にGenymotionを利用することで、アプリ開発における動作確認の時間を短縮することができると思います。基本的にはGenymotionを使うようにすれば、開発がだいぶ捗るのではないでしょうか？