USB3.0 が WiFi 2.4Ghz に干渉しすぎて無駄にケーブルやアダプタが増えて金は減る

MacにUSB3.0ケーブルを差すとはっきりWiFiの接続が切れまくる。

もしや、と思い調べてみると。

USB3.0 機器から発生する高周波ノイズも、2.4Ghz無線LAN機器に大きく干渉し、良くない影響(通信速度の低下や通信断)が発生するようです。

USB3.0機器から発生するノイズは、2.4Ghz無線LANに悪影響を与えるらしい。 - ぼくんちのTV 別館

え、中華なケーブルやアダプタって買ってみて気づくこと多くない?

ネットのレビューやランキングって当てにならなくねえ?...

Apple 公式にも。

USB 3 デバイスがコンピュータに接続されていると、Wi-Fi または Bluetooth デバイスが正常に動作しないことがあります。なぜですか?

一部の USB 3 デバイスは、無線周波数干渉を引き起こすことがあります。これによって、2.4 GHz 帯を使用する Wi-Fi および Bluetooth デバイスとコンピュータとの通信に問題が生じる場合があります。

Mac で USB デバイスを使う - Apple サポート

この、WiFiの周波数の話は以前混線が気になっていたのが、もう4年前とか。

公衆無線LANとかWiFiが途切れる場合「5GHz帯」に切り替えたほうがいいんぢゃね?

今、同じアプリで計測してみると、2.4GHzはあいかわらず混雑で、5.0GHzも混んで来ている模様。

ルータを見てみると、今では旧型となり、2.4Ghz オンリー。

当然、飛んでいるWiFiのSSIDにも -g -gw のみ。


○○-a	IEEE802.11n	5GHz帯	        600Mbps
○○-aw	IEEE802.11a	5GHz帯	        54Mbps
○○-g	IEEE802.11n	2.4GHz帯	600Mbps
○○-gw	IEEE802.11g	2.4GHz帯	54Mbps

無線LANルーターのwifiのID内にある「g」「a」「gw」「aw」の意味 | JoyPlotライフ

買い替えますか、WiFiルータ。

【価格.com】無線LANルーター(Wi-Fiルーター) | 通販・価格比較・製品情報

最近のガジェットて使えるものなのに無駄に購入したりしてません?

もう2000円のルータを買おうと思います。 ← これが原因か! (笑)

👉 「これは分からないわ…」Mac miniで2.4GHz帯のWi-Fiが全く通信できないので調べてみたら1000円くらいで買った中華製のHDDケースに付いてたUSBケーブルが原因だった - Togetter 
👉 公衆無線LANとかWiFiが途切れる場合「5GHz帯」に切り替えたほうがいいんぢゃね? 


Architecture Blueprints の非同期処理実装にみる Android SDK の方向性

MVP、MVVM、Clean Architecture、Dagger2、Data Binding、Archtecture Components などいろいろな組み合わせの実装例が ToDoアプリにて公開されています。

googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.

非同期処理部分を見てみると現在はすべて(todo-mvp-rxjavaを除く)が以下の実装となり、非同期処理の主役であった AsyncTask/Loader API を利用した記述は消え去っています。

まず、java.util.concurrent.Executor(s) を使って、AppExecutors を作っておいて、


open class AppExecutors constructor(
    val diskIO: Executor = DiskIOThreadExecutor(),
    val networkIO: Executor = Executors.newFixedThreadPool(THREAD_COUNT),
    val mainThread: Executor = MainThreadExecutor()
) {

  private class MainThreadExecutor : Executor {

    private val mainThreadHandler = Handler(Looper.getMainLooper())

    override fun execute(command: Runnable) {
      mainThreadHandler.post(command)
    }
  }
}

AppExecutors.kt

それに対応するデータベースやストレージ向けのExecutorを作ります。


class DiskIOThreadExecutor : Executor {

  private val diskIO = Executors.newSingleThreadExecutor()

  override fun execute(command: Runnable) { diskIO.execute(command) }
}

DiskIOThreadExecutor.kt

これらを使って以下のようにして非同期処理を実装します。


appExecutors.diskIO.execute {

  // IOスレッドで実行する
  // ...

  appExecutors.mainThread.execute {

    // メインスレッドで実行する
    // ...

  }

}

実装例では、コールバックを使ってPresenterまで伝達しています。


override fun getTasks(callback: TasksDataSource.LoadTasksCallback) {

  appExecutors.diskIO.execute {

    // IOスレッドで実行する
    val tasks = tasksDao.getTasks()

    appExecutors.mainThread.execute {

      // メインスレッドで実行する
      if (tasks.isEmpty()) {
        callback.onDataNotAvailable()
      } else {
        callback.onTasksLoaded(tasks)
      }

    }

  }
}

TasksLocalDataSource.kt

AsyncTask/Loader APIs の排除の方向性は、「Deprecated(廃止予定) samples」に移動されたブランチからも認識できます。

googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.

この流れについては、droidcon NYC 2017 - Android Architecture Round Table でも、話が挙がっていました。

it looks like Google is abandoning old API is like loaders and recommending patterns there are much less coupled with the framework, which is good but what happens with these API is are we abundant in then and I'm talking about classes like sync adapters loader async tasks etc

Google はLoaderのような古いAPI や フレームワークと関係の薄いパターンを推奨することをやめているように見えます。 それはいいことですが、それら古いAPIを捨てることは何を引き起こすか、AsyncAdapter や Loaderなどについて話したいと思います。

今後の、Android SDKは、フレームワークを意識したAPIが増えていくのでしょう。


すばやく理解する「Room x RxJava 」

いい記事があったので。

Room 🔗 RxJava – Google Developers – Medium

まずは、Room で Dao.


@Query(“SELECT * FROM Users WHERE id = :userId”)
User getUserById(String userId);

ここまでで問題なのは、

1. 同期呼び出しでブロッキング。
2. データ変更時に再度呼び出す必要がある。

ということで、RxJava を使いたくなります。

Room は RxJava2.x に対応しています。

Adding Components to your Project | Android Developers

どのように使うのか?

Maybe


@Query(“SELECT * FROM Users WHERE id = :userId”)
Maybe<User> getUserById(String userId);

1. 該当ユーザがなければ、何も返さずに complete。
2. 該当ユーザがあれば、onSuccess となり complete。
3. Maybe が complete されたあとにユーザー情報が更新されても何もしない。

Single


@Query(“SELECT * FROM Users WHERE id = :userId”)
Single<User> getUserById(String userId);

1. 該当ユーザがなければ、何も返さず onError(EmptyResultException)。
2. 該当ユーザがあれば、onSuccess。
3. Single が complete されたあとにユーザー情報が更新されても何もしない。

Flowable


@Query(“SELECT * FROM Users WHERE id = :userId”)
Flowable<User> getUserById(String userId);

1. 該当ユーザはなければ、何も返さず emit もされない。当然、onNext も onError も呼ばれない。
2. ユーザが存在すれば、onNext。
3. ユーザ情報が更新されるたびに、自動で emit されるので、UI上を最新データに更新させることが可能になる。

 

まとめ

これだけ数行でデータベース、非同期処理を簡潔明快に説明できる Room x RxJava の組み合わせ。

おまけに Observable から細分化された RxJava2.x の主役たちの使い方も理解することができます。

素晴らしいですよね。