ふと、こういう書き込みを見つけた。
国税庁 - 仮想通貨に関する所得の計算方法等について（情報）
雑所得扱いとなる申告が怖くて面倒くさいので利確できない
↓
BTC下がる
↓
利益がある限り利確できない
↓
BTC下がる
↓
利益がなくなる
そんなビットコインに対しての日本人の状況。
ビットコイン、取引シェア日本４割 個人の投機大半 ：日本経済新聞
2017-12-22 18:36 現在まさしくその流れ。
日本人はほんとに養分となってしまうのか。
がんばれ日本! 負けるな日本!
FCM と Notification の併用をやめてバックグラウンド受信時にうれしがる
ややこしすぎな気がします。
この記事のタイトルも書いてて意味不明です。
以下のような、FCMにJSONをPOSTしてアプリで受ける場合の話です。
curl https://fcm.googleapis.com/fcm/send -X POST \
--header "Authorization: key=FirebaseConsoleのプロジェクトの設定、クラウドメッセージングのタブにあるサーバーキー" \
--Header "Content-Type: application/json" \
-d '
{
"to":"/topics/all",
"data":{
"title":"New Notification!",
"body":"Test"
},
"priority":"high"
}'
このPOSTするJSONに含まれるデータ構造によって、アプリ側で受信する場合の処理の流れ変わって見通しが悪くなります。
きれいにまとめられています。
Firebase Notificationでアプリの状態による挙動の違いについて - Qiita
アプリがフォアグラウンドにある場合、このServiceのonMessageReceived()が呼び出されることになります。
アプリがバックグラウンドにある場合はこのonMessageReceived()は呼ばれることはなく、システム側で自動的にシステムトレイに通知を表示します。
"data"ブロックはConsoleからも含めることはできます（詳細オプションのカスタムデータで指定できる）。しかし、Consoleでは"notification"ブロックを省略することができません（メッセージ文を入力しないと送信できない）。
送信したメッセージに"data"ブロックがあっても、"notification"ブロックが存在する限り、アプリがバックグラウンドにある状態ではFirebaseMessagingServiceのonMessageReceived()は呼ばれません。
"data"ブロックの内容を受け取れないわけではありません。通知をクリックして起動したActivityのintentに含まれることになります。
"data"ブロックの内容の処理が、フォアグラウンド時に受け取ったときはFirebaseMessagingServiceで、バックグラウンドのときにはActivityでとなってしまって煩雑です。
実際に試してみると、これら書かれてることすごく良く分かります。
結局、この"notification"ブロックの特典としては、
アプリがバックグラウンド状態で受信した場合にのみ、アプリ側の実装なしで通知トレイに入る。
ということだけでしょうか、おおまかですが。
すべてのメッセージ受信時にonMessageReceived()が呼び出されれば、アプリがフォアグラウンドにあるかバックグラウンドにあるかを気にする必要がなくなります。
なるほど。
では、入れ子にしたらいいんじゃないかと。
例えば、
{
// ...
"notification": {
"title" : "News!!",
"body" : "New Product Release!!"
},
"data": {
"user": "Yamada Taro",
"age": 20
},
// ...
}
を以下のように入れ子にする。
{
// ...
"data": {
"user": "Yamada Taro",
"age": 20,
"notification": {
"title" : "News!!",
"body" : "New Product Release!!"
}
},
// ...
}
すべてサービスで受けることができます。
class MyFirebaseMessagingService : FirebaseMessagingService() {
override fun onMessageReceived(message: RemoteMessage) {
// ...
// 2層目以下はStringで送られてくるのでMap化
message.data["notification"]?.let {
val notification : Map<String, String> =
Gson().fromJson(it, object : TypeToken<HashMap<String, String>>() {}.type)
sendNotification(notification)
}
}
// サンプルを参考に
private fun sendNotification(notification: Map<String, String>) {
val intent = Intent(this, MainActivity::class.java)
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP)
val pendingIntent = PendingIntent.getActivity(this, 0, intent,
PendingIntent.FLAG_ONE_SHOT)
val channelId = getString(R.string.default_notification_channel_id)
val defaultSoundUri = RingtoneManager.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION)
val notificationBuilder = NotificationCompat.Builder(this, channelId)
.setSmallIcon(android.R.drawable.ic_notification_overlay)
.setContentTitle(notification["title"])
.setContentText(notification["body"])
.setAutoCancel(true)
.setSound(defaultSoundUri)
.setContentIntent(pendingIntent)
val notificationManager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
notificationManager.notify(0, notificationBuilder.build())
}
quickstart-android/MyFirebaseMessagingService.java at master · firebase/quickstart-android
元々、Firebase てのは、敷居を下げてマーケティングなどに利用を広めようとしてるのかな。
Amazon vs Google の排除合戦に Apple が参入した?
ネットの中立性があやしくなってきていますが。
米、「ネットの中立性」撤廃 コンテンツの扱い格差容認 （写真＝ＡＰ） ：日本経済新聞
で、最近のニュース。
GoogleはEcho Show向けにAmazonが用意したYouTubeアプリがGoogleの利用規約に違反しているとして、Echo ShowでYouTubeを使えないようにしました。その直後、AmazonはGoogle系列のスマートホーム企業Nestの一部製品をAmazonで販売停止にして対抗します。
AmazonとGoogleのバトルが激化 ユーザー不在の締め出し合戦へ - ITmedia PC USER
そんなことを考えながら、
ADBをアップデートして少しビビる、今日。
ビルドツールを更新すると、OS X上でADBが動作しなくなる
Updating to build tools 27.0.2 breaks ADB on OS X : androiddev
$ cd $ANDROID_SDK_ROOT
$ rm -r platform-tools/
$ curl https://dl.google.com/android/repository/platform-tools_r26.0.2-darwin.zip -o platform-tools_r26.0.2-darwin.zip
$ unzip platform-tools_r26.0.2-darwin.zip
iPhone の Apple をGoogleの敵と単純に考えてしまってはいけませんね。
すいません。
Architecture Blueprints の非同期処理実装にみる Android SDK の方向性
MVP、MVVM、Clean Architecture、Dagger2、Data Binding、Archtecture Components などいろいろな組み合わせの実装例が ToDoアプリにて公開されています。
非同期処理部分を見てみると現在はすべて(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)
}
}
}
それに対応するデータベースやストレージ向けのExecutorを作ります。
class DiskIOThreadExecutor : Executor {
private val diskIO = Executors.newSingleThreadExecutor()
override fun execute(command: Runnable) { diskIO.execute(command) }
}
これらを使って以下のようにして非同期処理を実装します。
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)
}
}
}
}
AsyncTask/Loader APIs の排除の方向性は、「Deprecated(廃止予定) samples」に移動されたブランチからも認識できます。
この流れについては、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 の主役たちの使い方も理解することができます。
素晴らしいですよね。