スマホ持ってる人10人いたらどのプラットフォーム/バージョンか?【国内】

日本国内の場合。

7人が iPhone
3人がAndroid

👉 Mobile Operating System Market Share Japan | StatCounter Global Stats 

5人 iOS12 2018年9月17日リリース
1人 iOS11 2017年9月20日
1人 iOS10 2016年9月8日
1人 Android 9 2018年8月6日
1人 Android 8 2017年8月21日
1人 Android 7 2016年8月22日

👉 Mobile & Tablet iOS Version Market Share Japan | StatCounter Global Stats 
👉 Mobile & Tablet Android Version Market Share Japan | StatCounter Global Stats 

こうしてみると明らかにAndroidはバージョンアップに失敗してるよな。

👉 iPhoneシェア率が異常!世界と逆をいく日本のスマホ市場【2019年3月】 


あなたは Android Architecture Component をどう思いますか?

ある人々のTwitter上の会話。ザクッと翻訳サービスを利用して眺めてみます。

Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI.

率直に言って、かなりの数のアプリケーションがすでにDIを使用している。したがって、コンテキストを介して依存関係を渡すためのさらに別の方法を提供するのはやり過ぎです。すべての「非DI機能」は、DIがない場合のギミック/回避策にすぎません。

On Android this sadly isn't the case. We seem to relish in bad architecture.

It's either "Why do I have to pass an executor/scheduler/dispatcher? So much boilerplate!" or "Why can't I test on the JVM? This library is poorly designed!"

Maybe KEEP-87 will save us from ourselves?

Androidでは、これは悲しいことではありません。悪いアーキテクチャーで大喜びしているようです。

「executor / scheduler / dispatcher を渡す必要があるのはなぜですか? かなりのボイラープレートです。」、「なぜJVMでテストできないのですか?このライブラリは適切に設計されていません。」

多分KEEP-87は私達を私達自身から救うのだろうか?

👉 [Kotlin] KEEP87 brings compiler-driven dependency injection without frameworks : androiddev 

On unrelated note. (disclaimer: I'm not an Android developer) I have a feeling that something is broken in testing or architecture approaches here. I've been writing huge (1M+ LOCs) UI apps for more than a decade and never had to use either DI or statics to make them testable.

無関係なメモについて。 (免責事項:私はAndroidの開発者ではありません)何かがここでテストやアーキテクチャのアプローチで壊れていると感じています。私は10年以上にわたって巨大な(1M + LOC)UIアプリを書いてきました。そしてそれらをテストするために DI や statics を使う必要は決してありませんでした。

Android never had architecture guidelines and the docs encouraged doing all the wrong things to make the tutorials easy. Basically equivalent to writing everything in main(). Even now almost all of the architecture offerings treat symptoms of this legacy and not the disease.

Androidはアーキテクチャのガイドラインがなかったので、チュートリアルを簡単にするためにすべての間違ったことをすることをドキュメントを奨めてきました。基本的にmain() ですべてを書くのと同じです。現在でも、ほとんどのアーキテクチャがこの遺産の症状を治療していて、疾患を治療していません。

👉 Roman Elizarov on Twitter: "@JakeWharton Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI." / Twitter 

みなさんはどう思っていますか?

Roman Elizarov
@relizarov
Team Lead @JetBrains, working on @Kotlin coroutines and libs, sports programming/ICPC, concurrency & algorithms, math/quantitative finance; formerly @Devexperts

👉 Roman Elizarov (@relizarov) / Twitter 

Jake Wharton
@JakeWharton
Opinions expressed here are my own, not those of my company. They made me write this because I complain about Inbox going away so much.

👉 Jake Wharton (@JakeWharton) / Twitter 


Apple AirPods を Amazon で買うことできます?

有線うざいでしょ?

電車でおっさんに絡まったり、引っかかったり。

なので、BTのヘッドホンを、と思い探してみるとやっぱりこれしかないよね。

👉 AirPodsを選択 - Apple(日本) 
👉 AirPods with Wireless Charging Caseを購入する - Apple(日本) 

3種類あるんですね。

イヤホン+ワイヤレス充電器
イヤホン+有線充電器
ワイヤレス充電器のみ

Amazon で買えるんかな、と思い見てみると以下。

AppleアクセサリAirpods & ヘッドフォン Authorized Reseller

それぞれ。


Apple AirPods with Wireless Charging Case (最新モデル) ¥24,613

Apple AirPods with Charging Case (最新モデル) ¥19,213

Apple Wireless Charging Case for AirPods (最新モデル) ¥9,493

「Authorized Reseller」とか書いてるけど、コメントを見ていると、微妙に中華感を感じてポチれません。

公式サイトで本物を、と一瞬思いましたが、イヤホン部分の形状が自分にフィットするか、を確かめたく、まずは、2000円ぐらいの中華版を購入しました。

数ヶ月使いましたが、私の耳の形状に対しては、左側だけが歩いているとよく落ちたりします。

橋や駅のホームで落とすと悲しいことになりそうです。

それでも、使い勝手に不自由することもなく、音質はこれまでの有線のヘッドセットと同じに聴こえます。

近所の100均ショップはいつもお客さんが一杯で常にレジが長蛇の列です。

お試しコスメとかゴミ袋など消耗品をよく買いにいきます。

別に中華版でもよくね? と思ったりすることが最近は多くなってきてません?


Related Categories :  AndroidapplemacReputationTools


本当にスマホはラジオを備えたのか?

毎日のジョギング時に1時間、radiko というアプリを使っていますが、
通信量が、1.5~1.8G/月 でした。

👉 radiko 

これは、格安SIM利用で、だいたい 1000~2000円/月 の範囲。

👉 格安SIMでradikoは聞ける?おすすめの回線プランを紹介! | ゴリラでもわかるBIGLOBEモバイル 


👉 エンタメフリー・オプション 通信制限にサヨナラ!|格安SIM/スマホのBIGLOBEモバイル 

ということで、

スマホでなく、「ポータブルラジオ」のがよくね?

ポータブルラジオ
価格: 1000~2000円
重さ: 160g
電源: 乾電池
通信: 使い放題



パナソニック ラジオ FM/AM/ワイドFM対応 シルバー RF-P155-S


パナソニック ラジオ FM/AM/ワイドFM対応 シルバー RF-P55-S


パナソニック AMラジオ シルバー R-P145-S


AM/FM/ワイドFM対応 ポケットラジオ オーム電機 RAD-P2227S-K(ブラック)


OHM AM/FM コンパクトポータブルラジオ [RAD-F1771M]

当然、非常時にもポータブルラジオは役立ちます。

👉 地下鉄で Radiko を途切れずに聴き続けるかんたんな方法 
👉 NexusOne や NexusS とか Desire とかでFMラジオをかんたんに受信できる件(Radikoではなくて) 


【MVVM】Transformations.switchMap() の使い方

👉 ViewModels and LiveData: Patterns + AntiPatterns – Android Developers – Medium 
👉 LiveData beyond the ViewModel — Reactive patterns using Transformations and MediatorLiveData 

LiveData をリアクティブに操作できるこのユーティリティメソッド。

LiveData を変換します。
これから返されるLiveData オブジェクトを Observe しておけば、Observer のライフサイクルを考慮しながら、データを変換することができます。lazy に処理され、呼び出しや依存関係の記述なしに、ライフサイクル関連の動作が引き継がれます。

👉 Transformations | android.arch.lifecycle.Transformations  |  Android Developers 

実体は MediatorLiveData のユーティリティ

ソースコードを見てみます。


@SuppressWarnings("WeakerAccess")
public class Transformations {

    private Transformations() {
    }

    @MainThread
    public static <X, Y> LiveData<Y> map(
            @NonNull LiveData<X> source,
            @NonNull final Function<X, Y> mapFunction) {
        final MediatorLiveData<Y> result = new MediatorLiveData<>();
        result.addSource(source, new Observer<X>() {
            @Override
            public void onChanged(@Nullable X x) {
                result.setValue(mapFunction.apply(x));
            }
        });
        return result;
    }

    @MainThread
    public static <X, Y> LiveData<Y> switchMap(
            @NonNull LiveData<X> source,
            @NonNull final Function<X, LiveData<Y>> switchMapFunction) {
        final MediatorLiveData<Y> result = new MediatorLiveData<>();
        result.addSource(source, new Observer<X>() {
            LiveData<Y> mSource;

            @Override
            public void onChanged(@Nullable X x) {
                LiveData<Y> newLiveData = switchMapFunction.apply(x);
                if (mSource == newLiveData) {
                    return;
                }
                if (mSource != null) {
                    result.removeSource(mSource);
                }
                mSource = newLiveData;
                if (mSource != null) {
                    result.addSource(mSource, new Observer<Y>() {
                        @Override
                        public void onChanged(@Nullable Y y) {
                            result.setValue(y);
                        }
                    });
                }
            }
        });
        return result;
    }
}

👉 Cross Reference: Transformations.java 

ソースコードより、これは、1:1 の MediatorLiveData を使うための便利ツールです。


class MainViewModel {
  val repositoryResult = Transformations.switchMap(userManager.user) { user →
     repository.getDataForUser(user)
  }
}

複数に変換したい場合は、直接 MediatorLiveData を使うのが良いでしょう。


val liveData1: LiveData<Int> = ...
val liveData2: LiveData<Int> = ...

val result = MediatorLiveData<Int>()

result.addSource(liveData1) { value →
    result.setValue(value)
}
result.addSource(liveData2) { value →
    result.setValue(value)
}

まとめ

ViewModel 内で、その下にある Repository との間で使います。

View (Activity / Fragment) のライフサイクルにも考慮されています。

ViewModel内で、データの id からその詳細情報の取得をしたり、検索文字列をフィルターとしてデータ抽出したり、などに使うことが多いようです。

👉 MediatorLiveDataとTransformationsでViewModelを効果的に使う