hishidaの開発blog

EBシリーズ(EBPocket,EBWin,EBMac,EBStudio),KWIC Finder,xdoc2txt,読書尚友の開発者ブログ

読書尚友の改良3点

読書尚友に、最近3点の改良を行った。

ファイル一覧でPDFの表紙画像のサムネイルを表示

PdfRendererで先頭ページの画像を取得し、縮小表示している。

f:id:hishida:20210118081857j:plain

読み上げのバックグラウンド再生

text-to-speechでテキストの読み上げを行う場合、Activity上での実行のため、アプリがバックグラウンドに回ったり、端末がスリープすると再生が止まってしまうという問題があった。通勤時間中に青空文庫をイヤホンで聴きたいというニーズがあるはずだが、実際は無理だった。
今回、text-to-speechを Service を用いて別プロセスで再生するようにしたので、音楽アプリのように、端末がスリープしても再生できるようになった。テキストの読み上げ箇所を画面表示するためには、ServiceからActivityへコールバックする必要があるが、Messengerを使った通信で実現している。また、バックグラウンド再生中は通知領域に表示し、タップすることでフォアグラウンドへ復帰するようにしている。

ePubのWebViewによる表示

ePub文書を、これまでは独自ビューアで表示していたが、CSSを活用したレイアウト重視のePubの表示が貧弱で、期待されるレイアウト通りに表示されないという問題があった。そこで、WebViewを用いたブラウザによるePub表示モードを追加した。オーバースクロール(スクロール端で引っ張って離す)による前後の文書への移動、文書内検索、メニューに対応している。

独自ビューだとCSSによるレイアウトが無視されてしまうが。。。

f:id:hishida:20210118082012j:plain

独自ビューアによるePub表示

WebViewだと次のようにきれいにレイアウトされる。

f:id:hishida:20210321161204j:plain

WebViewによるePub表示



ただしテキスト中心の縦書き表示だと、従来の独自ビューアのほうが読みやすい場合もあるので、設定で切り替えができるようにしている。

これでほとんどのePub文書が、一応は読めるようにはなった。ただ個人的には、ePubリーダーとしては、Androidなら楽天koboのビューアかGoogle Play Books、iOSならApple Books がお薦めである。

 

Android Q の外部ストレージアクセスについて

2020年11月以降、Google Play で既存アプリをアップデートするには、targetSDKを29(Android Q)以上にする必要がある。
ところが一つ問題があって、Android Qからは、対象範囲別ストレージ(Scoped storage)が導入され、外部ストレージのアクセスが厳格化された。

developers-jp.googleblog.com


Android P までは、READ_EXTERNAL_STORAGEパーミッションがあれば、外部ストレージのどこでもアクセスができたが、対象範囲別ストレージのもとでは、アクセス可能な領域が限定される。

  1. getFilesDir()で取得できるアプリ専用の内部ストレージ
  2. getExternalFilesDir()で取得できるアプリ専用の外部ストレージ
  3. StorageAccessFrameworkによって選択したファイル
  4. MediaStore APIによるアクセス(画像、動画、音楽、ダウンロードファイル)

ただし、移行期間として、マニフェスト ファイルで requestLegacyExternalStorage の値を true に設定すると、対象範囲別ストレージがオプトアウト(無効化)され、Android Pまでと同様のフルアクセスが可能になる。
現在EBPocket for Androidと読書尚友では、とりあえずrequestLegacyExternalStorageをtrueに設定して、下位互換性を保っている (11月以降のアップデートで一時Android10での外部ストレージアクセスができなくなる問題が出てご迷惑をかけたが、現在は修正済み)。

だが、2021年11月からはGoogle Playに提出するにはtargetSDKを30以上にする必要があり、そうするとrequestLegacyExternalStorageが無効化されてしまう。つまり、対象範囲別ストレージに対応できないと、今後アプリのアップデートができなくなってしまう。

developer.android.com


EBPocketはSDカードに辞書を置いて運用するスタイルなので、対応が難しそうに思う。

実現可能な方法としては、アプリ固有の外部ストレージ領域に辞書を置いてもらう方法があるが、アプリを削除するとデータ領域も削除されるので、アンインストール・インストールすると辞書を再度コピーしなければならない。iOS版のEBPocketは現在でもそうだが、これまでのAndroid版のユーザには受け入れられないだろう。

2021年11月までに対応ができない場合は、アップデートの凍結が最善かもしれない。targetSDKを30以上にしない限り、Android11の端末でも、(requestLegacyExternalStorageによって)対象範囲別ストレージは適用されず、相変わらず自由なアクセスが可能だからだ。

 

Xcode 12 対応

Apple Silicon Macが登場し、今後はIntelからArmへの移行が思ったよりも早く進みそうである。主要なソフトは次々にユニバーサルアプリの対応を発表、あるいはリリースしている。

EBシリーズもユニバーサルアプリ化の準備として、まず開発環境をXcode12に移行することにした。

macOSアプリのユニバーサル化

基本的には、Xcode12でコンパイルするだけで、自動的にユニバーサルアプリになる。Architectures の選択が、デフォルトで次のようになっている。

Build settings → Architectures → Architectures → 

 Standard Architectures(Apple Silicon,Intel)

これで話は終わってしまうのだが、EBMacの場合、これまで対象OSの下限をmacOS X 10.5(Leopard)にしていた関係上、C++ Standard Library に、現在では非推奨の libstdc++ を使用していた。(Xcode9以降はlibstdc++は入っていないため、Xcode8のlibstdc++を無理矢理コピーして、Xcode11まで使い続けていた。)

libstdc++のarm用は提供されないので、ユニバーサルアプリにするためには libc++ に変更する必要がある。

変更箇所は:

Build Settings → Apple Clang-Language-C++ → C++ Standard Library    → libc++

これで晴れてユニバーサルアプリとしてコンパイルすることができるようになったが、対象OSは macOS X 10.9 (Mavericks)以降になってしまった。これは仕方が無い。

ユニバーサルアプリの確認方法

本当にユニバーサルアプリになったかどうかは、file コマンドで確認できる。

$ ls
EBMac.app
$ file EBMac.app/Contents/MacOS/EBMac
EBMac.app/Contents/MacOS/EBMac: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
EBMac.app/Contents/MacOS/EBMac (for architecture x86_64): Mach-O 64-bit executable x86_64
EBMac.app/Contents/MacOS/EBMac (for architecture arm64): Mach-O 64-bit executable arm64

iOSアプリのXcode12 対応 

次は、EBPocket for iOSの移行である。基本的にそのままコンパイルできるのだが、リリースモジュールは作れるのに、デバッグモードでシミュレータを使用しようとするとエラーになってビルドができない。

色々調べた結果、Xcode11以前に作成したプロジェクトファイルにはVALID_ARCHSの定義があり、これが非推奨になったことが原因らしい。

Build settingsのUser-DefinedからVALID_ARCHSをバッサリ削除すると、デバッグモードでのビルドができるようになり、シミュレータが起動するようになった。

なお、Xcode12でビルドする場合、target OSの下限は9.0になる。

 Apple Silicon Macについて

これでユニバーサルアプリが作れるようになったわけだが、やはり実機で検証する必要がある。だが第一世代機を購入するのはなかなか勇気が要る。

現在の私の開発環境は、

の2台だが、Apple Silicon Mac を入れると3台になって、どうも多すぎる。MacBook Proを置き換えた場合、Apple Silicon MacではVM Wareで仮想環境が使えないのが痛い。

順当に考えると、Apple Silicon の Macbook Air あたりを買い足しするのがいいのだが、どうも時期尚早な気がする。

Apple Silicon MacVMWare が動くようになれば、一台に集約できるかもしれないが、もう少し様子見をして考えたい。

 

読書尚友に OpenSearch-1.1 を実装

拙作の青空文庫ビューアである「読書尚友」にはOPDSクライアントの機能があるが、あるきっかけがあって、OpenSearch対応を行った。

そのきっかけというのは、青空文庫でヘンリー・デイビッド・ソローの『森の生活』が追加されていることに気づいたことである。思い入れのある作品なので読もうと試みたが、翻訳が難解で、少しも頭に入ってこない。ふとオリジナルのテキストを見たくなって*1、読書尚友のOPDSライブラリでProject Gutenbergから探そうとしたが、検索機能がないと全く探せないことが分かった。OpenSearchの存在は以前から知っていたが、なんとなく億劫で対応を避けていたのだが、これがきっかけで調べてみる気になった。

まずOpenSearchの仕様はこちら:

opensearch/opensearch-1-1-draft-6.md at master · dewitt/opensearch · GitHub

翻訳はこちら:

Open Search 仕様書 1.1 ドラフト4版 - Walrus, Googling

OpenSearchは、利用する側にとっては特に難しくはない。Project Gutenbergを例にとって説明してみたい。

まず、Project GutenbergのOPDSのURLを実行すると、ルートカタログがRSSで返される。

https://m.gutenberg.org/ebooks.opds/

このなかに、OpenSearchのエントリがある。

<link rel="search" type="application/opensearchdescription+xml" title="Project Gutenberg Catalog Search" href="https://www.gutenberg.org/catalog/osd-books.xml"/>

 間接参照になっているので、href=のURLを実行すると、OpenSearchxmlが返却される。

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<LongName>Project Gutenberg</LongName>
<ShortName>Gutenberg</ShortName>
<Description>Search the Project Gutenberg ebook catalog.</Description>
<Tags>free ebooks books public domain</Tags>
<Developer>Marcello Perathoner</Developer>
<Contact>webmaster@gutenberg.org</Contact>
<Url type="text/html" template="http://www.gutenberg.org/ebooks/search/?query={searchTerms}"/>
<Url type="application/atom+xml" template="http://m.gutenberg.org/ebooks/search.opds/?query={searchTerms}"/>
<Url type="application/x-suggestions+json" rel="suggestions" 
template="http://www.gutenberg.org/ebooks/suggest/?query={searchTerms}"/> <!-- <Url type="application/rss+xml" template="http://example.com/?q={searchTerms}&pw={startPage?}&format=rss"/> <Image height="64" width="64" type="image/png">http://example.com/websearch.png <Image height="16" width="16" type="image/vnd.microsoft.icon">http://example.com/websearch.ico --> <Query role="example" searchTerms="shakespeare hamlet"/> <Query role="example" searchTerms="doyle detective"/> <Query role="example" searchTerms="love stories"/> <Attribution>Search Data Copyright 1971-2012, Project Gutenberg, All Rights Reserved.</Attribution> <SyndicationRight>open</SyndicationRight> <Language>en-us</Language> <OutputEncoding>UTF-8</OutputEncoding> <InputEncoding>UTF-8</InputEncoding> </OpenSearchDescription >

 このなかで、

 <Url type="application/atom+xml" template="http://m.gutenberg.org/ebooks/search.opds/?query={searchTerms}"/>

 が検索のテンプレートである。{searchTerms}の部分を検索語に置き換えて実行すれば、検索結果のRSSが得られるので、OPDSと同様に表示すればいい。

Project Gutenbergから "walden" で検索する例:

http://m.gutenberg.org/ebooks/search.opds/?query=walden

連語を検索する場合はURLEndodingにする。”shakespeare hamlet”を検索する例:

 http://m.gutenberg.org/ebooks/search.opds/?query=shakespeare%20hamlet

 
サイトによっては、間接参照のtype="application/opensearchdescription+xml"ではなく、OPDSのカタログの中に直接参照のtype="application/atom+xml" でOpenSearchのテンプレートがある場合がある。

(例:ManyBooks.net)。

<link rel="search" title="Search Catalog" type="application/atom+xml" href="http://manybooks.net/opds/search.php?q={searchTerms}"/>

 

画面の検索イメージ:

f:id:hishida:20201125185720j:plain

f:id:hishida:20201125185737j:plain

f:id:hishida:20201125185746j:plain

*1:もちろん、『森の生活』の英語版を読み通すような英語力は全くない。冒頭だけでも比較してみたくなっただけだ。

Android 10 のクリップボードの仕様変更について

Android 10以降、セキュリティ強化のためにクリップボードの仕様に制限が加えられた。

developer.android.com

クリップボード データへの制限付きアクセス
デフォルト インプット メソッド エディタ(IME)のアプリまたは現在フォーカスのあるアプリでない限り、Android 10 以降ではクリップボード データにアクセスできません。

 EBPocket for Androidにはクリップボードの変更を検知して検索する「クリップボード検索」の機能があったが、Android10以降は機能しなくなった。

代替案として、Android10以降のクリップボード検索では、EBPocket をバックグラウンドからフォアグラウンドに回してフォーカスを得たタイミングでクリップボードのテキストで検索するようにした。

自分でアプリを切り替える手間が必要だが、Android10の仕様なので仕方がない。

またブラウザ等であればコンテキストメニューに EBPocket を追加しているので、文字列を選択してコンテキストメニューからEBPocketを選択して検索する方法もある。

 

EBPocket for iOS のWKWebView対応について

iOSではウェブブラウザ用のUIKitとして長らくUIWebViewが提供されてきたが、セキュリティ等の問題があり、iOS8からWKWebViewが提供されるようになった。UIWebViewは現在ではdeprecated (非推奨)となっており、2020年4月からUIWebViewを使用したアプリのAppStoreへの新規の申請ができなくなっている。また、2020年12月末からはUIWebViewを使用したアプリのアップデートの申請もできなくなる。

developer.apple.com

このため、UIWebViewを使用したアプリは、WKWebViewへの置き換えが必須になっている。
EBPocketもUIWebViewを使用していたために、今回、思い切ってWKWebViewへの移行作業を行った。私の経験もどなたかの参考になるかもしれないので、作業記録を書き残しておきたい。

基本的な手順としては、次のようになる。

 

1) Build Phases->Link Binary With Librariesに、 WebKit.framework を追加する

iOS13以降では、明示的にWebKit.frameworkを加えていないと実行時にクラッシュする。

 2) UIWebViewのインスタンスを全てWKWebViewに変更する

ここで問題点が2つ生じた。

  • ストーリーボード上でWKWebViewを使用すると、targetOSの下限が11になる

古いXcodeでは、ストーリーボードでWKWebViewが使用できないという問題があったが、Xcode11から使えるようになった。ストーリーボードでUIWebViewを使用していた場合は、Xcode11以降であれば、ストーリーボード上でWKWebViewに変更できる。ただし、xibの"Builds for"を "iOS 11.0 and Later"にする必要がある。

実はこの方法には副作用があり、ストーリーボードからWKWebViewを初期化する場合、iOS10以下だとクラッシュする。このため、プロジェクトのTargetOSの下限も11以上にする必要がある。

TargetOSをどうしても11未満にしたい場合は、ストーリーボードを使わずに、プログラムコードでWKWebViewを初期化する必要がある。
EBPocketでは、Web検索の画面がこれに相当する。TargetOSを8にしたかったので、ストーリーボードを使わずにコードで初期化するようにした。

  • WKWebViewを継承したカスタムクラスをストーリーボードから初期化した場合に、クラッシュする。

WKWebViewの初期化にはWKWebViewConfigurationを引数に使用する必要がある。ストーリーボードからWKWebViewを初期化した場合はデフォルトのWKWebViewConfigurationが作成されるが、WKWebViewのカスタムクラスの場合は、WKWebViewConfigurationが nil になり、実行時にクラッシュしてしまう。
EBPocketでは、辞書の本文を表示する画面がこれに相当し、もともとUIWebViewのカスタムクラスだった。これを単純にWKWebViewに置き換えただけだと、見事にクラッシュする。
この問題にはかなり悩んだが、結局、次のコードをWKWebViewのカスタムクラスに追加することでうまくいった。ストーリーボードからの初期化の場合、initWithCoder:が実行されるので、その中でWKWebViewConfigurationを作成すればよい。

- (instancetype)initWithCoder:(NSCoder *)aDecoder
{
    WKWebViewConfiguration *_configuration = [[WKWebViewConfiguration alloc] init];
    CGRect frame = [[UIScreen mainScreen] bounds];
    self = [super initWithFrame:frame configuration:_configuration];
    self.translatesAutoresizingMaskIntoConstraints = NO;
    return self;
}

3) delegate関数をWKWebViewの関数に置き換える

UIWebViewのデリゲートのUIWebViewDelegateは、WKWebViewではWKNavigationDelegate,WKUIDelegateの二つに分かれている。

UIWebView:
webView.delegate = self

WKWebView:
webView.navigationDelegate = self
webView.uiDelegate = self

UIWebViewのデリゲート関数を、適宜、WKWebViewのデリゲート関数に置き換える。

UIWebView:
- (BOOL)webView:(UIWebView *)webView
shouldStartLoadWithRequest:(NSURLRequest *)request
 navigationType:(UIWebViewNavigationType)navigationType

WKWebView:
 - (void)webView:(WKWebView *)webView
 decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction
 decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler

UIWebView:
- (void)webViewDidFinishLoad:(UIWebView *)webView

WKWebView:
- (void)webView:(WKWebView *)webView didFinishNavigation:(WKNavigation *)navigation

4) javaScriptの実行がUIWebViewでは同期処理(処理が終わるまで帰ってこない)だが、WKWebViewでは非同期処理に変わる(実行後にコールバックされる) 

UIWebView:
    [webView stringByEvaluatingJavaScriptFromString:script];

WKWebView:
    [webView evaluateJavaScript: script
          completionHandler:^(NSString *result, NSError *error){
	// JavaScript実行後の処理を書く
    }];

5) scalesPageToFitプロパティ廃止への対応

 UIWebViewにあったscalesPageToFitプロパティが廃止されており、画面サイズが変更されたときにレイアウトを変更してくれない。結局、次のように親ビューに制約を加えるとうまくいった。

   [self.view addConstraint:[NSLayoutConstraint constraintWithItem:self.webView attribute:NSLayoutAttributeBottom relatedBy:NSLayoutRelationEqual toItem:self.bottomLayoutGuide attribute:NSLayoutAttributeTop multiplier:1.0 constant:0]];
    [self.view addConstraint:[NSLayoutConstraint constraintWithItem:self.webView attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:self.topLayoutGuide attribute:NSLayoutAttributeBottom multiplier:1.0 constant:0]];
    [self.view addConstraint:[NSLayoutConstraint constraintWithItem:self.webView attribute:NSLayoutAttributeLeft relatedBy:NSLayoutRelationEqual toItem:self.view attribute:NSLayoutAttributeLeft multiplier:1.0 constant:0]];
    [self.view addConstraint:[NSLayoutConstraint constraintWithItem:self.webView attribute:NSLayoutAttributeRight relatedBy:NSLayoutRelationEqual toItem:self.view attribute:NSLayoutAttributeRight multiplier:1.0 constant:0]];

 以上でWKWebViewへの移行がすんだが、テスト不足のため、WKWebView対応版のEBPocket for iOSのリリースは延期することにした。現在AppStoreにある1.46.2は、まだUIWebViewを使用しており、iOS13以後に発覚したbugの修正のみを行ったバージョンである。次にリリースするタイミングからWKWebView版に切り替わる予定である。(2020/11/19)

番外:iOS13以降、動画再生ができない問題への対処

iOS13以降、広辞苑等の動画の再生ができなくなったという問題を修正した。
EBPocketでは動画の再生にMPMoviePlayerViewControllerを使用していた。このAPIもiOS10からDeprecatedになり、代わりにiOS8から登場したAVPlayerViewControllerを使用することが推奨されている。iOS13からは実機からもMPMoviePlayerViewControllerが削除されたため、動画が再生できなくなった。AVPlayerViewControllerに変更することで、動画が再生されるようになった。

 

KWIC Finder 4 の最近の改良

ローカルファイルの検索ソフト KWIC Finder 4 に、ユーザからの要望に基づく改良をいくつか加えた。

  1. フレーズ検索を検索オプションに加えた
  2. エディタの切り替え

フレーズ検索

フレーズ検索とは、英単語の連語をそのまま検索する機能である。

(KWIC Finder 4も含め)大多数の検索システムでは、

personal computer

と検索すると、personal と computer を両方ふくんだ文書を検索する。これを、personal computer の出現通りに検索したい場合、フレーズ検索を使う。

KWIC Finder 4では

"personal computer"

のように前後をダブルクォーテーションで囲めばフレーズ検索ができる。だが、常時フレーズ検索を使いたい場合に、ダブルクォーテーションで囲むのは面倒ではある。

旧版のKWIC Finder 3.3 では、検索オプションに[フレーズ検索]があり、オプションを指定するとダブルクォーテーションで囲まなくてもフレーズ検索を実行できた。KWIC Finder 4にリニューアルする際に、不要と判断して省略したが、旧版のユーザから要望があったため、検索オプションの[フレーズ検索]を復活した。

エディタの切り替え

KWIC Finder は3.3までエディタにRichEditを使用していた。だがRichEditは機能が低いので、KWIC Fidner 4 ではフリーのエディタコンポーネントの Azuki Text Editorを使用している。Azuki は行番号やルーラーが表示できたり、プログラム言語の予約語をハイライト表示するなど便利な機能があるが、Azukiにすることで、旧版でできていたことの一部ができなくなった。

RichEditでは、クリップボードにコピーするときに属性もコピーされるので、検索一致個所のハイライトをそのままWordにペーストできた。ところがAzukiはテキストエディタなので、クリップボードにはテキストのみコピーされる。このためWordにペーストするとハイライトが消えてしまう。旧版のユーザから、「検索結果をもとに資料を作成するときにキーワードのハイライトをコピーしたい」という要望があった。

Azukiのソースに手を入れるのが困難なので、エディタ部品を動的にAzukiとRichEditで変更できるようにした。実装方法として、当初はFactoryMethodパターンを使えばできそうだと思っていたが、ドッキングウィンドウのクラスを継承しているためにうまくパターンにはまらず、結局 C# の dynamic 型を使えば動的にクラスを選択できることが分かった。

これでKWIC Finder 4の改良はいったんお休みにする。

次のお題

次はiOSのバージョンアップでいろいろ不都合が出始めているEBPocket for iOSに手を付けないといけない。いよいよUIWebViewからWkWebViewに切り替えないと2020年12月からAppStoreに提出ができなくなる。

あと課題として、青空文庫リーダーの読書尚友のiOS版の開発が残っている。ただiOS青空文庫リーダーも飽和状態なので、今から作っても遅いと思うが、理想の青空文庫リーダーをつくれば、多少は使ってくれる人もいるのではないか。