Android Studio のショートカットを覚えられない人のための最小限な2つ

こんな便利な機能があったのかと驚きました!!

(About) 10 Things You (Probably) Didn’t Know You Could do in Android Studio — Google Developers — Medium

いろいろあって便利ですよね!!

しかし「ここで!!」「いざ!!」 というときに忘れてる.

自分が頻繁に使うものだけ覚えればいいのだろうが思い出せない.

結局, ネットで検索することになり, Windows や Mac で微妙にキーが違ったり.

Ctl や Alt などの特殊キーの組み合わせは覚えづらい.

覚えられない人はどれから覚えたらいいのか.

Top 10 Android Studio Shortcuts - InnovateCode

上から2つのショートカットだけ覚えておこう.

機能の検索 - Ctl + Shift + A
テキストの検索 - Shift 二回押し

一つ目の「Find Action」(Ctl + Shift + A) で使える比較的覚えやすいキーワードだけ覚えておこう

completion
template
find
jump
postfix
search
replace
recently
keymap
auto
last
build
...

_About__10_Things_You__Probably__Didn’t_Know_You_Could_do_in_Android_Studio_—_Google_Developers_—_Medium

指で覚えてしまうまでは, これでいいや!!

AndroidStudioの設定場所やショートカットは「FindAction(テキストランチャー)」が捗りすぐる件


プログラマーのヘルプにもなる DuckDuckGo「Programming Instant Answers」

成長を続けているようです. かわいいアヒルでお馴染み(?)の.

DuckDuckGo

DuckDuckGo

こんな機能がアナウンスされています.

DuckDuckGo Blog : How we're trying to help programmers

プログラミング言語とキーワードの組み合わせを入力して検索するとヘルプのように結果が表示されます.

チートシートなども結果として準備されていたりします.

bash_time_-_DuckDuckGo

cheat_sheet_php_-_DuckDuckGo

strpos_php__PHP__-_DuckDuckGo

loop_python__Python__-_DuckDuckGo

hello_world_mysql_-_DuckDuckGo

hello_world_java_-_DuckDuckGo

hello_world_perl_-_DuckDuckGo

現在は, まだ言語によってまだばらつきがあるようですが, 多くの言語をカバーしようとしているようです.

Programming_IA_Coverage_·_duckduckgo_duckduckgo_Wiki

Programming IA Coverage · duckduckgo/duckduckgo Wiki

公開されているドキュメントをみてみるといろいろな試みをおこなっているようで非常に興味深いです.

How_Instant_Answers_Work___DuckDuckHack_Docs

How Instant Answers Work | DuckDuckHack Docs

DuckDuckGoとは?

たしか「プライバシーな情報は取得しない」というフレーズだけが聞こえてきてたように思うのですが, こちらはこちらで進化を続けていたのですね.

早くもっと大きなアヒルに育って欲しいですね.


直感的に理解する RxJava その3: リアクティブであることのメリット

ReactiveX

RxJava について, その1では「基本的な構造」, その2では「強力な Operator」についてみてきました. しかし, あなたは RxJava のメリットについて納得していないでしょう. ここでは, RxJava フレームワークがもつ他のいくつかのメリットを明らかにしていきます.

エラーハンドリング

ここまで onComplete() と onError() には触れませんでしたが, これらは, Observable がアイテムを発するのを停止したときに, 成功完了なのか, エラー停止したのかを示しています.

Subscriber は onComplete() と onError() をリッスンする機能をもっています. 実際にやってみましょう.


Observable.just("Hello, world!")
    .map(s -> potentialException(s))
    .map(s -> anotherPotentialException(s))
    .subscribe(new Subscriber<String>() {
        @Override
        public void onNext(String s) { System.out.println(s); }

        @Override
        public void onCompleted() { System.out.println("Completed!"); }

        @Override
        public void onError(Throwable e) { System.out.println("Ouch!"); }
    });

potentialException() と anotherPotentialException() の両方が, Exceptionを throw する可能性があるとしましょう.

すべての Observable は一回のコールにつき onComplete() か onError() で終了します. そのとき, プログラム出力は "Completed!" かまたは, Exception が throw されたときは "Ouch!" を 最後に出力します.

これらから分かることがあります.

1.「Exception が throw されたときはいつでも onError() がコールされる」

このことは, エラーハンドリングを極めてシンプルに可能にすることを意味しています. 結果, これだけですべてのエラーをハンドルできます.

2.「Operator は Exception をハンドルする必要がない」

Exception は onError() までスキップするので Observable チェインのどこかで起きた問題をどのように処理するかを Subscriber までは気にしなくて良いということになります.

3.「Subscriber がアイテムの受取りを完了したかどうか把握できる」

タスクが終了するタイミングを知ることはコード上で必要になることがあります. ただ, Observable が終了しない可能性もあります.

このことは, これまでのエラーハンドリングに比べてかなり分かりやすいでしょう. コールバックを使う場合は, それぞれのコールバックでエラーをハンドルしなければならず, 同じコードの繰り返すことになりますし, それぞれのコールバックは, どのようにエラーをハンドルするか, を知らなければなりません. このことは, コールバック部分のコードは密に呼び出し側と連携されているということになります.

RxJava では, Observable は エラー時の処理を知る必要が無く, エラーの状態をハンドルする必要もありません. エラーの場合は処理をスキップして, すべてのエラーハンドリングを Subscriber に置くことができます.

Scheduler

Androidアプリでネットワークリクエストを利用するとします. それが時間がかかるものであれば, 別のスレッドでロードします. そこで問題がおきたりすることが有ります.

マルチスレッドのAndroidアプリは難しく, 正しいスレッドで正しいコードを実行することを確実に行わなければなりません. これは混乱してアプリがクラッシュする可能性がとなります. メインスレッド以外からViewを操作するとException が発生することはご存知だと思います.

RxJava では, subscribeOn() を使うことで どのスレッド上で実行するかを Observer に教えることができます. また observeOn() を使うことで Subscriber を実行するスレッドを指定できます.


myObservableServices.retrieveImage(url)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(bitmap -> myImageView.setImageBitmap(bitmap));

シンプルですね. Subscriber までのすべての処理は I/Oスレッドで実行されます. そして最後にメインスレッドでViewの操作が行われます.

メインスレッドのブロックをできるだけ少なくするために, Subscriber はできるだけ軽くする.

これらは非常に便利で, すべての Observable に subscribeOn() と ObserveOn() を追加することができます. ただの Operator です. 何の Observable であるか, 前の Operator が何をしているかについては気にする必要はありません. 簡単にスレッドの振り分けを指示することができます.

Observable の処理に時間がかかる場合に, Subscriber がすでにI/Oスレッドで準備できていれば, それを監視する必要がないので subscribeOn() から observeOn() を先延ばしにすることは良い実験になります.

AsyncTask などでは, どの部分を並列処理にするかある程度設計しなければなりませんでしたが, RxJavaを使うと そのまま並列処理と追加するだけでよいのです.

Subscription

他にもまだ説明していないメリットがあります. Observable.subscribe() をコールした時これは Subscription を返します. これは, Observable と Subscriber のリンクです.


Subscription subscription = Observable.just("Hello, World!")
    .subscribe(s -> System.out.println(s));

このリンクである Subscription を以下のように利用することができます.


subscription.unsubscribe();
System.out.println("Unsubscribed=" + subscription.isUnsubscribed());
// "Unsubscribed=true" と出力される

RxJava が unsubscribe を操作することの良いところは, チェインをストップすることができることです. 複雑な Operator のチェインを利用している場合, unsubscribe を使うことでいつでも実行中のコードを停止することができます. 他に処理は必要ありません.

その1で Observable.just() は, onNext() と onComplete() を単純にコールすることに比べて, すこし複雑であることを書きました. その理由は Subscription にあります. それは onNext() をコールする前に, Subscriber がすでに subscribe されているかどうかを実際にチェックするからです.

まとめ

気に止めておいて欲しいのは, これらの話は RxJava の序論です. ここで説明したことよりもっと多くの学ぶべきことがあると思います. たとえば, Backpressure について調べてみてください.

すべてに これらのリアクティブなコードは使う必要はありません. シンプルなロジックにしたい複雑なコードに対して利用しましょう.

これらの説明で このおもしろいフレームワークを始めるには十分だと思います. もっと学びたければ, 公式 RxJava Wiki を読むことをおすすめします. そして「可能性は無限」であることを忘れないでください.

元々は, この記事で最終にする予定でしたが Android 向けの実用的なサンプルのリクエストが多く, その4 を書いています.

[原文] Grokking RxJava, Part 3: Reactive with Benefits

直感的に理解する RxJava その1: 基本的な構成

直感的に理解する RxJava その2: Operator

直感的に理解する RxJava その4: Reactive Android