d WiFi を使うための長き道のり

この話。　

NTTドコモは、無料で公衆Wi-Fiが利用できるdポイントクラブ会員向けサービス「d Wi-Fi」を3月25日から開始した。NTTドコモの携帯電話回線を契約していなくとも利用が可能。

👉 誰でも使えるフリー公衆Wi-Fi「d Wi-Fi」開始、無料のdポイント会員登録でNTTドコモ以外のユーザーも - INTERNET Watch 

使ってみよう。

 

「d WiFi」とは何なのか。

「docomo Wi-Fi」(2021年度中に終了予定)に代わる公衆Wi-Fiサービス。

SSIDはこれまでと同じ「0000docomo」「0001docomo」

同時接続台数は5台に拡張される。

NTTドコモの携帯電話回線を契約していなくとも利用が可能。

👉 d Wi-Fi | サービス・機能 | NTTドコモ 

dポイントクラブ会員なら、ドコモのケータイ回線をお持ちでないお客さまでも、無料でd Wi-Fiをご利用になれます。

→ dポイントクラブ(無料) の会員登録が必要。

 

「d ポイントクラブ」 とは何なのか。

「dポイントクラブ」は便利でおトクなポイントプログラムです。
ドコモ回線をお持ちでない方も含め、どなたでも無料でご入会になれます。

👉 dポイントクラブ | サービス・機能 | NTTドコモ 

→ dポイントカード利用登録が必要。

 

「dポイントカード」とは何なのか。

dポイントカードは、dポイントをためて、つかえるdポイントサービス専用カードです。スーパーやコンビニなど、街のお店（dポイント加盟店）でdポイントがどんどんたまります。

👉 【dポイントクラブ】dポイントカードとは - ご利用ガイド 

ぐぬぬ。。。

もういいです。。。

次回、使ってみます。。。

 

まとめ

「dポイント」 の利用促進の意味が強いように見えます。

いつもよりまして

しくみも登録手順も面倒くさすぎ。

👉 急げ!「d Wi-Fi」への設定変更【6/30 docomo Wi-Fi 終了】 

がんばれドコモ!

負けるなドコモ!

👉 ドコモユーザーが無料「docomo WiFi」を契約すべき3つの理由 
👉 通信量制限のことは「docomo WiFi」で忘れてよし! 

 

追記: 2020-06-26

変更しました。

ポイントカードはオンライン式にて。

SIM認証があるなど。

詳細は以下から。

👉 急げ!「d Wi-Fi」への設定変更【6/30 docomo Wi-Fi 終了】 

👉 3キャリアの新料金プラン移行の前にしなくてはならない2つのこと 

オードリー・タン氏のPRにみる言語選択肢の表示文字

これ。

👉 東京都のコロナ対策サイト、台湾の“天才IT大臣”も改善に参加　オープンソースの取り組み、「胸アツ展開」と話題 - ITmedia NEWS 

👉 Fix language selector label for zh-TW (体 -> 體) by audreyt · Pull Request #827 · tokyo-metropolitan-gov/covid19 

❌ 繁体
⭕ 繁體

ということになります。

あれ、

「繁体」

のほうをよく見かけるような気がしませんか??

本当に「繁体」は間違い?

繁体字（はんたいじ、繁體字、拼音: fántǐzì）

特に中華人民共和国の一連の「文字改革」政策による簡体字（簡化字）との対比によりこう呼ぶ。現在では主に台湾のほか、中華人民共和国の特別行政区である香港・マカオで使用され、中華圏外の華人コミュニティーでも見られる。

👉 繁体字 - Wikipedia 

Google 翻訳のWEB版とアプリ版の選択肢をみてみます。

そうか、

サイトやアプリの「表示している言語」の設定で「言語の選択肢」の表示文字が変わるのですね!

👉 Google Language Codes - tomihasa 

4つの言語に関して、表示されるべき選択肢の文字を見ておきましょう。

hl=ja

英語
中国語(簡体)
中国語(繁体)
日本語

hl=en

English
Chinese (Simplified)
Chinese (Traditional)
Japanese

hl=zh_CN

英语
中文（简体）
中文（繁体）
日语

hl=zh_TW

英文
中文（簡體）
中文（繁體）
日文

オードリー・タン氏は、台湾の方なので、台湾向け言語表示としては

「中文（繁體）」

が選択肢に表示されるべき文字となるのでしょうか。

しかし、東京都のように選択肢の文字自体を表示言語に合わせて翻訳してないサイトもあります。

👉 都内の最新感染動向 | 東京都 新型コロナウイルス感染症対策サイト 

Android Pie 言語設定画面。

Android端末では、以前からこのような実装になっています。

フォントの事情がありますので、端末や文字によっては豆腐や文字化けなどに注意が必要です。

まとめ

呼称や表記でもめたりするネット上で

オードリー・タン氏の台湾愛を見たような気がします。

「NFC Pay」はAndroid端末でも使えるようになるのか

この記事。

セブン-イレブン・ジャパンは18日、全国約2万店のセブン-イレブンにおいて、2020年6月からVisa／Mastercard／JCB／Amex／ダイナースの5つのクレジットカードブランドを用いたNFC Type-A/Bによる非接触決済サービスの取り扱いを開始予定であると発表した。実際の利用時は対応カードなどをレジのリーダーにかざすだけで、サインや暗証番号が不要で支払いが完了できる。

今後も訪日外国人の増加が期待されるなか、セブン-イレブンでも海外で主流の決済サービスに対応するのは重要なトピックと言える。

👉 ASCII.jp：セブン-イレブンで6月からクレカ5ブランドのNFC Payが使用可能に 

そうだよな。確かにクレカは差し込む方式だよな。

あれ?

Android端末を使った Google Pay や おサイフケータイ でクレカを直接登録して非接触のかざすだけで使えるようになるのかな?


👉 一目で分かる「Pay(ペイ)」の基本 

 

そもそもハードウェアは対応してるのか

ぼんやり、

「国内版Androidはガラパゴス仕様チップNFC=FeliCa」で海外版のグルーバルのNFCと違う。

と認識してましたが。

こんな Pixel公式説明もあります。

日本で購入された Pixel 4、Pixel 3a、Pixel 3 スマートフォンの場合は、NFC と同じ箇所に FeliCa チップが取り付けられています。

👉 Pixel スマートフォンのハードウェアの図 - Pixel Phone ヘルプ 

これを見る限り、「ハードウェア的なNFC」は、国内版と海外版で違うような説明に見えますが、しかし。

Why is Google turning off FeliCa on Pixel models outside of Japan? I doubt it is a licensing restriction because the whole point of NXP PN81 is having all the global NFC licensing pieces, NFC A-B-F/EMV/FeliCa/MIFARE, all on one chip, all ready to go.

日本以外のPixelモデルでFeliCaをオフにしているのはなぜですか？ NXP PN81のすべてのポイントは、すべてのグローバルNFCライセンスの一部であるNFC A-B-F / EMV / FeliCa / MIFAREをすべて1つのチップに搭載しており、すべて準備が整っているからです。

👉 No global NFC evolution for Pixel 4? – Ata Distance 

Google might have left a backdoor to activate FeliCa later on non-JP Pixel 4 models

Googleは、後に非日本版Pixel4にFeliCaを有効化するバックドアを残した可能性があります。

👉 Pixel 4 goes cheap instead of deep – Ata Distance 

日本版Pixel4と同じチップでFeliCaのみ使えないものが海外版Pixel4搭載のチップ、ではないかと言っています。

では、実際Pixel3ではどうなっているのでしょうか。

 

日本版NFCチップこそグローバル?!

規格については、NFC周りはややこしくて流動的です。

👉 AndroidのHCE-Fについて調べてみたメモとサンプルソース - Qiita 
👉 NFC関係用語と解説 - Qiita 
👉 Advances with Osaifu-Keitai ―Starting Services Supporting NFC (Type A/B) on NTT DOCOMO UIM Cards 

このようなアプリがあります。


👉 NFC TagInfo by NXP - Apps on Google Play 

端末にかざしたモノに反応して、その情報を表示してくれます。

日本独自のFeliCa代表としてPASMOをかざしてみます。

反応して FeliCaな「NFC-Type F」を表示しました。

続いて、AmericanExpress をかざしてみます。セブンイレブンなどでは差し込む方式で、非接触としては使えないものです。

ガラパゴスなFeliCaでない「NFC-Type A」が反応しています。

 

まとめ

国内版Android端末(ハードウェア)は、海外仕様だと言われている「NFC Type-A」にも対応している。

海外版Android端末(ハードウェア)は、「NFC Type-F FeliCa」に対応していない。

Google Pay や おサイフケータイアプリ が対応すれば、きっと、クレカ登録だけでタッチ決済ができるようになりそうに思えます。

いや、大人の事情があるのかな。

👉 一目で分かる「Pay(ペイ)」の基本 

スマホリングの剥がし方

力ずくではカバーが外れてしまいます。

下敷きのような硬い薄い何かを差し込むと簡単に剥がれます。


KYOKA スマホ リング ホールドリング 薄型 スタンド機能 落下防止 車載ホルダー 360回転 iPhone/Android各種他対応 (ブラック)


Homefunny 解体ツール8セット 携帯電話の修復ツール FOR iPhone 画面 修理 工具 開腹・分解・修復用専門ツール

あなたは 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