これはひどい | #iOS | #Android ファショ通

アプリレビューでみるクソな Pay (ペイ)アプリの現状

最終更新日時 : 2019-07-04 13:36

ここ数日で不具合だらけのサービスリリースの記事を多く見かけました、7Pay とファミペイ。

👉 7payクレジットカード不正利用：第三者乗っ取りがあり得る致命的な2つの弱点(三上洋) - 個人 - Yahoo!ニュース

👉 7iDのパスワード再発行がセキュリティ的に最悪な件：パスワード変更しても無意味な状況 │ かえざくらのつぶやき

👉 7payの不正利用についてまとめてみた - piyolog

👉 セブン&アイの7pay、7日持たずに大コケ : 市況かぶ全力２階建

👉 セブンイレブンアプリ乗っ取りにより7payで30万円不正利用された人のツイート - Togetter

👉 やたらと「○○Pay」が増えすぎ問題！コンビニ大手のファミマが2019年7月からファミペイ開始を発表…と、もうゴチャゴチャです。 - クレジットカードの読みもの

その他、低評価Payアプリと比較しながら、Google Play ストアレビューを見てみましょう。

セブン-イレブンアプリ評価:3.5

7payが導入され、エラーコードが出て使えない‼️電話やメールしても返答なし。おまけに問い合わせの電話しても、すぐ切れるし…４日経っても何の対応もなし。いつになったらエラーコード回避できるのか？対応できないなら、やらなきゃいいのに‼️

7payを使用するためにインストールしましたが、会計時にアプリが立ち上がらず、結局nanacoで支払いました。運用開始して日が浅く、まだ不安定なのかもしれませんが使えないというのは致命的。入店する前に立ち上がるか確認してからでないと安心して買い物できません。尚、アプリは店を出てから繋がりました。利用価値は高いと思うので今後に期待です。

メールアドレスと電話番号さえ判れば、誰でも乗っ取ることができる。セキュリティーは無いに等しい。

ナナコカードとセブンペイ連携してチャージ出来るようにしてくれたら携帯をいちいち持たなくてもいいのにと思います

誕生日が解れば誰でもパスワードを初期化しアカウントを乗っ取れるようなので、使わないほうがいいです。

バーコードを真っ先に表示し、常に表示するようにしなさい。広告表示は後にしなさい。アプリのデザインについてユーザーがなんのためにアプリを立ち上げるか考えたことあるのだろうか。レジ前でモタつかせるような仕様にするな。

退会理由を入力できないようなアプリもどうかと・・・

再インストールしてログインできません！

訳が分からん。ナナコで充分な気がするし、いちいち 7ペイにチャージしないといけないし、提示にもアプリ立ち上げてから、時間がかかる。ナナコと紐付いてるとはいえ、チャージは別、という意味が分からん。

セキュリティ対策がザル（笑）危険すぎて使えない

メルアドと電話番号で簡単に不正利用できるらしいですまた他アカウントでログインするとそちらの生年月日と性別も抜かれるみたいですテレビでも宣伝していたので信用していた方も多いでしょうにねペイペイの問題を克服できるのかと思ったら全くそんなことはなくて残念です

クレジットカード不正利用されても責任を取らないまともじゃない企業

まとめてクーポン、使い方がわかりづらいです。還元率も不満。nanacoモバイルのほうが楽だったのに。現場目線で仕事してください。店員さんもかわいそう。⭐5つけてるのみんな本部社員でしょ？

会員コードをスキャンしてから、7Pay支払いするのは二度手間で使い勝手が悪い。 7Pay支払いの起動が遅いことがあるので、会員コードと7Payは同じ画面になってないと支払いに手間取り、別の支払い方法を選らばなければならない。

7Payの注意書きでは同社規定のアクセス手段であれば、例え第三者による使用であっても責任を負わないとあるし。ナナコは落とした場合、即時停止できず不正利用の補償もしないみたいだし。残高無くなったら辞めよう

とりあえず7Peyもチャージしたけど、モバイルnanacoのほうが手軽だし、店員も7Peyの操作に慣れていないみたいで時間がかかるしなので、最低限しか使わないかな。セキュリティ強化したのか？3日にしれっとアプリ更新してるし。

セキュリティーに問題あり怖くて使い物にならない

👉 セブン-イレブンアプリ - Google Play のアプリ

ファミペイアプリ評価:2.9

ファミマTカードアプリを入れていたら、勝手にインストールするされていた。やめてくれ

会員登録でＳＭＳに認証コードが届かなく、登録できない。

新しくなってからログインができない

ファミチキクーポン表示されない… 「ポッカサッポロの辛王激辛肉みそスープ」と辛いモノ苦手なので絶対食べないクーポンしか出ない… セキュリティとか色々、信用できないのでアンインストール!!

SNS認証で画面が戻ってしまう不具合があり、登録出来ません。

Tカードクレカじゃないとオートチャージ／チャージ不可。その他は現金からチャージ。Tマネーと何が違う？とりあえずTカードクレカの人だけ使えるサービス。

いまだに何度トライしても認証コードのSMSが届かない。アプリというよりサーバー側に問題がある？

認証がされない為、登録自体出来ない。原因は分からないまま。残念です。

なかなか登録できないし、やっと登録できてクーポンを使おうとするとエラー表示。アプリの動作確認をしてないんですか？

何十回やっても認証のメールが来ないので使えない。

都合の悪い書き込みを消すな

会員登録したいくて携帯番号入力しているのにいつやってもＳＮＳで電話認証のメールが来ないし、聞きたい事があってサポートセンターにかけても１時間繋がらないしどうなっているんだ！後店によってＴポイントカード出してもポイントは貯められないからファミペイに変えればペイポイントは貯められるからと拒否された店舗もあるんだけどどうなっているんだ？😤

電話番号にSMSを送っても届きません。登録出来なきゃ使えませんよ😫

SMS届きません

何度やってもメッセージアプリを変えても認証コードが送られてこないので登録できない。

SMSが来ないんですが

システムエラー多すぎ！使いたい時エラー表示。チャージした意味ない！最悪!!

👉 ファミペイアプリ - Google Play のアプリ

Line Pay 評価:2.6

チャージできないアプリになる前はよく使ってたけど、アプリに変えた意味不明

パスワード？を忘れてる場合指紋認証して合致したのにまた入力画面に戻されるのですが。どうしたらいいですか？

想像絶する使い勝手の悪さラインモバイル使用してるので一緒に使用したほうがお得かと思いアプリを導入しましたが使ってもポイント付与の気配がないのでもう消すよ

LINE本体でLINE PAYのショートカット作るのと変わらないのでわ･･･ LINE PAYカードには連携してないようですし･･

単独アプリである意味が不明。バーコード表示したいだけなのにカメラが起動するのもよくわからないし、クーポン等を見ようと思うと必ずマップのページを通過することになり、回線速度やGPSの状況が悪いと固まって使い物にならない。決済でもバーコードを読み取ったもののレジ側でエラーが出た事があり、普通のLINEアプリ経由で払いました。 LINEアプリの方でバーコード画面のショートカットが作成できますので、こちらのアプリはキャンペーン時にポイント還元枠を増やす用ですね。

バーコード決済の場合、3%とカラーレッド0.8%を足して3.8%のポイントが入る筈が、毎回3.7%でしかポイントが付与されていない。この質問をメールで問い合わせても、レスは帰ってこない。かれこれ2ヶ月経つが、修正する気あるのだろうか。

なんでもかんでもアプリにするな！LINEアプリ多すぎ。スマホパンクした。LINE本体以外は全部アンインストールです。

👉 LINE Pay - 割引クーポンがお得なスマホ決済アプリ - Google Play のアプリ

ゆうちょPay 評価:2.2

ゴミアプリだ。全くログインのが出来ないし意味がわからない。パスワードが違ったのかとパスワードを忘れたを選択してもメールが来ないからどうしようもない

クソアプリ

後発なのに他社から何も学んでない。どこの会社に作らせたのでしょうか。流行ってるからとりあえずやってみた感じでしょうか。

ユーザーを無視したアプリ作成側の自己満足アプリ。確認コードを見に行くと初期画面になり、確認コード入力画面に戻れなくて、アカウント登録をさせない仕様になっている。しかも機能的に○○payの中で一番低機能。使えない。こんなアプリによく開発費払えたね

ログインIDもしくはパスワードが間違っていますから進めません。何度パスワードの変更を行ってもNG

ゴミアプリすぎる。事前に何がパスワードで何がIDなのか周知しない、メールでも送ってこないからいきなりログインできない。もしくは合っていても反応しないのか知らんがとにかくログインできない。個人情報盗まれるだけなので利用しない方が良い

登録すると500円のポイントプレゼントというのと、取引銀行がゆうちょ銀行であった為に丁度いいと登録したがまったく使えない。ログインしようとパスワードもきちんと入力したけどこのアカウントIDは使えないと表示。このアプリは個人情報を抜き取る為の詐欺アプリではないか！？と疑っている。問い合わせ先とかもないので非常にやられた感がする。ログインIDパスワードを抜き取る為の詐欺アプリなのでは！？こんな危険なアプリに入金なんてとてもじゃないが出来ない！しない！

最低システム、アプリがね。ダイレクト、残高使ってるけど関係ない。ゆうちょpay登録できないよ。時間がもったいないからやめた。ゆうちょもやめる。すべてがめんどくさい。

ポンコツ？一定時間操作していなかった、暗証番号を入力しろ、と言った表示が出たが、暗証番号を入れられない状態。白い意味不明のスペースが出ていて、何の操作も出来ないんですが！

👉 ゆうちょPay －あんしん＆べんりなゆうちょのスマホ決済 - Google Play のアプリ

auPay 評価:2.0

企画の勉強不足でしょうか。企業間で契約し、システム追加してもらう内容だと思います。一般の消費者は、支払アプリだと誤解してKDDIを不信に思いますよ。

最初の画面でログインIDとパスワードとと出てくるが設定もしてないのに間違えてますと表示されログインすらできない

このアプリいる？あんまいらないと思う。 auウォレットから aupayのページいって aupayへのショートカット作れるしそのショートカットから入ればこのアプリいらなくね？って思うけどどうですかね？

馬鹿がつくってんだな

ビジネス用が有るのに、コンシュマー向けアプリがgoogle playに存在しない、摩訶不思議。どうやって使うのか？スマホはMVNO、ガラケーはau、au ID、au walletカード使ってても、au payは使えない。

👉 au PAY for BIZ - Google Play のアプリ

まとめ

もしかして、本当は、「要らないもの」なんじゃねえか? ペイとかよ。

Android Paging Library と Retrofit

最終更新日時 : 2019-06-27 19:43

例えば、このパターン、Network only。

ここでは、PositionalDataSource を拡張するが、他のタイプのDataSource拡張でも同じ。

compositeDisposable のように viewModelScope をはるばる持ってきたにもかかわらず、


class RemoteDataSource(
  private val coroutineScope: CoroutineScope,
  private val service: RemoteService,
  private val s: String
) : PositionalDataSource<Item>() {

  @ExperimentalCoroutinesApi
  override fun loadInitial(params: LoadInitialParams, callback: LoadInitialCallback<Item>) {
    Timber.d("RemoteDataSource#loadInitial: ${Thread.currentThread().name}")
    ...

loadInitial() 内は、メインスレッドではなく、別スレッドで実行されている。


Timber.d("RemoteDataSource#loadInitial: ${Thread.currentThread().name}")


D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_0
D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_1
D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_3

これらは、Android Architecture Component が作成した独自スレッド。

よって、同期なRetrofitの実行処理で良い、となる。

If I use enqueue with Retrofit 2.3 it will doesn't work but if i do a .execute() the LiveData is correctly triggered

Retrofit 2.3で、enqueue() を使用しても機能しませんが、execute() を実行するとLiveDataが正しくトリガーされます。

Android Paging Library LiveData> is triggered before the end of the api call

公式リファレンスにも記述はあるという。

To display data from a backend server, use the synchronous version of the Retrofit API to load information into your own custom DataSource object.

バックエンドサーバーからのデータを表示するには、同期バージョンのRetrofit APIを使用して、独自のカスタムDataSourceオブジェクトに情報をロードします。

Network only - Paging library overview

しかし、DiffUtilを使ったリフレッシュなアニメーションが実行されない。

「手間がかかる」でなく「沼にハマる」ことが最近は多くなった。

APIの仕様がおせっかいすぎやしないか。

しきいを下げようとして、余計に混乱させるばかり。

👉 あなたは Android Architecture Component をどう思いますか?
👉 Fragment と Toolbar の歴史の話 - Qiita

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

最終更新日時 : 2019-06-18 00:15

ある人々の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