Android 9 Pieへのアプリ対応

ICカードこれひとつ、どうやらAndroid 9 Pieでは動作していません。
GooglePlayへの怒濤のクラッシュレポートでandroid.database.sqlite.SQLiteExceptionが発生していることは分かるのですが、どこでどのような理由で発生しているのかが分からないため、手の打ちようがありません。

しかし開発機にはいつになってもPieが降ってこず、しかし早急な対応を求められているので、仕方が無いのでお金がかかる方法を用いて対策を講じることにしました。

端末購入の資金調達ができるか否か


今後長期にわたり開発機として利用でき、サポートも長いGoogleのPixel 3を購入したいと思っておりました。
3年間のサポートがあり、Android 12まで対応することが保証されているからです。
しかし13万円くらいします。
数えるほどしかサポート会員がいない現状では、高くてとても買うことができません。

では、受益者負担の原則に基づいて、Pieでの利用を有料とするとした場合、どの程度賛同が得られるでしょうか。
ツイッターでアンケートを実施したところ、次のような結果が出ました
31票中
39% 対応希望(課金するので早く対応して欲しい)
61% 希望しない(対応は1年でも2年でものんびり待つ)

母集団31票では少なすぎるのでこの結果で判断はできませんが、いずれにしてもサポートに要する莫大なコストを負担するとしたユーザーは少ない状況でした。

僅か500円でも、30人くらいが1年払ってくれるだけでPixel 3を1年で入手できるわけで、アプリ開発も今後数年は安泰になるわけですし、今回のPie対応に要する開発費(人件費)についてもこの数倍の会員がいれば何とかなるわけですが、その人数に到達していないので、いまこれを買うことはできません。大赤字がさらに増えてしまいます。

結論として、開発用のスマホを買う資金の見通しすら立ちませんでした。

借りるしかない


買う資金が得られないのであれば仕方が無いので、誰かに借りるしかありません。
ということで、きょう、レンタル業者に申込書を送り費用を入金したので、今週中にPie端末が弊社に届くはずです。
しかし所詮はレンタル、幾らお金を払ってもその端末は弊社のものにはならないのです。残念なコストです。

受益者負担の原則を適用します


Pie端末での利用は完全有料化します。
1年間を目処に、急行券(300円/月)以上必須とする計画です。
それ以降はPieでも無料試用モードが使えるように開放する予定ですが、その頃には恐らくAndroid 10対応で10は有料になっているのではないかと思います。

とりあえずある程度の入会者を確保しないとアプリの存続に関わりますが、もし多くの会員が確保できたなら、先に述べたPixel 3購入も視野に入ります。

ユーザーにとっても、急行券なら現在あるプレミアムサービスの全機能が使えますし、「近くの店をさがす」機能まで使えるので、Pieを使いたいという先進的なユーザーには最適なプランでしょう。
またそういう先進的な方々がプレミアム会員になってくれるのであればアプリにとってもこれ以上良いことはありません。

とりあえず事前の調査


そもそも、どこでエラーが発生してアプリは落ちているのか。
事前に検索して、それらしき候補がStack Overflowにありました。

Android P - 'SQLite: No Such Table Error' after copying database from assets

データベースはassetsから複写して使用しているわけですが、filePathの取得まわりを変更する必要があるのではないかと予測をしているところです。
とりあえず事前に何らかの対応をし、届いたPieスマホで検証をしていきたいところです。

残ったスマホレンタル期間は、Pieでの使い勝手などをじっくりみてUIの改善などをしていきたいと思っています。

2018/12/11(火)20:29 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

複数の電子マネーに対応したリーダーに共通のIDを与える考察

電子マネーを使った店名を表示するために


全国のICカードこれひとつは、交通系電子マネーやWAONに対応し、その店舗名、レジ番号までを特定して登録・表示するサービスを提供しています。
この実用化のために多くの力を注ぎ、今では何とか技術面では実用化を達成したと考えており、あとは情報の充実があればという状況です。

店名・レジ名等の表示の改良


弊社サイトで対応店舗の一覧表を掲示しております。
一覧も少しずつ改良しており、現在は店までを共通化し、その下に複数の電子マネーに対応する場合はそれぞれごとに分けた上で対応するレジ等を掲出しているのですが、一つの端末でも複数の電子マネーに対応した場合はどうしても分かれて表示されてしまいます。
これは、全く異なる仕様の電子マネーを一つの一覧に混ぜている以上、ある程度はやむを得ないのですが、これを更に統合できないか、と考えています。

現状と想定する理想


現在は、次のような階層構造になります。

店舗名
 ICOCA
  レジ1
  レジ2
 WAON
  レジ1
  レジ2

脳を駆使すれば、レジ1とレジ2の計2台があり、それぞれICOCAとWAONに対応している、と読み取ることができますが、ぱっと見て判断するのは難しいですし、機械処理で全自動で認識することもできません。

理想としては、次のような表示にしたい。
店舗名
 ICOCA+WAON
  レジ1
  レジ2

この表示なら、一目で分かります。
ただこれをどうやって実現すれば良いのか?が課題となります。

思いつき


WAONのデータベースに交通系電子マネーのSPRWIDを、
交通系電子マネーのデータベースにWAONのSPRWIDを、
それぞれ入れておけば照合することができ、まとめられるのではないかと一瞬は考えました。
しかしすぐに、交通系も9カードのほかにSAPICAとIruCaという伏兵があり、店によってはKitaca+SAPICA+WAONであるとか、ICOCA+IruCa+WAONという対応をするものもあることを思い出して、この方法は無理なのであきらめました。
また交通系については、SPRWID全桁分かっている店は数えるほどしかなく、殆どは未知なわけですから、交通系電子マネー側にも何らかの一意性のある独自のIDを別途振ってあげないと、機械処理が難しいという結論になりました。

レジや自販機にIDをつけよう


レジのRW端末や自販機を一意に特定するIDについて考えてみました。

汎用性を高めるなら、会社の番号+店の番号+レジの番号、あるいは会社の番号+自販機番号、といった形になるでしょう。

お店のレジにIDをつけよう


会社の番号は、12桁もありますが登記所が使う会社法人等番号や、更に1桁増えて13桁もありますが国税庁の法人番号というものがあります。

セブンイレブンは各店ごとの店番号が分からないのでローソンを例にしますが、
株式会社ローソンの法人番号は2010701019195
ローソン1号店のローソン桜塚店の店舗コードは086993
らしいので、更にレジ1番とすると
2010701019195-086993-1

のような形の不定長文字列とするのが良いのかも知れません。
ただIC R/Wは複数レジで共用する店もありますので、その場合はどうするのかも考える必要があります。

自販機にIDをつけよう


自動販売機の場合、持ち主が存在することと、大抵なんらかの番号が付いていることから、自販機を一意に特定することは可能だろうと思います。

例えばコカ・コーラウエスト株式会社の自販機で、設備コードが930-1234567だったとすると、

コカ・コーラウエスト株式会社の法人番号は2290001075614

なので、
2290001075614-930-1234567

のような形の不定長文字列とするのが良いのかも知れません。

ただ、報告の場合、この番号を記載していない例が多々あるので、その場合どうするのかを考える必要があります。

データベース上での扱い


このIDをデータベースのキーにしてしまえば交通系もWAONも一つのデータベースに統一はできます。
ただ現状を考えると、交通系にしろWAONにしろ、データベースのキーはそれぞれのSPRWIDとして維持し、DBも分けておくのが最良と思われるので、実際に運用するならば、このIDはキーではなく情報として、DBにフィールドを一つ新規に追加して格納し、表示するタイミングで一致するものをまとめることになるでしょう。

さらに考えるべき点


ただ問題もあり、個人経営の店舗などの場合は当然ながら法人番号などはないですし、店でもよく調べないと経営主体が分からないものもあります。
ユーザーからの報告で情報が足りないものも多く発生しうるので、その辺りをどう解決するかが必要でしょう。
現状でも物販対応が追いついていない状況、できるだけ作業効率を高める必要があり、実際に運用するとした場合どうするかを考えないといけません。

2018/11/07(水)16:11 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

神戸市社会実験バス(連節バス)の調査結果について

神戸市社会実験

神戸市が平成30年10月に、「連節バスに乗って神戸のウォーターフロントを楽しもう!」という社会実験を実施しました。

去年も実施したらしいのですが弊社は知りませんでした。今年はアプリユーザーが増えたことが奏功し、弊社にも情報が流れてきたようです。

報告に期待するだけで全停留所の網羅は難しいだろうと判断し、今年は、神戸は非常に遠いですが出掛けて参りました。実際の調査状況についてはマストドン(まちトドン)にトゥートした通りとなります。

停留所

この社会実験の停留所は全5停留所で、ループします。何周かしたら終点はハーバーランドumie前として一旦終了となります。

  • 三宮(そごう前)
  • ハーバーランドumie前
  • 中突堤
  • 新港町
  • 神戸ポートオアシス前
  • 三宮(そごう前)

調査結果

三宮乗車は時間の都合上、弊社では調査を省きましたが、次のような結果が出ました。

  • 「三宮」と「ハーバーランドumie前」は同じ番号らしい
  • 「中突堤」「新港町」「神戸ポートオアシス前」は番号が異なり、それぞれ近いが、上の番号とは距離がある

弊社としての判断

総評

上記調査結果から、弊社では次のように判断しました。

  • 「三宮」と「ハーバーランドumie前」は社会実験として割り当てた専用の臨時番号を用いたのではないか
  • 「新港町」「神戸ポートオアシス前」は、神姫バスの在来路線の停留所番号をそのまま使っているのではないか
  • 「中突堤」は路線はないらしいものの、必要を感じて専用に番号を作った(またはあらかじめ用意されていた)のではないか

三宮とハーバーランドumie前

ハーバーランドumie前は観光バス用駐車場の一角にいかにも臨時を思わせるポールを立てていたので当然ながら常設の予定はないと思われ、臨時番号を付けるのは違和感がありません。この場所を選んだのは、長い連節バスを転回させる必要があったためと思われます。

しかし三宮も同じ番号というのは謎ですね。

三宮はそごう前のY5のりば(ポートアイランド方面行きの乗り場)が使われていました。これはこれで専用の番号が既にあるので流用は可能だったとは思いますが、理由は不明ながらそれを使わなかったようです。

新港町と神戸ポートオアシス前

「新港町」は今まで報告がありませんでしたが、かなり以前からある路線の停留所のようです。

「神戸ポートオアシス前」はどうやら4月のダイヤ改正で新設された停留所のようです。路面のバス停のペイントが比較的新しく、ここから新しさを感じました。

この二つの停留所はこれまで報告がなかったため今のところ在来路線との比較ができませんが、恐らく社会実験で既存の番号が使われたのだろうと考えられます。

中突堤について

「中突堤」は、現存路線はないらしいものの、この停留所のために専用に番号が用意されていると思われました。

この付近の路線は不明なため、過去にあって廃止されたのかもしれませんし、もし過去にもないのなら今はない中突堤(神戸ポートタワー)周りの路線を作る計画が実はあるのではないか(現在は神戸市交通局/神戸交通振興の路線などが存在する)と予想されます。

ちなみに社会実験中の中突堤停留所のポールは路面埋め込みではなく、ベースの上にポールを立てているタイプで、中突堤中央ビル入口前に置かれていました。実験が終わったら撤去されるのでしょう。この場所が選ばれたのは恐らく、連節バスの長さから長い直線が必要だったためと思われます。

2018/10/29(月)13:43 |Comments(0) |Trackback(0)

地域振興 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

Pocket Changeの交通系チャージに不具合の疑い

解決済


本件は10月10日に解決した旨、連絡を受けております。
以下に5日に書いたものをそのまま残しておきますが、既に解決しておりますので、Pocket Changeは安心して利用できます。


はじめに


10月5日から、Pocket Changeは交通系電子マネーに対応しました。
京都駅のPocket Changeは動かなくなって久しいので、大阪の難波まで現物を見に行きました。
pocketchange.jpg


WAONとICOCAでそれぞれチャージを試しましたが、ICOCA(交通系電子マネー)のカードへの書き込みが期待と外れており、処理に不具合がある可能性が存在するため、ここにその状況を指摘しておきます。
同内容は既に「お問い合わせ」から報告をしています。

調査対象


大坂難波から徒歩移動可能な次の三箇所を確認しました。

ドン・キホーテ 道頓堀御堂筋店
関西ツーリストインフォメーションセンター 大丸心斎橋店
ホテルエキチカ長堀橋(旧ホテルロア)

WAONは恐らく問題ありませんが、交通系電子マネーについては、この三箇所全てで不正値をカードに書き込んでいました。

状況


交通系ICカードには、SPRWIDと呼ばれる物販端末を一意に特定する番号のうち一部が記録されます。
SPRWIDが分かれば、カード内に書かれる内容は計算だけで求められます。
しかし、レシートに印字されるSPRWIDと、実際にカードに記録されるべき番号が全く一致していませんでした。
これは、次のいずれかが想定されます。

①レシートに印刷されるSPRWIDが間違っている
②カードに書き込む値が間違っている

状況からの判断では、②カードに書き込む値が間違っている ものと思われました。

実際


3店舗で、それぞれ次のような結果となっています。

ドン・キホーテ 道頓堀御堂筋店
 レシートのSPRWID JW10721010990
 期待されるカード内番号 C8-6D2E
 実際のカード内番号 C8-8B8E

関西ツーリストインフォメーションセンター 大丸心斎橋店
 レシートのSPRWID JW10721010984
 期待されるカード内番号 C8-6D28
 実際のカード内番号 C8-71D5

ホテルエキチカ長堀橋(旧ホテルロア)
 レシートのSPRWID JW10721010982
 期待されるカード内番号 C8-6D26
 実際のカード内番号 C8-3DDD

それぞれで1回ずつしか試していませんので、実際にはチャージごとに異なる値が書き込まれている可能性もあります。

30台程度稼働しているらしいPocket Changeに、各契約カードごとに連番でSPRWIDが振られたと考えられ、うち近畿圏ではICOCAのJWから始まるSPRWIDが連番で振られていると見込まれます。
実際この3店は近い番号が付いています。
ということは、レシートに印刷されているSPRWIDに不審な点は見当たらず、恐らく正しいのだろうと判断できます。

一方、カードに書き込まれる値はデタラメで、計算からも導けません。結果として、交通系ICカードに不正値を書き込んでいると判断することができます。


利用者側の対策


一応確認に使ったICOCAは破損せず、不正値が書かれると言ってもカードがめちゃくちゃになるほどの内容ではありませんでした。
しかし動作が不正である以上、カードを破損する恐れもあるので、修正されたというアナウンスがあるまでは利用を控えるべきかと考えます。

2018/10/06(土)10:04 |Comments(0) |Trackback(0)

技術情報 | 電子マネー | 株式・投資・マネー | [編集]

▲ページトップ

パソリRC-S380への対応に成功

このたび、ICカードこれひとつはパソリ(PaSoRi)、以下パソリに対応することができた。

これにより、家電量販店で安価に販売されており、かつまた確定申告の電子申告などにも利用できるパソリを、ICカードこれひとつでも活用できるようになった。
仕様が無償では公開されていないこのパソリへの対応は大変だったものの、無事に解析と対応をすることができた。

種類


パソリは大きく二種類、古いRC-S956チップセットのものと、新しいPort-100チップセットのものとがある。

既に製造中止となった古いRC-S956チップセットのものは、RC-S330/RC-S360/RC-S370が該当するが、こちらは資料が豊富ですんなり対応できた。
一方Port-100チップセットのRC-S380は、資料が非常に乏しく苦労したものの、無事にコマンドを見つけ出し、遂に対応することができた。

安価に済ませる前提の開発であるため解析による実装となり、つまりソニーの認証などはない状態で作っているため動作については弊社が保証する必要があるものの、コマンドの送受信ができるのなら恐らく大丈夫だろうと思われる。

パソリ対応は、Android用カードビューアーとしては他にほぼ例がなく、ICカードこれひとつでの対応は、極めて強力な機能になると思われる。
これは、自信を持って、堂々プレミアムサービスとして提供をする。

以下に、開発で気付いた点をメモしておく。

コマンドの違い


RC-S956とPort-100はコマンドが違う。
どちらもNXP PN533互換のフレーム構造ではあるものの、相互に互換性はゼロで、RC-S956のコマンドをPort-100に投げても無視される。ACKすら返らない。

RC-S956


RC-S956は、NXP PN533でいうNormal information frameで動作する。
00 00 FF LEN LCS TFI … という形式になる。
コマンドもなぜかNXP PN533互換で作られていて、ゆえに無償で仕様が公開されているNXP PN533にならって実装をすれば、古いパソリに対応できることになる。

Port-100


一方Port-100は、Extended information frameでないと動かない。
00 00 FF FF FF LEN LEN LCS TFI … という形式になる。
なぜこのフレーム構造にする必要があったのか、実装を終えてみても分からない。長いフレームを送受信する必要があったのだろうが、解析しにくくすることが目的の可能性もあったのではなかろうか。

そしてここからが大問題で、TFIが異なる。

TFI


TFIは、そのフレームの方向を表わすためのバイトである。

RC-S956は、NXP PN533互換で、送信はD4h、受信はD5hである。
一方Port-100は独自拡張で、送信はD6h、受信はD7hであり、もってNXP PN533非互換となっている。

そして、送受信されるパケットデータも異なり、まずコマンド番号とコマンドの種類が全く違う。
Port-100は、NXP PN533とは全く異なるコマンドセットとなっている。

互換だと何かしら問題があったのか、Port-100では故意に仕様を変更したように見える。

424とはなんぞや


FeliCaの標準は212kbpsであるが、仕様上、212k/424k/848k/1.6Mまでが定義/予約されている。

ICOCAは212だけだが、大容量なためアプリの読み込みが遅いとクレームが多いSuicaは424に対応している。
なら424にして倍速読み込み!と行きたいところだったが、既知の範囲内で424にするコマンドを送っても、以降はコマンドエラーが返るだけとなり、通信ができなくなってしまった。
現時点では、424は使い方が分からないため使うことができない。


MIFAREはやっぱり読めない


Port-100は、MIFARE Ultra lightなどは対応していて当然読めるはずなのだが、今のところRC-S956と同様、読み込みには成功していない。

設定が間違っているのかもしれないし、送信するコマンドが間違っているのかもしれないし、理由は分からないがまだまだ調査・研究をしないとパソリでMIFAREを読み取るのは難しいようである。

2018/09/30(日)21:37 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

カレンダー

11 | 2018/12 | 01
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 - - - - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterマストドン

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR