Windows 10 Mobile で spmode に接続する
IIJmio の契約を docomo に変更した記事を書きましたが
ayano.hateblo.jp
さてでは SIM フリー端末、特に Windows 10 Mobile ではどのようにインターネットに接続すれば良いかというところについて。
docomo で公式に書かれていますが、spmode での接続先 (APN) は
spmode.ne.jp
です。APN 設定するだけで後は何も記載しなくて OK
www.nttdocomo.co.jp
Windows 10 Mobile なら、端末によってはプロファイラーが用意されていることもありますが、手動で設定する場合は APN 設定で以下の通りにすれば OK です。
[IP の種類] を「IPv4v6」にしてますが、spmode でも IPv6 接続ができるので、この設定でよいかと思います。
簡単ですね！
Windows 10 Mobile でも spmode に接続できて、普通に使えるって、素敵ですね…。なんで流行らなかったんだろう…。
ちなみに「My Docomo」の各種設定手続きにかかわるログインも、キャリア端末と同様にネットワーク暗証番号でできました。
ぼくがまだ Windows 10 Mobile を使い続けている理由
この記事は、Windows 10 Mobile Advent Calendar 2017 の 1 日目の記事です
adventar.org
今年は残念ながら、Windows 10 Mobile の悪いニュースが明らかになるなどもあり、ネガティブ思考になりがちで、ポジティブなことも書きづらい形での Advent Calendar となりました。
とはいえ直ちに使えなくなるわけでもないので、使えなくなるまでは使い続けようと思っています。
Windows 10 Mobile を使い続けている理由
Windows PC と Mobile の組み合わせは、Microsoft が Android / iOS にモバイル分野をシフトしても変わらず強いものと感じる部分はあります。
例えば「アプリ設定のローミング」。UWP アプリは設定を Microsoft アカウントに紐づけて、ほかのデバイスでも同じ設定で使えるようにするという仕組みがありますが、これは当然 Mobile でも使えます。この点は現時点で最強のメリットだと感じています。Mobile がなくなった後は、UWP は PC と Xbox, HoloLens でしか動かないものになるため、設定のローミングは薄くなってしまうなぁとちょっと寂しいです。
これに関連して、ストアで購入したアプリは Xbox, HoloLens も含め、Mobile も PC もアプリが利用可能であれば、どのデバイスでも購入情報が共有されるので、PC と Mobile でそれぞれアプリを買わなくてもいいという利点がありました。
まだまだ使うために アプリの紹介
Slack
www.microsoft.com
ご存じコミュニケーションツール Slack のクライアントです。月に 1 回アップデートが入っていて、しっかりメンテされている雰囲気もあります。
日本語表示はもちろんのこと、メッセージを見る、スレッドを見る、ファイルを送信するなどの基本的な機能は問題なくできていますが、ファイルのコメントは見ることができず、誰がリアクションしたのかも見ることができないなどの機能制限はあります。BOT からのメッセージについて、設定している情報が反映されていない箇所があったり、日本語化されたことによって、フォントが NotoSans の常用漢字レベルまで引き抜いた版が使われるようになり、割り当てのない漢字が Yu Gothic UI に代用されるため、混ざると非常に不自然な表示になるなどがあり、この辺はぜひとも改善してほしいところ。
ライブカレンダー
www.microsoft.com
スタート画面のタイルにカレンダーを表示してくれるアプリです。WP7 のころからある老舗アプリです。
ワイドタイルにしておけば、端末で持っているカレンダー情報も表示してくれるので、なかなか便利です。
Analog Clock Tile
www.microsoft.com
スタート画面のタイルにアナログ時計を表示してくれるアプリです。
様々なスキンが用意されているため、好きなのをいつでも切り替えて表示できます。
fitbit
www.microsoft.com
活動計アプリの定番アプリ。Windows 10 Mobile 版もちゃんとあります。
できることはたくさんあり、fitbit デバイスとの接続ももちろん、ソーシャル機能も問題なく使えます。
タイルでも歩数をはじめとして、様々な情報が表示されるのがとても便利。
sanka
www.microsoft.com
2 5 ちゃんねるビューアーです。
API 対応のため安心して使える点、先述の設定ローミングによって、Mobile で見たりお気に入りに入れたスレを PC でもそのまま見ることができるので、rep2 のような Web で動くマルチプラットフォームビューアーと同じ使い勝手なのが魅力。
Mobile だとアプリとは別に 5 ちゃんねるにお金を払っていないと、画面にでかでかと広告が鎮座するので、そこは割り切って広告と付き合うか、5 ちゃんねるにお金を払うなどで広告を消すなどする必要はあります。
見たレスの位置、お気に入りスレの情報はローミングしてくれますが、NG ワードなどの設定はどうやらローミングしてくれないようなので、そこだけ改善されるといいなぁと思っています。
そんなわけで
Mobile もまだ頑張れるぞっていうことを伝えたかったんですが、どうでしたでしょうか。
12 月 2 日は id:kazuakix かずあきさんです。
僕が考える、Windows 10 Mobile からの移動先について
今朝書いた記事が思いのほか伸びてて、割と恐縮というか、「ああなんか、終わりに郷愁を抱く日本人らしい反応だな…」とか思いつつ見ているわけですが
ayano.hateblo.jp
じゃあ僕が思う、Windows 10 Mobile が正式にサポートを終了した後、どのプラットフォームに移るといいのか？というところをちらちらと書いてみます。
同じ操作感を求めるなら Android 系を選ぶべし
もはや僕自身の中での答えはこっちです。W10M ユーザーに相談されたら間違いなく Android 系がオススメと答えます。
実は Windows 10 Mobile の操作感はほぼ Android 系のそれと似ています。
W10M でいうアクションセンターは Android も同等に画面上から下へスライドすればよく、その先の通知の一覧はもちろんのこと、各種センサー類・ネットワークを操作するクイックアクションも Android でもほぼ同じフィーリングで操作ができます。
また、カーブフリックに慣れてる方にとっては、他のフリック入力が煩雑でつらいなどあると思いますが、つい先日「アルテ on Mozc」が『カーブフリック準拠』のキーボードを搭載してリリースされました。
play.google.com
所々で本場カーブフリックとは違う挙動、例えば、左下フリックで「あ段」の確定はできず、英字入力は「先に大文字小文字切り替えをしてから文字を入力」ではなく「文字を入力してから大文字小文字を切り替える」などがありますが、それ以外については変わりはありません。
ちょっと挙動が違うと言えば、タスク切り替えは Android 端末によって変わりますが、専用のナビゲーションボタンが存在します。それをタップすることで切替ビューに遷移します。
前によく言われたのは「Android はマルウェアに弱い」ことでしたが、最近は割とどうにかなっているようで、怪しそうなアプリを入れないなどすればどうってこともなく、変な"セキュリティソフト"を入る必要もないように感じてます。
僕自身も W10M と Android の二台持ちで運用しています。あまり頭でプラットフォームが違うことを意識せず使えているので、かなりストレスフリーな感じはあります。
Microsoft の中の人が Windows 10 Mobile の事実上の終了を宣言した話
ついにこのときがきてしまったのか っていう気持ちですが…
windowscentral.com
www.onmsft.com
Windows Phone ではイケメンぶりを発揮してた Joe Belfiore さんが、自身の Twitter で明らかにしたことで、
「Windows 10 Mobile はバグ修正、セキュリティパッチなどのメンテナンスはするが、新機能などはもうしない。個人利用者は iOS 端末や Android 端末に切り替えてほしい。 個人的には、Windows 10 Mobile 端末から別の端末に切り替えた。 (太字部分は 10 月 10 日更新)」
という、事実上の「終了宣言」「敗北宣言」が出てしまいました。
これで、 PDA から始まる Windows CE, Windows Mobile, Windows Phone といった、パームトップ・電話としての Windows の系譜がここで途絶えてしまうことに。
iPhone や Android が出た当初、それまで Microsoft の独壇場だった PDA 市場にあぐらをかいていたあの頃から、もう運命は決まっていたのかもしれません…。
あれよあれよと追い抜かれていき、iPhone は日本では圧倒的なシェアを誇り、Android は出た当初と大きく変わってかなり快適な操作性を得るまでに至りました。
僕個人としては、もうちょっと Windows 10 Mobile と遊んでいたい気持ち。
Windows on ARM の状況も気になりますしね。「電話としての Windows」が復活するのか、それとも…。
2017/10/10 追記
割と反響ありすぎて心が痛いんですが…。
電話としての Windows は今後新機能開発に注力しないというだけで、今すぐ終わるわけでもないということは付け加えておきます。
今後も僕は Windows 向けアプリ開発は続けていきますし、UWP から手を放すつもりはないです。なんだかんだで作りやすいプラットフォームですからね。
あやふやだった方向性が、Joe 氏によって明確化されたことで、今後のアプリ開発をどうしていくかは割とわかってきた気がしてます。
同日追記・修正
つらいのでまだ書きます。
Joe 氏がこのタイミングでアナウンスした真意はわかりません。Windows on ARM あるいは Windows Core OS が今後控えているから、Win32 系アプリを実行できない Mobile はフェードアウトさせたいのか、そもそも電話としての Windows からガツっと撤退するなのか、今後の状況を見ないことにはわかりかねる話かと思います。
今更ですが誤訳に気づいたので修正しておきます。"As an individual end-user," の前置きを無視してたので思いっきり違う意味にとらえていました。お詫びして修正します。
(2/2) As an individual end-user, I switched platforms for the app/hw diversity. We will support those users too! Choose what's best 4 u. https://t.co/LKQBL3w7gA
— Joe Belfiore (@joebelfiore) 2017年10月8日
Windows 10 Mobile の未来とは
おことわり: すべて憶測に基づく雑な記事です。参考にしたものはなく、僕が普段 Windows 10 Mobile 端末を使っていて思ったことなどから導き出した話です。ただのたわごと・ポエムだと思って雑に見てください。
土曜日はさわやかに、日曜日は Foursquare Meetup に参加していて気付いてませんでしたが、土曜日に新しい Insider Preview が発表されてから、W10M クラスタがちょっとだけｻﾞﾜｻﾞﾜしてるのを月曜に知りました。
例えばおでさんが記事にするくらいに気にされてるところが、今後の Insider Preview 対応の端末についてです。
・ HP Elite x3 ・ Microsoft Lumia 550 ・ Microsoft Lumia 640/640XL ・ Microsoft Lumia 650 ・ Microsoft Lumia 950/950 XL ・ Alcatel IDOL 4S ・ Alcatel OneTouch Fierce XL ・ SoftBank 503LV ・ VAIO Phone Biz ・ MouseComputer MADOSMA Q601 ・ Trinity NuAns NEO
日本で発売されている、ドスパラの Diginnos Mobile DG-W10M や、ヤマダ電機の EveryPhone に、FREETEL の…なんでしたっけ。といった、2016 年に相次いで登場した電話たちは非対応となりました。
Creators Updateの配信端末は限定されるようですod10z.wordpress.com
また、pnp0a03 さんが Windows 10 Mobile に対して悲観的な記事を書いています。
これらを勘案して、僕が思う Windows 10 Mobile の未来を考えてみます。
Windows 10 Mobile は Windows 10 ARM 版に統合される
…というのは、Windows まわりを追っている人にとってはわかりきった未来かなと思うところです。2016 年 12 月には正式に ARM 版の Windows 10 OS が発表になっています。
ARM 版 Windows 10 は、Windows 8 のころ登場した Windows RT ができなかった、ARM で x86 のアプリ (特に Win32 アプリ) が動作するとあって、「真の Windows スマートフォンになるのでは」と期待を込めた記事もありました。
この点から、ARM 版の Windows 10 に Windows 10 Mobile は統合されるものだと強く思っています。ARM の上で Win32 アプリが動作できるようになると、今後 Win32 アプリが動かない Windows OS すなわち Windows 10 Mobile はただただ不利なだけのものになってしまいます。
これで、電話もできて、これまでの Win32 アプリも動く、今までになかった新しい価値のスマートフォンとして今後展開されていくものだと思っています。
ただひとつ懸念もあります。
Windows 10 を搭載したスマートフォンは日本で登場しなくなるのではないか
ARM 版 Windows 10 が出ることにより、Atom 搭載で動いていた Windows タブレットが ARM 版 OS に切り替わっていく可能性もあります。最初はタブレット、スマートフォン両方が出るかもしれませんが、スマートフォン上で Win32 アプリを動かすのが難しいまたは Continuum でないとダメなどの制約があると、徐々にタブレットにシフトし、スマートフォンは発売されなくなるという未来も考えられます。
この点をおでさんはかなり気にしているような気がします。
僕はそんなことはないみたいです。この間GPDの実機見せてもらったときも、食指は動きませんでしたし。なのでもし、ARM on WindowsがW10Mを食らうならそのときは
— 沼に潜むＯＤ－１０Ｚ ／ 3ΦΦ (@od_10z) 2017年2月17日
ARM on Windows 10を素直に喜べない僕がいる……。この先W10Mはどうなるのか。期待と不安が入り混じった感じで、テンションが凄く微妙。
— 沼に潜むＯＤ－１０Ｚ ／ 3ΦΦ (@od_10z) 2016年12月8日
僕も気にしてます。
この点は、今後の UWP の普及次第かなというところもあります。
UWP であれば、スマートフォン版・PC 版など分け隔てなく、その端末の画面サイズに応じた UI を、ひとつのバイナリで提供できますし開発者にとっては UI にさえ注意すれば開発は容易なはずです*1。したがって、UWP で作られたアプリが普及すれば、普段は UWP アプリで事を済ませ、どうしてもだめなときは Continuum などで接続し Win32 アプリを立ち上げる…といった流れになったりで、ポケットサイズの端末の優位性は格段に上がります。
ただ現状を考えると、Win32 アプリの優位な状況は変わらず、このままなら上記のような未来は避けられないかな…なんて思ったりしています。
この辺は米国 Microsoft もそうですが、MSKK仕事しろといった感じ。UWP での開発のしやすさ向上、UWP の安定性向上と、UWP を開発するメリットをもっと高めてほしいです。
*1:実際僕自身が開発してるときも、UI だけ気にすれば簡単に実装出来ました
Bluetooth で OBD2 と接続して Mikaboshi で表示したい
この記事は、Windows 10 Mobile / Windows Phone Advent Calendar 2016 の 3 日目の記事です
www.adventar.org
先日の記事で、開発・公開している Windows 10 アプリ「Mikaboshi (みかぼし)」について書きましたが、きょうは今後予定している機能のうちのひとつを、開発手法とあわせて紹介します。
Mikaboshi のダウンロードはこちらからどうぞ
www.microsoft.com
Mikaboshi は、主に車載向け (自動車・バイク・自転車など) を想定して作っていますが、GPS の情報に頼る性質上、例えば高い建物の間を移動していたり、トンネル内を移動していたりしたときは地図の更新も、推定移動速度も更新されなくなります。そんな中でも、移動速度だけは更新させたいという気持ちから、OBD2 を使った移動速度の検知を試してみました。
OBD2 とは、いわゆる「自動車の自己診断機能」のことで、本来は自動車の故障個所などを検知する目的で使われるもののようですが、その情報の中には移動速度なども含まれており、また車からの情報なので即時性・正確性が高く、これを利用したアプリや車載機器*1が多くあります。
実装するにあたり、電話で使うので Bluetooth 接続できた方がありがたいですよね。Bluetooth 接続できる OBD2 アダプターデバイスは結構多く存在します。適当に Amazon でポチポチしてもいいと思いますが、なぜか当たりはずれの大きいものばかりなので、既に Windows Phone 向けにも OBD2 を使った情報収集できるアプリ「OBD Info-san!」を開発した がんち さんが紹介している OBD II マルチメーター M-OBD-V01 が割と安定して使えるかなと思います。ほかのやつと比べるとちょっと高いですけどね。
- 出版社/メーカー: MAXWIN(マックスウィン)
- 発売日: 2016/02/29
- メディア: Automotive
- この商品を含むブログを見る
Mikaboshi で OBD2 検知機能を実装するにあたり、がんちさんのアプリには大変お世話になりました。
Bluetooth デバイスを見つけて接続する
まず Bluetooth 接続を実装する前に、Package.appxmanifest で Bluetooth を使うように宣言します。
開いて、「機能」タブから「Bluetooth」にチェックを入れてください。これでアプリで Bluetooth が使えるようになります。
次に、使える Bluetooth デバイスを列挙します。何が OBD2 アダプターなのかわかりませんからね。
使えるデバイスの一覧を拾うには、 Windows.Devices.Enumeration.DeviceInformation が使えます。
こんな感じ。
using Windows.Devices.Bluetooth.Rfcomm; using Windows.Devices.Enumeration; public async Task<DeviceInformationCollection> GetAvailableDevicesAsync() { var services = await DeviceInformation.FindAllAsync(RfcommDeviceService.GetDeviceSelector(RfcommServiceId.SerialPort)); return services; }
OBD2 アダプターがシリアルポートとして動くので、シリアルポートとして動くデバイスを探して列挙しておきます。
次に接続します。さきほど見つかったデバイスのうち、OBD2 アダプターデバイスを見つけておいてください*2。見つけたデバイスの DeviceInformation のインスタンスを保持しておきます。
そして接続します。こんな感じ。
using Windows.Devices.Bluetooth.Rfcomm; using Windows.Devices.Enumeration; using Windows.Networking.Sockets; using Windows.Storage.Streams; private StreamSocket socket; private DataWriter writer; public async Task ConnectAsync(DeviceInformation device) { var service = await RfcommDeviceService.FromIdAsync(device.Id); this.socket = new StreamSocket(); await this.socket.ConnectAsync( service.ConnectionHostName, service.ConnectionServiceName, SocketProtectionLevel.BluetoothEncryptionAllowNullAuthentication); this.writer = new DataWriter(this.socket.OutputStream); }
StreamSocket.ConnectAsync() したとき、はじめての場合システムから許可を求められます。許可することで接続が確立します。2 回目以降は特にいわれませんので、ConnectAsync() してすぐに接続が確立します。
Bluetooth デバイスとデータを送受信する (準備)
OBD2 アダプターデバイスは、データの送信と受信を一対一でおこないます。クライアントはデータを送信したら、OBD2 から受信を待機して、受け取った情報を解析するような流れをとります。
ですので、送信した後すぐ待機するようなコードを組むようにします。
using System.IO; using Windows.Devices.Bluetooth.Rfcomm; using Windows.Devices.Enumeration; using Windows.Networking.Sockets; using Windows.Storage.Streams; // これらに、すでにインスタンスが上記コードを使って入ってるものとします private StreamSocket socket; private DataWriter writer; public async Task SendCommandAsync(string message) { // OBD2 のコマンド終端は \r var bytes = Encoding.ASCII.GetBytes(message + '\r'); this.writer.WriteBytes(bytes); // OBD2 へここでデータを投げる var result = await this.writer.StoreAsync(); if (result == bytes.Length) { // たぶん成功してる await AnalyzeAsync(); } } private async Task AnalyzeAsync() { var stream = this.socket.InputStream.AsStreamForRead(); var result = new List<byte>(); while (true) { var b = stream.ReadByte(); if (b <= 0) continue; result.Add((byte)b); // > がきたら応答が終わったとみなす if ((char)b == '>') break; } // 以下省略、続きは次で }
こんな感じ。これで形はできました。
OBD2 のインターフェースである ELM327 がプロンプト形式でやりとりするので、「>」はユーザーからの入力待ちモードになってるって感じです。ユーザーからコマンドと「\r」をもらったら、それに応じて情報を返して、「>」で終わるという具合。
なので、「>」がきたらデバイスからの応答は終わったとみなしてOKでしょう。
Bluetooth デバイスとデータを送受信する (送信と解析)
実際に送信してみましょう。
コマンドについては ELM327 のデータシートも参考にしながら。
https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf
まずリセットコマンドを送信しておきます。
リセットコマンドは次の 3 つです。
at z at l0 at e0
z は初期化コマンド、e0 はコマンドのエコーをするかどうか (これでエコーしないようになります)、l0 はラインフィードを追加するか (これで追加しないようになります) を設定します。
OBD2 へ送信するコマンドはいろいろあります。先ほどのデータシートにもありますが、英語版 Wikipedia にも一覧が載っています。
速度情報は Mode 01 に書かれているので、コマンドはこんな感じ。
01 0D
これを送信することで、応答に速度情報が返ってきます。
これらを先ほどのコードで実装した SendCommandAsync() に投げます。
そしてこれらの応答を解析するコードを実装します。
// 上記コードからの続き public int Speed { get; private set; } private async Task AnalyzeAsync() { var result = new List<byte>(); // 省略 result = /* OBD2 応答 */; // 応答をバイト配列から文字列にしておく var buffer = result.Where(w => w > 0).Select(s => (char)s).ToArray(); var resultStr = new string(buffer); // 文字列にした応答を、半角スペースと改行で配列に分ける var data = resultStr.Split(new[] { ' ', '\r' }, StringSplitOptions.RemoveEmptyEntries).ToArray(); // 初期化処理以外で 41 で始まるデータが返ってこなければ、それは失敗してる if (data[0] != "41") return; switch (data[1]) { case "0D": // 速度情報 break; default: return; } } private AnalyzeVehicleSpeed(string[] data) { // 使うデータは 3 バイト目 var speedData = data[2]; var speedValue = 0; int.TryParse(speedData, NumberStyles.AllowHexSpecifier, CultureInfo.CurrentUICulture, out speedValue); this.Speed = speedValue; }
こんな感じ。
初期化コマンドの応答については処理について特に書いてませんが、ちゃんと返ってきます。
> at z ELM327 v1.5 > at l0 OK > at e0 >
特に処理する必要もないですが、初期化してから各種コマンドを投げた方がいいです。初期化については「41」で始まる応答を返しませんが、エラー扱いにすると危ないので気を付けた方がいいです。
そして、送信した速度情報のコマンドの応答は
41 0D 28
となっています。成功を示す「41」と、速度情報に応答したと示す「0D」のあとに続く「28」を解析してやればOK。単に 16 進数ですので、数字に変換してやれば速度情報になります。
つまり、OBD2 で得られる速度情報は、0 ～ 255 km/h までということですね。
速度情報はたいていの車で返してもらえると思いますが、車によっては返してもらえなかったり、返す値が微妙に違う (同じ応答を 2 つ返すなど) するらしいので、その辺の情報がちょっとほしいなあと思ったりはしています。
また、ほかのコマンドを叩けば、その情報も得ることができますし、先述の Wikipedia の記事にはフォーマットもありますので、割と楽に取れるかと思います。
取得する車が何のコマンドが使えるかは、「OBD Info-san!」を使うと一覧化してくれます。試用版でもできるので、拾いたい情報をそこから探すという手もあります。
…というのを、Mikaboshi で実装していて、現在テスト中です。速度情報のほかにエンジン回転数も表示できるようにする予定でいます。
実際使ってみるとかなり楽しいというか、目指してたものが実現できたので割と満足しています。
割と古い開発中のころのスクリーンショットですが、こんな感じ。
少し気になるのが、OBD2 アダプターデバイスの個体差があるのかもしれませんが、OBD2 から得られる情報の更新頻度が急に落ちたり、応答がなくなったりすることがときたま起きます。
再接続したり、アダプターデバイスの電源を入れなおしたり、コマンド送信から受信までタイムアウト時間を設けて、一定時間返ってこなければ自動再接続したりするなど対策はしていますが、更新頻度の低下はうまく検知できてない状態です。
このあたりうまくやれる方法があれば教えていただけると助かります…。
また、まだテストしてる車が、家のホンダ フィット (GP6) しかなく、ほかの車でも動かせるかどうかを確認したいところです。
準備ができ次第リリースするので、協力いただける方がいればよろしくお願いします。
寄付をお願いします
1 日目に引き続いて恐縮ですが、アプリの「？」をタップして表示される「バージョン情報」に「作者に寄付する」ボタンがあります。実際に使ってみて、よければ寄付ください。アプリ内課金を利用しています。寄付額は選べませんが、寄付いただければ例えば Xamarin 使ったマルチプラットフォーム対応とかやる気が起きます。お願いします。
Advent Calendar でした
4 日目は od_10z さんです。誰もが息をのむような、すごい記事に期待しています。
twitter.com
Windows 10 アプリ「Mikaboshi (みかぼし)」の紹介
この記事は、Windows 10 Mobile / Windows Phone Advent Calendar 2016 の 1 日目の記事です
www.adventar.org
先日リリースしたアプリを、このブログで紹介してなかったので、Advent Calendar のネタとして投下します。
10 月 10 日に「Mikaboshi (みかぼし)」ってアプリを、Windows 10 PC / Mobile (主に Mobile 向け) でリリースしました。いわゆる位置情報を可視化するアプリです。
Windows 10 PC / Mobile 対応 位置情報表示・共有アプリ「Mikaboshi」をリリースしました。試しに買った電話が眠ってるあなたも現役なあなたも、車に自転車にバイクに装着してみませんか #wpjp サイトは→ https://t.co/jS0A1jqhqP
— 綾野ちい✨アヤノフ (@ChiiAyano) October 10, 2016
主に自動車、バイク、自転車などにくくりつけて使うような想定で作ってますので、例えば Windows 10 Mobile デバイスだと GPS もついてるので使い勝手がいいかと思います。
やってることは簡単で、GPS などの位置情報センサーを使って、現在の位置を地図に出したり、GPS から割り出される航行速度を表示したり、移動距離ごとに住所を割り出して表示したりなどしています。割り出した住所と前に取得した住所を比較して、都道府県や市区町村が変化するようなときは、それを読み上げてくれる機能もあります。
上記ウェブサイトで載せてるような機能紹介をただ繰り返すだけじゃ面白くないので、紹介してない機能とか、表面的にしか紹介してない機能とかの深掘りしておきます。
住所読み上げ機能は、音声合成の性質上、漢字の読みなどを間違えることが多いです。そこで、Mikaboshi では「都道府県」と「政令指定都市の市と区」は漢字読み、それ以外はすべてひらがな読みにすることで、間違いを極力減らせるようにしました。それでも、政令指定都市でも漢字読みに失敗する例*1もあったり、また逆にひらがなだと「は・へ」の読み替えがうまくいかない例*2*3などがあるので、一度通った住所を端末で記録しておいて、あとから読み方を変えられるようにしました。
設定画面に [住所アナウンス設定] があるので、そこをタップ/クリックすると、これまで通った住所が一覧ででてきますので、読み方を変えたい項目を右か左にスワイプすることで、読み方を切り替えることができます。PC で変更する場合は右クリックで変更ができます。項目をタップ/クリックするとプレビュー再生するので、読み方が正しいかどうかも確認できます。
漢字読み/ひらがな読みで同じ読み方になる場合でも、読み上げのイントネーションに変化があったりするので、どっちがいいか選ぶことができます。ちょっと面白いです。音声合成の特性上、やっぱりたどたどしさというか、変な感じになるのは仕方ないです。Cortana さんの音声合成使わせてください。
何回かのバージョンアップで、地図表示のスタイルを少し更新しました。「マップモード」ができました。現在地の日の出・日没時刻を見て、日の出を過ぎると明るく、日没を過ぎると暗くなります。設定で抑止することもできます。が、現在バグで「日の出・日没をまたいでもしばらく地図が切り替わらない*4」問題がありますが、次リリースするバージョンで解決します。ごめんなさい。
Mikaboshi は、位置情報を共有するサービス Locapos (ろけぽす) にも対応しています。というか、 id:tmyt にお願いして作ってもらいました。
当初、 今ココなう！(β) を使って同じようなアプリを書いてリリースしてたことはあります*5が、サービスが事実上停止状態になり、新たなサービスを立ち上げる必要が出てきたわけです。
Mikaboshi を使ってできる Locapos の機能は、
- 現在位置を送信する
- 誰かの現在位置を地図表示上にプロットする (現時点では相手の名前は見えません)
の 2 点です。別端末で Locapos のポータルサイトを開いておくというスタイルを想定しています*6。
今後やりたいこと
マルチプラットフォーム対応はぜひやりたいところです。Xamarin か…。厳しい闘いになりそうだ…。だれか教えてください。
他にもいくつかやりたいことがありますが、それは 3 日目の Advent Calendar に書きます。
寄付をお願いします
アプリの「？」をタップして表示される「バージョン情報」に「作者に寄付する」ボタンがあります。実際に使ってみて、よければ寄付ください。アプリ内課金を利用しています。寄付額は選べませんが、寄付いただければ例えば上記の Xamarin 使ったマルチプラットフォーム対応とかやる気が起きます。お願いします。
Advent Calendar でした
2 日目は ipponshimeji さんです。
