Hatena::ブログ(Diary)

hishidaのblog このページをアンテナに追加 RSSフィード

プロフィール

hishida

hishida

EB series support page 管理人 ブログ

2018-07-14 KWIC Finderリニューアルに着手 このエントリーを含むブックマーク このエントリーのブックマークコメント

ここ数年、かつて2000年代に作成したアプリの書き換えを進めており、EBWin4に続いて昨年はEBStudio2をリリースした。残る大物アプリがファイル検索ソフトのKWIC Finderである。

KWIC Finder

KWIC Finderは基本的にファイルブラウザ+GREP検索+KWIC索引アプリで、OfficePDF文書プラグインなしで検索できることから長く利用されてきた。だが近年Windowsの利用環境の変化により、不便に感じることが多くなってきた。作者が考える致命的な問題点は次の2つである:

  1. Unicodeに未対応
  2. NASネットワークフォルダに未対応

KWIC Finderからテキスト抽出フィルタの機能を独立させたxdoc2txt については、すでにUnicode対応を行ったver2.0をリリースしている。いよいよ本体のKWIC Finderに手をつけようかと考えている。

KWIC FinderのソースはVisual C++6.0なので、現在のVisual Studio では再コンパイルも難しく、C#全面的に書き直すこととしたい。

KWIC Finderリニューアルの目標:

現在のKWIC Fiderから削除する機能:

開発を始めた証拠に、最初のスクリーンショットを掲載しておこう。最終的なUIはかなり変わると思う。

f:id:hishida:20180714175407p:image

期間は半年から1年ぐらいを考えているが、自分で満足のいくものができたタイミングでリリースしたい。

2018-06-03 青空文庫がSSL/TLS1.0を無効化? このエントリーを含むブックマーク このエントリーのブックマークコメント

5/31頃からAndroid4.4(kitkat)で読書尚友での青空文庫ダウンロードができなくなったという報告を受けた。現象としてはAndroid5.0以上は問題なくダウンロードでき、4.4以下が全てダメらしい。調べたところ、どうやら青空文庫のaozora.gr.jpのサーバーSSL/TLS1.0を無効化した為ではないかという推論に達した。

青空文庫SSL化については、以前から告知されており、4/1以降は https: のURLでないとアクセスができなくなっている。

2018年03月31日 青空文庫SSL化対応についてのお知らせ

https://www.aozora.gr.jp/soramoyou/soramoyouindex.html#000497

だがTLS1.0の無効化については告知がない。たぶんサーバー管理会社の方針でおこなったものではないかと思う。

SSL/TLS1.0の脆弱性は以前から指摘されており、無効化の期限が切られている。

脆弱なSSLおよびTLSからの移行期限の変更について | NTTデータ先端技術株式会社

SSL/TLS 1.0 はいつまでに無効化しなければならないか? | NTTデータ先端技術株式会社

大手のサーバーは軒並み2018年6月をめどにTLS1.0を無効化する見込みで、青空文庫も追従することは仕方ないかもしれない。

問題は既存のアプリへの影響で、iOSiOS5以降TLS1.1/1.2に対応しているが、Androidの場合はTLS1.1/1.2に標準で対応するのは5.0(Lollipop)以降である。

実は4.1〜4.4はTLS1.1/1.2が既定で無効化されているだけなので、アプリ側の対応でTLSを有効にすれば回避できる。

この辺の事情については次が参考になる。

Android4系端末のTLS1.1&1.2対応について

https://qiita.com/ntsk/items/9f31fc7b44c04ea45e0b

具体的な実装は下記の通りで、OkHttpClientを使っている場合は比較的簡単に対応できる。

Android 4系(API16-19)のTLS1.1, 1.2対応 - 怠惰を求めて勤勉に行き着く

support enabling TLSv1.2 on Android 4.1-4.4. #2372

https://github.com/square/okhttp/issues/2372

AndroidHTTP通信の方法について

AndroidHTTP通信を行う方法には変遷がある。

最初はHttpClientが標準だったが、Android5.1から非推奨になり、現在はHttpURLConnectionが標準ということになっている。

一時期Volleyが流行った時期があったが、HTTPClientに依存しているために現在は非推奨になってしまった。

HttpURLConnectionにも標準ではリダイレクトに対応していないという問題があって、リダイレクトさせるには自分で色々実装が必要になる。

[Android]URLConnectionでリダイレクトにも対応してみた | T.Muroiのblog

サードパーティー製でOkHttpClientというのがあり、こちらはリダイレクトにも対応していて活発に更新されているので、今はOkHttpClientを使っているアプリが多いと思う。

読書尚友ではHttpURLConnectionを使っていたが、kitkat以下の場合はOkHttpClientを使って上記の方法でTLSを有効にすることで、なんとかAndroid4.1-4.4でも青空文庫からダウンロードできるようにした。

Android4.0.3以下については、どうあがいても青空文庫サーバーから直接ダウンロードすることはできない。実際、端末のブラウザから青空文庫ホームページを見ることすらできない。

TLS1.0の無効化がすすむと、古いAndroid端末は実用的には使えなくなると思う。Yahoo! JAPANも6/1以降TLS1.0/1.1のサポートを順次終了するとアナウンスしており、「見られるホームページがほとんどない」という事態になるはずだ。

読書尚友の有償版では別のサーバーからの一括ダウンロードができるので、現在までに公開されている作品については一括ダウンロードで読むことが可能である。

だが作品一覧のデータの取得ができないので、新規作品を読めない。作品一覧をミラーサーバに置くとかすれば対応できる可能性があるが、今後メンテしていけるかどうかが不透明だ。

miniSDKVersionを16(4.1Jelly Bean)にして、4.0.3以下は切り捨てることも考えないといけないかもしれない。4.0.3以下の端末で読書尚友を利用しているユーザがまだ2%くらいいるので、悩ましいところだ。

2018-04-06 青空文庫のSSL対応 このエントリーを含むブックマーク このエントリーのブックマークコメント

読書尚友で青空文庫の作品一覧の更新ができなくなったので慌てて調べたところ、4/1からSSL対応され、URLが https: に変わったためだった。

2018年03月31日 青空文庫SSL化対応についてのお知らせ

https://www.aozora.gr.jp/soramoyou/soramoyouindex.html#000497

すぐに修正したが、メンテナンスされていない青空文庫関連アプリだと脱落するものもありそうだ。多くの青空文庫ビューアで使用されている青空プロバイダもエラーになってしまっている。

青空文庫OPDSも今の所3/31で更新が止まっている。こちらはたぶん対応してくださると思うけど。

2018-02-25

[][][]EBWin4 64bit版

要望を頂いている訳ではないが、EBWin4の64bit版を実験的にビルドしてみた。

WindowsクライアントOSではVistaから64bit版が提供されるようになり、現在ではインストールベースで64bitが32bit版を上回っている。32bitOSでは物理メモリが3GBが上限だが、64bitなら物理メモリの上限まで使用できる。

ちなみにmac OSもHigh Sheirraが32bitアプリが動作する最後のOSと告知されており、iOSもiOS11から32bitはもはや実行できない。Windowsアプリもいずれは64bit対応が必須になるだろう。

EBMacやEBPocketはすでに64bit化が済んでおり、EBWin4もそろそろ64bitネイティブ化する時期だと思う。

Visual Studio で64bitアプリを作成する

既存の32bitアプリを64bit化する手順は、

本当に64bitで動いているかどうかは、タスクマネージャで確認できる。

1日くらいの作業で64bit化できたが、私の通常の使用環境だと32bitとの違いは全然感じない。数十個の辞書をグループ化して検索するような極端なケースでは、多少恩恵があるかもしれない。

次の目標はEBStudio2の64bit化になるが、これは4GB超の巨大辞書を作るときに必要になると思う。

P.S.

EBStudio2の64bit版も2/27にリリースしました。特に問題はないように見えます。

2018-02-01

[][] iPhoneX 全画面対応

iPhone Xが発売されて数カ月が立つが、iPhone Xはこれまでと違う独特のアスペクトレシオを持ち、アプリもそれなりの対応が必要になる。

当方の開発環境はこれまでMac OS X 10.11 El Capitan および Xcode 8だったが、iPhone Xの対応はXcode 9以降となる。さらにXcode9の動作環境はmacos X Sierra以降なので、iPhone Xエミュレータを試すには開発環境をアップグレードしないといけない。

開発環境を更新するのはリスキーなので、VMWare Fusionmacos X Sierra環境を作り、その上でXcode9のiPhone Xエミュレータを動かしてEBPocket for iOSの動作確認を行い、対応できたものと思って安心していた。(→ iPhone X の解像度の問題 - hishidaのblog

ところがiPhone Xの実機で全画面で動作させるには、Xcode9でビルドおよび提出が必要であり、Xcode8以前でビルドしたアプリiPhone Xで実行すると上下に黒い枠が表示されることがわかった。

いずれはXcode9以上でないとアプリの提出が認められなくなるので、重い腰を上げてXcode9対応を行うことにした。

1.まずMac OS Xを 10.11 El Capitanから10.12 macos X Sierraアップグレードする。これ自体は特に問題は無い。

2.次にXcode9.2をインストールし、Xcode8時代のプロジェクトをコンパイルしてみると、早速コンパイルエラーの山となった。

Command /usr/bin/codesign failed with exit code 1

Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed'

Technical Q&A QA1940: Code signing fails with error ’resource fork, Finder information, or similar detritus not allowed’

上のURLに書かれているように、次のコマンドを実行することで解決

xattr -cr プロジェクトディレクトリ

3.これで大丈夫と思いきや、iOS11で実行するとUIScrollViewのcontentInsetがずれるという凶悪な問題が発生。

no title

上記URLとは違う解決方法だが、結局、次の方法でiOS11のcontentInsetの自動調整を抑止し、さらに表示位置をiOSのバージョン毎に調整することで解決

MainWindow.xibのRootViewControllerで下記設定を行なう

Adjust Scroll View Insets : チェックを外す ←勝手なcontentInsetの自動調整を止める

Under Top Bars : チェックをつける←NavigationBarの高さが変わっても潜り込まずにbarの下に表示される

iOS6からiOS7になるときにもNavigationController Barの下にUITableViewが潜り込むという問題が起きたが、その時の対処が不完全であったことが、iOS11になって表面化したらしい。

no title

ただ今回のやり方が合っているのかどうかはわからない。そのうち「おまえらのiOS11対応は間違っている」と言われるかもしれない。

一時はもうAppStoreに提出できないのではないかと思って悩んだが、最終的には無事Xcode9でiPhone X対応版を提出することができた。

f:id:hishida:20180209081515p:image

一つの問題点として、Xcode9でビルドすると、TargetOSの下限がiOS8になってしまう。ただしiOSは大多数のユーザが最新のOSに速やかにバージョンアップするので、実際は問題は無いだろう。

iOSはメジャーバージョンアップごとに破壊的修正が入るので、開発者にとっては大変である。