Weather Typing 3.0開発,とりあえずQwertyのシングルモードは打てるようになった。スマートフォン版をWindowsで使えるようになった感じ。ウィンドウを拡大縮小できるし,文字の拡大縮小もできる。
というところで設定とか対戦の実装を始めるのだが,出張でしばらく空いてしまいそうなので,その間にデザインを考えている。タイトル画面はこんな感じか? アイコン適当だけど。
C#版Weather Typingを作る上でどうしても性能が出ない部分がある。キーボード入力部分と打鍵音再生。キーボード入力はWindows Messageでもいいけど,どうしても遅延が発生するのと,ツール対策上もっと低レイヤーが望ましい。打鍵音再生は普通に再生すると音飛びが発生しまくるし複数音同時再生ができない。
ということでC#でゲームを作るときに今は何を使うのか調べてみたところ,予想以上に混沌としていた。まず現行のWeather Typingで使っているDirectXをC#から使うManaged DirectXだが,.NET 4.0以降では使えない。そしてDirectXの後継XNAだが,別途ランタイムが必要で,既に廃止が決まっている。その後は・・・あれ,何もないのか。どうすればいいのさ。
てことでもうC#からP/InvokeでDirectXを呼び出しちゃうことにした。
最近The Gamification Revolutionという本を読んでいる。いろんなことにゲーム的な要素を取り入れることでモチベーションを高められるというもの。Twitterなんか,フォローア数とか,最近一般に使えるようになったTwitter AnalyticsのImpressionsとか,あからさまにゲーム性を出してる感がある。こういうのをフリーソフト作りのヒントにしたい。
Weather Typingはランキング,ロビーや大会などでライバルに勝つというのがモチベーションにつながるのは分かるけど,それ以上何かないかな。TOD2は成績評価してたり,タイプウェルはアチーブメント的なのを導入してるのか。打鍵数とか練習時間が記録されるとか,全配列で一定の点数を出すと何か嬉しいことがあるとか,パッと思いつくのはそんなところかな。
Analog Book Readerも開発中から何かゲーム要素を付けたいとは思っていて,読書時間を記録するようにしたんだけど,もっと積極的に読書を面白くする方法はないだろうか。本を配布しているサイトを運営しているなら,やりようはありそうなんだけどなあ。
Windows 7問題が解決したところで新しいWeather Typingを少し考えてみる。まずは今までの要望を整理。サミットで頂いた要望も追加しておいた。
Analog Book Readerは一般向けに作ったので機能をできるだけシンプルにしたけど,Weather Typingはコアなユーザ向けなので多少複雑でも機能性とカスタマイズ性を重視するのが基本路線。といっても今のままのUIでは使いづらいのでUIは考えないといけない。
少し前からiOS/Android版をWindowsに逆移植し始めていて,C#+WPFではシングルプレイはある程度できた。ここにiOS/Android版では付けなかった対戦機能とカスタマイズ機能を付けると基本は完成するはず。
それにしてもC#+WPFの開発効率はすごい。今までJava/Objective Cで作っていたUIをXAMLに移植するとコードが数分の1くらいになるイメージ。今までコードで表示していたユーザ情報やランキング情報も,Binding使えばほぼ何も書かなくていい。画面回転でレイアウトを変えていた部分もかなりめんどうなコードだったが,XAMLなら何もしなくても可変サイズに対応できる。ここまで楽ならより凝ったUIにするのも考える余裕が出る。
Weather Typing 2.2.3を公開しました。といってもWindows 7のフリーズを直しただけなので,今困っていない方はアップデート不要です。なお,Windows XPはサポート対象からは外しましたが,テストはしているので動かしてOKです。
前回原因は書いたので,解決策を書いておく。結局IMEとDirectPlayの初期化の競合は避けられず,IMEはウィンドウが作成されたときに自動でロードされてしまうので,DirectPlayの初期化をウィンドウが作成される前にやることにした。理論上はこれで競合する可能性はなくなったはず。
5年ぶりにバージョンアップしたけど,当時のビルド環境を揃えるのが大変だった。今のVisual Studio 2013でビルドしてもいいけど,XP SP2で動かなくなるし,新しい環境でのテストもしていないので,Visual Studio 2008を新たにインストールしたり,XPやVistaのテスト環境を作ったり,ついでにダイアログのバージョンとかReadmeとかマニュアルとか,結構めんどう。早いところC#版に移行しよう。
というわけで,協力して頂いた皆様ありがとうございました。
サミットに参加して一番言われたのがWindows 7で動かないという話。その中で調査に協力してくれるという方もいて,早速調査したところ,直接の原因は判明。Weather Typingの中で暫定対策したものを置いてみた。今までWindows 7で動かなかった方で,これでも動かない方がいたら教えて欲しい。
調査依頼は,Weather Typingがフリーズしたときのダンプファイルを取って送ってもらうというもの。掲示板だと相手の技術レベルが分からないのと,ダンプファイルが100MBとかになって送ってもらう手段がなかったのでなかなか依頼できなかった。今回は直接困っている方に会って見せて頂いたことで,多少複雑な操作でもやってもらえそうだったのと,WordPressを導入したことでアップロード手段も確保できたことで依頼ができた。
原因だが,WeatherTyping側はDirectPlayの初期化(CoCreateInstance CLSID_DirectPlay8Peer
)で、dpnet.dll
のLoadLibrary
中、cryptsp.dll!_CryptAcquireContextW
で止まっていた。
さらに他のスレッドを見ると、IME14\IMJPAPI.DLL
で、rsaenh.dll
のLoadLibrary
中、cryptsp.dll!_CryptAcquireContextW
で止まっていた。
両方とも最終的には_ZwWaitForSingleObject
で止まっていたので、典型的なデッドロック。
IME14はOffice 2010のIME。てことでOffice 2010のIMEを入れていて、デフォルトにした状態でWeather Typingを起動するとDirectPlayと初期化が競合してフリーズする。
どうやって解決しようか。とりあえず暫定版ではDirectPlayの初期化を遅らせただけなんだが、それでは根本的解決ではないのでいい方法を考え中。
第6回タイピングサミット,二日目に参加してきました。Weather Typing作者として貴重な時間になったのはもちろん,個人としても楽しい時間を過ごせました。参加者の皆さん,運営の皆さん,ありがとうございました。
タイピングサミットは,タイピングが好きな人の集まりで,ルーツをたどっていくとかなり歴史があるオフ会。今までオフ会は作者が目立ちすぎるのもよくないと思って出てなかったのだが,今回は主催者のPocariさんから,ユーザと作者の交流もテーマとのことを伺って,参加することにした。当日まで秘密にしましょうということにしたため,日記に書くのを我慢していたが,ようやく書ける。
オフ会自体が初めてだったのだが,参加者のうち結構な人はTODエキスパートだったり,初期からのウェザタイユーザだったり,最近だとタイピング本で知った方だったりで,しかも相手も相手で私のことを知っているという,不思議な感覚だった。作者ということで優遇されすぎ感も多少あったが,そこは利用させてもらって,いろんな方に話をさせて頂いた。
イベントとしては「WeatherTyping(団体戦)」とその後の「作者を囲む会」に参加して力尽きつつ,その後のTOD団体戦と懇親会まで過ごさせてもらった。
ここは私が書かなくてもよさそうかな。「チーム開発者」の下っ端として参加したが,最近練習してないのがたたって歯が立たず。0点じゃなくてよかった。チートコードを実装,じゃなくてもっと練習しておくべきだった。
団体戦ルールは,全員をレベル順に並べてチームに割り振り,毎回の対戦相手は同じレベル同士で対戦できるようにするという仕組み。毎回接戦になって見応えがあった。ウェザタイはレベルがちょっと違うと一方的な試合になることが多いが,ルール次第でこれだけ面白くできるとは。
団体戦の後,作者を中心にユーザが取り囲んで,好きなことを言う会が始まる。こんなことやってもらえるフリーソフトの作者なんてどれだけいるんだろう。というところで,リクエストを勝手にランク付けして10位まで紹介! 後で全部要望一覧に入れます。
一つ一つ見ていくといろいろあるわけだが,実際のところ,昔要望されたことがあって私が優先度を低くしていたものが半分くらいか。でも作者が思う必要な機能とユーザが思う必要な機能はずれていて,こういう機会があるとそのずれが分かるだけでも貴重。あとは,ここには書けないけど,そんな使い方してるの? みたいな話が聞けたりして。
でも,今回の参加で一番インパクトがあったのは,iOSとAndroid版タイトルのWeather Typingのスペルが間違っていたこと。気になる人はダウンロードして見てみましょう。すぐ直しちゃうので今のうちです。Yさん,ご報告感謝です。
ウェザタイを作って12年,最近は,もういい加減作りが古くなっているし,新しいタイピングソフトに譲っていければいいんじゃないかと考えていた。
でも,2年ほど前,同人本「タイピング Professionals」に少し協力させて頂いて,そして今回,大会であんなに盛り上がっているのを間近で見ることができた。また,最近でもロビーに人が増え始めてるよ,とかコアな人達が満足できるソフトが未だなかったりという状況も聞くことができた。もう,やらざるをえないですよね。
実はタイピング本のときに新しいウェザタイを作り始めていたのだが,自分がタイピングから離れていたためどんなものにすればいいのかよく分からず,途中で止まっていた。今回の参加でいろいろなヒントをもらうことができて,開発スピードもあがるはず。ウェザタイとしてまだできることをやっていくので,よろしくお願いします。
開発状況は今後の日記で書いていきます。
Analog Book ReaderをiOSに移植する環境が整った。今,手元にはMacBook ProとXcode 6 beta,Windows Mac共有ケーブル,iOS 8 betaのiPad Mini Retinaがある。さらにSwiftの洋書も読める。あとは時間だけか。
実際,EPUB機能の追加とかウェザタイの作り直しも平行で進めてるのでかなり厳しい。この状態で新しいアプリのアイデアが出てきたらどうしよう。
電子書籍は紙に比べて,出来事の発生タイミングの認識が悪いというレポート「電子書籍に移行することで失われる読書体験の中身が少し判明」だが,Analog Book Readerなら少しはよい結果がでるのかな。
2chなんかでは以下のような意見が出てたけど,それって単に電子書籍リーダーが悪いだけで電子書籍がダメなわけじゃないよね。
Analog Book Readerでは,常に今どこを読んでいるか,あとどのくらいで終わるかが分かるように常にプログレスバーを出すようにしたし,ちょっと前のページもすぐ確認できてすぐ現在のページに戻ってこれるようにブックマークを工夫した。てことでまさにこういうのを解決しようとしたアプリなので,同じ実験をしたら多少はいいんじゃないかと思うんだけど,どうだろう。
来月またアメリカに行きそうなので,英語の勉強も兼ねてSafari Books OnlineのSwift講座を観たりしている。Objective-Cはちょっと今の時代厳しいよね,って感じだったので,Analog Book ReaderのiOS移植はする気になれなかったけど,Swiftならいけるか? 少し興味が出てきたのでもう少し勉強してみよう。
ブログ更新日をトップページに載せた。やっぱりトップページを見れば全更新日が見えるようになってる方が便利。WordPressのRSSフィードをMagpieRSSで取得して,結果をSSIで表示した。一箇所,MagpieRSSでsplitを使っている部分があり,PHPの新バージョンでは警告になってしまうところがあって修正した。Cacheが作成された後は警告が出ないので,最初に表示されたところで無視してリリースしてしまうと,最初の一人だけ警告が表示されるような微妙なバグになるところだった。
Deprecated: Function split() is deprecated in hoge/rss_parse.inc on line 208
MagpieRSS 0.61の該当箇所を変えて対応したが,MagpieRSSはGPLなので,修正箇所をここに載せておこう。もちろん要望があれば送付します。
修正前
list($ns, $el) = split( ':', $element, 2);
修正後
list($ns, $el) = preg_split( '/:/', $element, 2);
家に戻ってきたのでE-PUBリーダー実装を再開。横書きの本はいいとして,縦書きの本を考えると文字一つが一個のオブジェクトになる。そういえばFlyweightパターンってあったよね,と調べたけど同じオブジェクトじゃないから適用できないか。普通に作るしかないか。
現在開いているページに合った年月を,右にある「アーカイブ」から選択できるように修正した。これでWordPressでやりたかったことは全部完了。
ちなみにうちのブログの場合,Function.phpに以下を記載するとWordPressの月別アーカイブで,今開いているページの年月を選択できる。URLに年月を入れていてウィジェットから選択式のアーカイブ表示にしている前提。
function archives_link_filter($link_html) { if(preg_match( sprintf("@\/%04d\/%02d@", get_query_var('year'), get_query_var('monthnum')), $link_html) == 1) { $link_html = preg_replace('/<option /', '<option selected="selected"', $link_html); } return $link_html; } add_filter('get_archives_link', 'archives_link_filter');
どうせここまでやったのなら,ということでソースコードを綺麗に載せるところもやってみた。つまりソースコードを載せるときに行番号付けたりキーワードに色付けたりってやつですね。以前別のところでやったときは,CSSとHTML変換を駆使して自力で作ったが,今回はオープンソースの力を借りる。
有名どころだとSyntax Highlighterというのがあって,よく見かける。このブログにも入れてみたらデザイン的によく合うのでこれでいいかな。WordPressプラグインもあるらしいのだが,あまり密結合にすると乗り換えにめんどうなのでJavaScript単体で入れた。
Syntax Highlighterでは,JavaScriptとCSSを読み込んだ上で,ソースコードを以下のようにpreで囲ってclassを指定する。シンプル。そして今までもpreで囲むようにはしていたので今回は簡単に移行できた。
<pre class="brush:csharp">
以下,サンプルコード。
namespace com.denasu.AnalogBookReader { ////// 情報ダイアログ /// public sealed partial class AboutDialog : SettingsFlyout { ////// コンストラクタ /// public AboutDialog() { this.InitializeComponent(); var version = Package.Current.Id.Version; _appname.Text = string.Format("{0} {1}.{2}.{3}.{4}", App.Current.Resources["AppName"].ToString(), version.Major, version.Minor, version.Build, version.Revision); } } }
Analog Book Reader。E-PUBの実装で詰まっている。詰まっていると時間がもったいなくなって英語の勉強をし始めるので,勉強ははかどるんだけどいつまでも完成しない。
DTPは昔一通り勉強したから知識としてはあるんだけど,実装するとなるとかなり大変。PurentroでMIDIの楽譜化をしたときも基礎的な音楽理論の勉強から初めて1年くらいかかったけどそれに似ている。
Analog Book Reader Ver 1.3公開。自分で使っていて気になった使い勝手を修正。ページのソートについては今までとがらっと変えたので,何か問題があれば報告をお願いします。
そして偶然そのまま峠 その2も公開。これからどんどん更新していく,のかな。
Analog Book Reader Ver 1.3をストア申請した。ここ2ヶ月でたまったUIの改善とバグ修正。E-PUB対応はまだまだ先。
64bitにするのを早く公開したいので,次のバージョンで入れたいものを急いで実装。いつか書いたが,マンガを開くのに必要な機能がまだ全然足りてなくて,まずはファイルのソートとフォルダ分けの対応をした。今まではzipに含まれる順番で表示していたが,ファイル名の連番に対応したり,フォルダをまたいで見開きになってしまうのを修正したり。結構作り込んだのでうまいこと表示されるようになったはず。
Analog Book Readerを作ったときに一番最初に考えたのが,本を快適に読むためならPCを限界まで使ってしまえというものだった。具体的には,本を開いたら全ページをレンダリングしてメモリに持っておけば,高速にパラパラめくれるというもの。なんだけど,今のバージョンでは,数千ページの本を開くとメモリ不足になるので理想に合っていない。
この問題は最初のバージョンからずっと調べていたのだが,ようやく原因が分かった。Winrtのビルド時にCPUをAnyCPUでビルドしているからなのか。AnyCPUだと基本的に32bitアプリになるので,結局1GBくらいでOut of Memoryになる。ARM/x86/x64でバイナリを分けることで,物理メモリの限界まで使えるようになった。64bit OS限定だが,4000ページくらいの本でも開けて,ロードが終わればストレスなく4000ページをパラパラできる。画像のサイズと拡大率によるが,使用メモリは3GBくらい。
某所でXamarinを知った。.NETのマルチプラットフォーム実装のMonoというのがあるのは知っていたが,Monoをベースにした製品とのこと。WinRTのアプリを作るとAndroidとiOSでも動くようになるというのでAnalog Book ReaderのAndroid版とiOS版を作れるかとおもったけど,WinRTのコアの部分のみ対応で,それ以外はC#で各プラットフォームのUIを作り込むってことなのか。それだったらJava/Objecitve-Cで全部作った方がいいかな。
先週はちょっと違うことをやっていてAnalog Book Readerはすすんでいない。今までのところをとりあえずバージョンアップしてしまった方がいいんだけど,テストする時間がないんだよね。で,それとは別に,今のdenasu.comで通信対戦サーバ作ったらどのくらいのトラフィックになるのかを試算中。
何か急に「タイピング」というキーワードでアクセスしに来る人が増えた。と思って検索してみたら,Yahoo!で「タイピング」3番目だった。「物理シミュレータ」もいつの間にか2番目になっていた。ページランクが高くなったわけでもないのに何でだろう。「World Tester」はVectorの科学カテゴリトップだったり,紹介サイトからのリンク元からも結構アクセスがあって地味にページビューがある。
紹介するのが遅れたけど,タイピングサミットでも「Weather Typing」大会は今でも開かれていてとてもありがたい。
という感じで,新しく公開したソフトに注力している間も以前の作品は使われていて,メンテしたり機能追加したりしたいのだが,時間が足りない。何か面白いことを思いつけばやるかも,くらいになっている。
前に掲示板で「1ページ表示・2ページ表示の切替が欲しい」という要望があった。でちょっと前に解決策が思いついていたので実装してみた。「1ページずらす」メニューを作り,実行するとうまいことずらしてくれる。つまり,前のページを見ていって,タイトルまでいってしまったらタイトルが1ページ表示になるし,途中で横長のページがあればその次のページを独立させる。縦横混在の本で試してみたらまあまあうまくいったので,次のバージョンで入れる予定。
ついでに。このアプリの方針として,できるだけユーザには考えさせずに,自動的に最適な状態にしてあげるというのがある。ユーザが1ページずつ指定するとか,本ごとにあれこれ設定するとか,そういうのはやりたくない。設定画面をあえて用意してないのはそういう意味だったりもする。で,この要望をこの方針で再度考えた結果が「1ページずらす」メニュー。ちなみに機能はできるだけ少なくしたいので,「タイトルページあり/なし」機能は抹消する。「1ページずらす」があればいらないので。
会社で特許文献を読んでいてふと思ったんだけど,マルチモニタで本を読みたい。Analog Book Readerの最新版で画像をピン留めする機能を付けたんだけど,あれって,文書と図が別々のページにある,まさに特許文献みたいな本を想定している。でも,やっぱり紙に印刷して,綴じない状態で4ページくらい広げて読みたくなった。特許文献も,2台のPC使ってようやく読みやすくなった。ピン留め機能でもいいんだけどやっぱり画面が狭い。マルチモニタで4ページ表示,しかも2ページずつ別々の場所を表示できれば嬉しいのだが,Windows Storeで複数画面に大きく表示なんてできないし,どうにかできないかな。
Analog Book Reader公開から今日で3ヶ月が経過する。このアプリを公開するときに,ダウンロード数の目安を知りたくて検索したらYOMON8.NETさんの「Windowsストアアプリについて3ヵ月間のダウンロード数などを振り返ってみる」というページがあった。このページでは,「付箋タイル」というアプリの3ヶ月のダウンロード数とダウンロード数を確保する対策を書いてあってとても参考になった。てことで,私も3ヶ月のダウンロード状況を公開してみたい。次の誰かの参考になればってことで。
青が日本からのダウンロードで,オレンジが日本以外。公開一週間くらいで新着トップになり,急激にダウンロード数が上がった。書籍の人気トップ(無料)で3位くらいまでいって,一ヶ月くらいで落ち着いた。その後,緩やかにダウンロード数が落ちていって,現在は人気トップ(無料)で10位,カテゴリ全体で50~60位くらいか。
ただ,それは日本のマーケットだけで,日本以外ではまだまだ。そこで,リリース4でストアに載るアイコンを少しきれいにして,紹介文の英語をシンプルにした。その結果かどうか,だんだん日本以外のダウンロードが上がってきているっていう状況。アメリカを始めとしていくつかの国でコメントや星をもらっているのでそれなりに使ってくれている人もいるのかな?
全体的には付箋タイルと似た感じか。コンバージョンレートは29%でも高いと感じていたが,付箋タイルは36%となっているのでこれでも低いのかな? まあWindows 8.1にしか対応してないので,そんなものといえばそんなものかも。
ところで「Average App usage per day」って,単位は何なんだろう。200~400分とか出るんだけど,平均値にしては多すぎるし…。
土日でEPUBの実装を少し進めた。EPUB自体はzipなのでzipライブラリで読み込める。中身のメタファイルを解析して,XHTMLはXMLライブラリで読める。と思ったら,XHTMLは要素の中にテキストと要素が混在しているため,winrtのElementsではうまく読み込めない。Elements.Valueでは混在した要素のテキストだけが抽出されてしまう。結局DescendantNodesで細かいノードを一つ一つ解析するようにした。
CSSは既に解析する処理を実装済み。オートマトンに要素階層を与えるとスタイルが返ってくるイメージ。多分遅いので改善することになるだろうけど。
あとは画像系はそのまま読み込めるとして,SVGはどうしよう。winrtでは標準で読めないので,WebViewを経由するか,NuGetでライブラリ探してくるか。
動画やJavaScriptはサポートしないとして,そんなものかな。
あとはXAML to HTML Conversion Demoが参考になりそう。標準のXMLパーサーじゃなくてHTMLパーサーを自作しているけど,おそらくXHTMLじゃないからかな。EPUB3.0だけを考えるならXHTMLだけなので,そこまでやらなくてもいいだろう。
なんかEPUBサポートまであと半年くらいかかりそう。winrtでWebKitが使えれば楽なんだろうけど。EPUB以外の改善もあるので,ある程度のところでそっちを先にリリースするかな。今考えているのは以下。
他にもこの日記にタグとかコメントとか付けられるようにしたいとかいろいろあって,時間が足りなさすぎる。
たまにPowerPointの資料をPDFにしてAnalog Book Readerでプレゼンすることがある。まあ拡大縮小とペン機能を使うだけなので普通のPowerPointでもいいんだけど。で1つバグを発見したのだが、2ページの本の場合、拡大縮小しても解像度が調整されない。この原因は結構深くて、欲しいイベントが欲しいタイミングでやってこないのが根本原因で、そのせいで、起動時に最後のページを開いた場合に解像度調整ができなくなるというのが二次原因。対策案はまだないが、2ページの本はあまりないから急がなくても大丈夫かな。
追加機能とバグフィックスが一段落したので,ePub対応の開発を再開。とはいえ,ePub対応するとどのくらいの電子書籍をカバーできるんだろう。Kindleとか有償サービスのクライアントを作れればいいんだけどそれはできないわけで。
本来は,電子書籍サービスと電子書籍リーダーは分離されているべきだろう。つまり,有償の電子書籍サービスがあってそれぞれ別々に魅力的なコンテンツを売っていて,でも電子書籍リーダーはユーザが自由に選べるという世界。現状は,電子書籍サービス毎に専用のリーダーがあって,この本はこのサービスで買えるからこのリーダを使う,別の本は別のサービスでしか買えないから別のリーダーを使う,ってことになる。サービスを使う側にとっては,本ごとに使い勝手が違うんでイライラする。サービスを作る側にとっても,魅力的な本を売りたいだけなのに不慣れなアプリ開発をしなければならないのでめんどくさいはず。
著作権があるので完全に自由にはできない前提で。似たような話として,地デジの視聴ソフトは,良くも悪くもB-CASがあるので,コンテンツ(番組)とアプリ(視聴ソフト)が分かれている。なので見たい番組を気に入ったソフトで見られる。これと同じような仕組みがあればいいのか,またはもうそんなやり方は古くて,コンテンツは月額料金だけで配ってしまって,ダウンロード数に応じて著作者に還元する方式がいいのか,いずれにしても根本から変えていく必要があるだろう。
Analog Book Readerは,それをふまえて,フリーソフト作者にできることって何かないかなあ,みたいなことを考えつつ作っているわけです。
Analog Book Reader Ver1.2.1でRARファイル対応した。その中で,NuGetからSharpCompressというライブラリを使った。これはC#で作られたオープンソースのアーカイバライブラリ。RAR/7Zip/Zip/Tar/GZip/BZip2に対応しててなかなか素晴らしいライブラリ。標準のPDFライブラリと近い使い方ができるので割とすぐに取り込むことができた。あと1行足すと7zにも対応できるのだが,今の使い方だとページ表示に時間がかかるようだったので入れていない。RARファイルはPDFより少し遅く感じるが,十分実用範囲。
さて,SharpCompressはシーケンシャルアクセスのReader系APIと,ランダムアクセスのArchive系APIを持っている。Analog Book Readerは開いたページを優先的に開くので,ランダムアクセスAPIを使った。しかし,RarArchive.Openはまだパスワードに対応していないようで,RARのパスワード対応はまだ先になるだろう。GitHubの最新のソースでは対応しているっぽいけどwinrt用のブランチはまだっぽかった。
パスワード付きPDFは,次のバージョンでサポート予定。パスワード付きZipはどうしようかな。winrt標準のZipArchiveはパスワード対応していないけど,SharpCompressのZipArchiveはパスワード対応している。でもいろいろ考えるとできるだけ標準クラスを使ってた方がいいだろうな。
Analog Book Reader Ver1.2.1審査合格。日曜日なのにMSの人対応してるんですね。ということで,未サポートの本が複数登録されている場合に起動エラーになる件を修正。次のストア更新のタイミングで公開されるはず。
今回は条件が限られていて,さらにコメントでバグ報告をしてもらえて助かった。何も反応がないと,私も発見できなくて,最悪誰も起動できないまま忘れさられていってしまうわけで。Windows Storeコメントでも掲示板でもメールでもTwitterでも,バグ報告は歓迎です。
ついでにRARファイル対応もリリースした。実はパスワードPDF対応したりキーボードでの拡大縮小とかも既に対応してるんだけど,まだあんまりテストできてないのでこれは次バージョン。