ICカードこれひとつ iOS版開発準備の進捗

(前準備) Kotlin化完了のお知らせ


ICカードこれひとつ iOS版開発に向けて」で書きましたように、現在はiOSに移植するための準備をAndroid版で鋭意進めているところです。

このアプリはAndroid用アプリですので、当然ですがJavaで書かれていました。
iOSではSwiftというプログラミング言語を使いますが、Javaとは仕様・概念が大きく異なるため、Javaから直にSwiftに移植することは非常に困難です。
そこで、Swiftに似せて設計されたと思われるAndroid用のプログラミング言語Kotlinへの移植を進めました。

このたび、ICカードこれひとつを構成する120ファイル以上、総計約10万行になるソースファイル全てをJavaからKotlinに移植成功しました。
数々の大きな設計変更を伴いましたが、ある程度動作しており、鋭意不具合の修正作業を実施しております。

iOS版に向けた作業の進捗は、予想以上に順調となっております。

今後の残作業


当面はKotlin版の安定動作に努めます。

Kotlin化したことで、想定外の部分でNullPointerExceptionいわゆるぬるぽでアプリが異常終了する等、アプリ内にある潜在的なバグは激減したと思います。ただ移植したばかりで、動作検証は進めておりますが意図せぬ不具合が混入している可能性が高いですから、今後は機能追加なども含めて、鋭意メンテナンスしながら問題を洗い出し、安定性を高めてゆきます。

本バージョンは近日中にベータ版として配信し、多くの環境、条件で問題なく動作することを確認してから正式配信する予定です。

iOSアプリ開発開始予定


Kotlin版がある程度安定した頃、iOS用アプリ開発の環境も弊社内に整えて行きたいと考えています。
アプリ開発に支障がない程度の性能を有した税込10万円未満(※1)の中古のMacBook、およびSIMは不要なので安価な中古のiPhone7を入手し、プログラミングを開始する予定です。
(※1)10万円以上になると固定資産になり減価償却が面倒なため

ちなみに、Kotlinにしたからといって、それを単純にSwiftに変換すれば動くわけではありません。
AndroidとiOSは全く異なるOSでありプログラムの作り方も全く違うわけですから、基本的には0から完全に新規に作ることになります。
OS動作に関わらないところは基本的に同じですから、そういった部分はKotlin版を参考にSwiftで作り込んでいけば、同様に動作するものができるだろう、と期待をしているところです。

2019/07/14(日)15:44 |Comments(0) |Trackback(0)

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

▲ページトップ

ICカードこれひとつ iOS版開発に向けて

iOS用ICカードリーダーアプリ


iOS13から、通常のアプリよりSuicaなどFeliCaカードが読み取れるようになります。
従って早晩、AndroidのようにiOSでもカードビューアーアプリが有料無料問わず多数溢れるであろうことは想像に難くありません。
弊社も、iOS用「全国のICカードこれひとつ」を開発し、皆様のご期待に応えられるよう、準備を始めております。

お値段はAndroid版より割高とします


iOS用アプリはAndroidアプリと違って開発やストア維持にかかるコストが段違いですので、これはユーザーの皆様にご負担いただきます。仕方がありませんね。

その点について、Androidでは「100円は高い30円にしろ💢」「無料にしろ💢」「広告が邪魔だなくせ💢」などという人が跋扈していて途方に暮れた末、廉価ながら完全有料化してそういう方々にはお引き取りいただくことになった経緯がございますが、iOSユーザーのお気持ちは果たしてどうなのでしょうか、事前に確認しました。

「割高でも欲しいですか」という問いに、ものすごい勢いで「欲しい」という回答が寄せられ、待ってましたというご意見もいただきました。
価値の分かる皆様のために、期待に外れないようなアプリを開発し、提供していく所存です。ご期待下さい。

価値あるサービスを妥当な価格で


このアプリは、企業製品として、石油王でもなければ無料では提供し続けられないような「本物の性能」の提供を目指し、開発を進めております。

常に情報を収集し、月に数回最新情報や機能改良を加えてアプリを更新する、何気ないことですが、これは実は凄いことなのです。企業製品だからできるのです。

現在Android用に提供しているこれとほぼ同等の性能とサービスを、iOS用に提供できれば、きっとiOSユーザーにご満足いただけるものと確信を持っております。

プラチナサービス(仮称)


Android版のプレミアムサービスよりお高くなるため、サービス名は変更する必要があるだろう、ということになりました。また直販は難しく、ストア経由以外での販売は難しいだろうとみています。
そんな、心豊かな方々のための新プラン、仮称は「プラチナサービス」です。

発売前に再度アンケートをとり、当面売れそうな本数を概算して価格決定しますが、ダウンロード価格と月極価格はいずれも倍程度になる見込みです。単純に倍だと特急券が1000円になってしまい、かなりのプラチナ価格なので、実際どうするかは検討中です。販売時点での状況で、採算が取れるよう判断されます。

開発の準備


現在、将来的にiOSに移植するための前準備を開始しています。

iOSではプログラミング言語としてObjective-CかSwiftかを選択することになるようですが、迷わずSwiftを選びます。

Java→Swiftの移植はかなり困難なため、その前準備として、Android版もリファクタリング(作り直し)しています。
具体的には、JavaからKotlinに書き換えており、Android版もいずれは内部がほぼ別ものに変わります(プログラミング言語が変わるので)。
KotlinとSwiftは傾向が似ているため、Kotlin→SwiftはJava→Swiftよりは楽であろうと見込んでいます。

Java→KotlinもSwiftと大差ないくらい大変ですが、既に充分な開発環境がありますので、動作確認しながら作業を進めることができます。
Javaという言語に依存しすぎた設計が随所にありますので、この機会ですから設計も見直して、よりメンテナンスしやすい、移植しやすい形に改良をしております。

そしてiOSの開発については、いずれ開発環境を整えたところで、Kotlin→Swiftという移植を実施することになるでしょう。
中古でMac BookシリーズのどれかとiPhone 7を購入して利用する予定でおりますが、10万円を超えてしまうと経理が大変なので、1桁万円台で何とか入手できないものかと考えているところです。

予定


iOS版、Androidのリファクタリング含めて移植開発工数として半年程度を見込んでいますが、Android版開発の片手間になるので、多少伸びることも想定しています。
何とかプロトタイプ版だけでも年内に公開できたらと考えておりますが、このアプリは非常に多機能でありプログラムの規模も巨大なので、機能を維持しての移植はかなりの難作業が予想されます。

また、iPhone本体内蔵NFCの性能はまだ未知です。iPhoneは海外製品ですからほぼ間違いなく相性問題は生じる(読み取れないカードがある)ことでしょう。ですので、Android版と同様、パソリにも対応させます。USBは使えないですからBluetooth LE版パソリRC-S390に対応する予定です。

2019/06/20(木)15:19 |Comments(1) |Trackback(0)

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

▲ページトップ

「くしろバス」「阿寒バス」の「WAON」調査について

WAONで乗れるバス


北海道、釧路。
JR北海道のKitaca圏内ではないので交通系電子マネーも見込み無く、しかし沿線にイオンが多いということで「くしろバス」と「阿寒バス」ではWAONによる交通精算が導入されました。

Suica/PASMOほか10カードでは、バス乗車時にはカードに書き込みはしていません。
後ろの読み取り機ではカードのIDのみを読み取って、これを運賃箱で記録し、降車のさいに乗降の距離を判断して運賃を決定するのが一般的です。

しかし情報によりますと、非常に興味深い記述がありました。

QRかICカードか? 交通系チケットシステムを巡る世界の最新事情 (2/5)
WAON内部の記憶領域を使って出発地の情報を記録しておき、降車時にその差分を計算してWAONの電子マネー決済を携帯ネットワーク経由で行う

これはいったいどういうことなのでしょうか?

そこで


北海道に行って調査をしたいのはやまやまではありますが困難でありますので、沿線の方に協力をお願いしたいと考えております。

①乗車時タッチでも何かをWAONに書き込んでいるらしい
②降車時タッチでももちろん何かをWAONに書き込む(残高も引かれる)

ということなので、それを調査したいと考えております。

調査の方法


ICカードこれひとつ」を用いて、

①乗車にダンプツールで読み取って送信
②乗車タッチ後にダンプツールで読み取って送信
清算(下車)後にダンプツールで読み取って送信

という3回の調査をお願いできれば幸いです。
その際、乗車後と降車後では、それぞれで停留所名と整理券番号をお書き添え下さい。

3種類の情報を比較しながら、
①何か情報が書かれているか
②書かれているなら読み取れるか
③読み取れるなら解釈は可能か
といったことを調査します。

なにか知見が得られましたら、ICカードこれひとつ で随時対応をし、公共交通をより便利にご利用いただけるよう還元をさせていただきます。
調査にご協力をいただければ幸いです。

2019/05/28(火)21:18 |Comments(0) |Trackback(0)

製造開発 | 電子マネー | 株式・投資・マネー | [編集]

▲ページトップ

「バスの系統」データベース再設計

前回「ICカードこれひとつ「バスの系統」協力募集」で、系統情報の暫定的な仕様を定め、開発に着手しました。

実際にデータを登録してみて、保守性を確保するために用意した情報がかなり問題になりました。
無駄になることは最初から想定済みでしたが、全体としての分量が想定以上に多くなりデータベースが大きくなりすぎることが分かってきました。
そこで、よりシンプルで分かり易い仕様とするため、改めて設計をし直すことにしました。

細かな機能の実装は今後の課題となりますが、基本的な処理の作り直しを無事終えたので、メモ代わりに書いておきます。


方針


階層構造


「系統の情報」と「停留所の情報」は分離する。

系統は、「事業者」→「系統」→「ルート」→「停留所」という階層構造で表現できそうなことが分かってきたので、概ねこの階層構造でデータベースを作るものとする。

事業者だけのデータベースは不要なので、系統以下の3種類のデータベースに分割することになる。


系統情報データベース


各社の系統情報を1系統1レコードとして用意する。
同じ系統番号でも、若干経由地が異なったり、途中で車庫入りする等で部分的な運行となるルートがある場合は、どうするかは都度考える。

ルート情報データベース


ルートは往復ある場合で2ルートということになる。
夜など、途中で車庫入りするため途中で運転打ち切りになるルートなどもありうる。
曜日によって運行されるルートが変わることもある。

そういった情報ごとにルート番号を変更して記録し、このDBにはそのルート情報を格納する。


停留所情報データベース


ルートごとに、存在する停留所の一覧を記録するデータベースとする。


データベース構造


各項目の意味
※は検索用情報で、うち一部はKEYとなる。マークなしは原則として表示用

系統情報データベース


1 ※事業者番号
2 ※系統ID
3 内部利用のフラグ (未使用では0としておく)
4 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
5 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
6 バス=B
7 事業者名 (日本語名と英名は|で区切って併記する)
8 営業所名 (日本語名と英名は|で区切って併記する)
9 コミバスなどの名称 (日本語名と英名は|で区切って併記する)
10 系統のフラグ
11 系統の特性(表示用) (急行・特急・臨時などの情報をおく)
12 路線番号(表示用) (系統番号とは別に存在する場合用)
13 路線名(表示用)(日本語名と英名は|で区切って併記する)
14 系統番号(表示用)

●系統のフラグ(暫定仕様)
助 = 国・自治体・沿線住民等からの補助路線
免 = 免許維持路線



ルート情報データベース


ルート情報データベースは、主としてそのルートの起点終点および運行日が記録される。

1 ※事業者番号
2 ※系統ID
3 ※ルート番号 (0からスタートで9までの最大10種類、足りない場合があれば再検討)
4 内部利用のフラグ (未使用では0としておく)
5 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
6 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
7 ※ルートの運行条件
8 系統の起点(表示用)
9 系統の終点(表示用)
10 系統の経由地(表示用)



●ルートの運行条件

日本の公共交通のダイヤは次の種類がある

・日常的なダイヤグラム
1. 平日ダイヤ
2. 金曜ダイヤ (沖縄県など)
3. 土曜ダイヤ
4. 日曜祝日ダイヤ
・その他のダイヤグラム
5. 臨時ダイヤ
6. 免許維持ダイヤ (年1など)

運行曜日は日=0、土=6の数字で記述する。
毎日なら「0123456」、平日のみなら「12345」、土日のみなら「06」など

免許維持ダイヤは、DBには英字で記述し、アプリ側で特別な対応をするものとする。

例: 春分の日のみ (京都バス) 「SYUNBUN」


10月1日のみ、など特定の日付の場合、これは英字のみで表現する方法を模索する必要がある。




停留所情報データベース


ルートごとに、その停留所を記録する。
最低限必要なものはDB自体の検索キーと停留所番号のみだが、系統名や停留所名などがないと保守性が著しく低下するため、TSVファイルにはメモとして記載し、スクリプトで抜き取ってから実DBを作成するものとする。
△はデータファイルのみの項目で、抜き取って加工してからDB化する。

こうすることで保守性を確保しながら無駄を排除し、停留所名などの二重管理も不要とした。

1 ※事業者番号
2 ※系統ID
3 ※ルート番号 (0からスタートで9までの最大10種類、足りない場合があれば再検討)
4 ※停留所連番 (1からスタートの10進数とする。系統の停留所数が10以上の場合は01、100以上の場合は001のように頭に0を付けて桁数を合わせるとソートしやすい)
5 内部利用のフラグ (未使用では0としておく)
6 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
7 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
8 方向
9 ※リレーション用の停留所番号(バス停DBのキー)
△10 事業者名
△11 路線番号+路線名+系統番号
12 停留所のフラグ(自由乗降などを表わすフラグ類おきば)
△13 停留所名1
△14 停留所名2
△15 停留所名3


●停留所のフラグ(暫定仕様)
臨 = 臨時駅・停留所
自 = 自由乗降区間(CI-CA)
由 = 自由乗降区間(CI-CA以外)


●方向
1ルートを1文字で表現する。

v = 下り線が停車する停留所
^ = 上り線が停車する停留所
| = 通過
* = そもそも経由しない


2ルート程度までまとめて記載可能とすることでデータベースサイズをコンパクトにできないか、暫定的な措置を講じる実験。

往復(2ルート)を1情報としてまとめる場合

v^ = 双方向
v| = 下りのみ停車(上りも経由はする)
|^ = 上りのみ停車(下りも経由はする)
v* = 下りのみ停車(上りは別の道を通る等で経由すらしない)
*^ = 上りのみ停車(下りは別の道を通る等で経由すらしない)

無理そうなら、諦めて往路、復路でデータを分けるものとする。

実際のデータ例


ここではタブコードを ‣ 記号で表わす

奈良交通の21系統を例とする。

系統情報データベース


0E51‣31-21‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣‣‣‣大和町線‣21


ルート情報データベース


0E51‣31-21‣0‣0‣00000000‣99999999‣01234567‣学園前駅(南)‣学園大和町五丁目‣


停留所情報データベース


事業者名、系統名、停留所名は全てメモに過ぎない。変更があれば、この系統DBのメモとしての記載も変更することにはなるが、してもしなくてもデータベースには入らないので影響はない。
0E51‣31-21‣0‣01‣0‣00000000‣99999999‣v^‣033B‣奈良交通|Nara Kotsu‣大和町線21‣‣学園前駅(南)‣‣
0E51‣31-21‣0‣02‣0‣00000000‣99999999‣v^‣0121‣奈良交通|Nara Kotsu‣大和町線21‣‣学園南三丁目‣‣
0E51‣31-21‣0‣03‣0‣00000000‣99999999‣v^‣0123‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町‣(奈良西警察署)‣
0E51‣31-21‣0‣04‣0‣00000000‣99999999‣v^‣0139‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町二丁目‣‣
0E51‣31-21‣0‣05‣0‣00000000‣99999999‣v^‣5F29‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町①)‣
0E51‣31-21‣0‣06‣0‣00000000‣99999999‣v^‣013A‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町三丁目‣‣
0E51‣31-21‣0‣07‣0‣00000000‣99999999‣v^‣5F2A‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町②)‣
0E51‣31-21‣0‣08‣0‣00000000‣99999999‣v^‣013B‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町四丁目‣‣
0E51‣31-21‣0‣09‣0‣00000000‣99999999‣v^‣5F2B‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町③)‣
0E51‣31-21‣0‣10‣0‣00000000‣99999999‣v^‣013C‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町五丁目‣‣


本当の問題と課題


DBが3つに別れてしまいましたが、これを維持管理するのは本当に大変そうです。
本当にこの仕様を維持できるのでしょうか。

2019/05/26(日)02:37 |Comments(0) |Trackback(0)

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

▲ページトップ

磁気式などの電子マネーを管理するアプリの開発

増え続けるお店専用電子マネー対策


ICカード式電子マネーは「全国のICカードこれひとつ」シリーズで管理できます。弊社としてはもっともお勧めの方法です。

しかし、磁気カード式、現在だとスマホを想定したQRコード式の、店舗の独自電子マネーも徐々に普及し始めていると思われます。

理由は色々あると思いますので店舗の思惑がどうかは一概には言えませんが、おつりの小銭を用意するのも最近では銀行手数料がとてつもなく高額になり、そんな無駄金を銀行なんかに払うくらいならお客に還元した方がいい、となって最近ではスーパーマーケットですらクレジットカードや電子マネーに対応するのが日本の現状なのだろうと認識しております。
また、政府の後押しもあり、今後もキャッシュレス化が進むことは疑いようがないでしょう。

ただ、大きな所(ようするに交通系電子マネー)に乗っかることができない事情も店によってはあると思われ、そういった店では「その店(または店グループ)専用電子マネー兼ポイントカード」という、従来の磁気式あるいはバーコード式ポイントカードに電子マネー機能が付いて便利さupという、そういう方向性の電子マネー導入になることもあると思われます。

そういった電子マネー、数が多いと(多くなくとも)「今残高いくらだっけ?」となるのは間違いありません。
ネットから、あるいは専用アプリから残高や履歴確認できるものも多いですが、一つ一つ確認するのは大変なので、もうちょっと何とかならんのか、と思うのが実際の所ではないでしょうか。
つまり、アプリで一覧管理できることが望まれるわけです。

ならば管理するアプリを作ろう


そこで、インターネット経由で残高や履歴確認できるそれら電子マネーを管理するアプリを開発する計画です。

時期については未定ですが、開発初期の無料配布はなく、機能が乏しい最初の時点から有料での販売となり、随時改良版の更新配信を実施してゆきます。
また、月極ではなく、売り切り販売のアプリになることが予定されています。

1年ないし数年ごとに新製品を新発売して年貢を徴収するのが資金調達的には無難ではありますが、売上が良好であれば一度買った人から再徴収せず、価格改定(値上げ)でご新規さんの負担を増やす方向もありかもしれません。予定は未定ですのでどうなるかは今後考えていくことになると思います。

どういった操作性にするのが使いやすいのだろうか


作るのは良いのですが、どういった操作性にするのが良いのでしょうか。
「全国のICカードこれひとつ」も、従来にない新しい操作性で一世を風靡し、ICカードビューアーという既に数多のアプリがある世界に新風を巻き起こしましたが、電子マネー管理アプリなどというものは既存品は存在せず、完成すれば弊社製品が恐らく初になると思われます。

参考にするものがない中で操作性を考える必要がありますが、ICカードこれひとつと同様にタブ式の操作にすることは既に決まっています。

一覧と選択した電子マネーの詳細の切り替え


初期画面は登録したアプリの電子マネー額一覧にするのが良いと思うのですが、それをタップすると右側にタブが追加されるような感じが良いのでしょうか。
他の電子マネーを選択したらそれらタブは一旦全部消えて、選択した電子マネーのタブのみが追加される方がいいのか、前のタブは残る方がいいのかで設計が大きく変わりますが、前のを残すと色々と無理が出そうではあります。

電子マネー名と確認した最終残高の一覧表示は間違いなくするとして、それをタブ1枚で初期画面にするのが良いのでしょうか。

操作性アイディアとして良さそうと思っているのは、アプリを起動すると強制的にドロワーメニューが左から出てきて、そこに一覧表示しておき、詳細確認したい電子マネーをタップ(選択)するとネットアクセスして最新状態をゲットしてタブ表示する方式、というものがあります。

タブも、履歴タブ1枚で済むものもあれば、Webでは月ごとにページが切り替わるもの(PiTaPaなど)もあるのでこういったものは月ごとにタブを分けた方が間違いがないと思いますし、履歴以外にも残高の有効期限などの情報を表示するタブは別途必要でしょう。

無理なく、すっきりした画面表示にするためには、複数の電子マネーのタブを混在させることはせず、常に選択した電子マネーに限ったタブのみ表示する方が恐らく良いのでしょう。

想定する対応電子マネー


ネットから残高および履歴等が確認可能な電子マネー、ポイントカード類すべて。

ただカード自体を入手しないとネットから見られないことが多いと思われるので、その入手が困難なものは、なかなか対応できないことも想定されます。

現時点で、対応できそうなものを以下に書いておきますが、関西系以外は入手困難なため、すぐの対応は難しいと思われます。
また、これ以外にも要望あり次第、全てに対応していく計画です。

・CoCGa (CGCグループ)
・litta (イズミヤ、阪急グループ)
・PiTaPa
・SMART ICOCA
・majica(ドン・キホーテ)
・uniko(ユニコ) (旧ユニー系)
・LaCuCa (ライフ)
・ほぺたんカード (コープみらい、東京・埼玉・千葉)
・吉野家プリカ (吉野家)

そのほか、以下もネットで確認できるらしいという情報を得ています。
・記名式SUGOCA
・VISAやMasterプリペイド/デビット


ご意見やご要望などは随時募集しておりますので、お気軽にコメント等でお寄せください。マストドンでも随時ご意見への対応や現状報告を実施しております。

2019/05/21(火)19:36 |Comments(0) |Trackback(0)

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

▲ページトップ

カレンダー

07 | 2019/08 | 09
- - - - 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