Android 開発日記
★英辞郎第11版発売中！ 2020/3/6発売
開発日記
2015.2.1
UDACITYのAndroid講座で勉強をしている。一通り見た後、実際に環境を整えて一つ一つやってみる。
しかし女性の説明は早口で、しかも聞き取りにくい発音だから厳しいx_x
開発環境がAMDだと、Emulator起動時にお前の環境では動かせん！と起こられるx_x
→Genymotionをインストール(起動にかなり時間がかかる)
"Loading plugins..."が長時間出た後、"Unable to load VirtualBox"と出る。
BIOSの設定が悪いのかと思い確認したが特に問題なし。そのまま起動したらなぜか正常に(?)起動した。
Genymotionは起動できたが、Android Studioからはどうやって起動する？
→Genymotion Plugin for Android Studioというものがあった
→Android StudioからEmulatorの起動までできるようになったが、debugを開始しようとすると、"Segmentaion
fault"または"Aborted"と出る。
Waiting for device.
Target device: genymotion-google_nexus_4___5_0_0___api_21___768x1280-192.168.56.101:5555
Uploading file
local path: E:\src\Android\Sunshine\app\build\outputs\apk\app-debug.apk
remote path: /data/local/tmp/com.example.tnishi.sunshine
Installing com.example.tnishi.sunshine
DEVICE SHELL COMMAND: pm install -r "/data/local/tmp/com.example.tnishi.sunshine"
Segmentation fault
Launching application: com.example.tnishi.sunshine/com.example.tnishi.sunshine.MainActivity.
DEVICE SHELL COMMAND: am start -n "com.example.tnishi.sunshine/com.example.tnishi.sunshine.MainActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER
Segmentation fault
Linuxでの解決方法はあるようなのだが・・・
Genymotionは起動するのに、Android StudioからMyAppが起動できない。
Windows+AMDはもはやマイナーな存在なのだろうか？
Corei5が載ったPCでは実行すると"HAX is not working..."と出る。
→"Intel x86 Atom System Image"をインストールしてみる→変化無し
→"AVD Manager"を選択、Virtual Deviceの一覧の右側にある鉛筆(編集ボタン)をクリック、"Show
Advanced Settings"、RAMの量を1536MB→1024MBに変更したらOK!! HAXMインストール時に指定したメモリ量にする必要がある。
Emulatorが動くところまでで約7GBを使用。
2015.2.3
Buildが終わってからEmulator上で自作アプリが起動するまで最短でおよそ１５秒くらい。これだとデバッグ周期が長くてつらいな。。
(もちろん、Androidは起動した状態。初回はもっと遅い）
Emulatorではなく、x86バイナリーのSimulatorがあればもう少し速いと思うが。。
WindowsCEをやっていた頃は、x86で動くWinCE Simulatorがあったからデバッグサイクルはもう少し短かったような気がする。
そこはWindowsべったりではないAndroidだからしかたないところか。。Macだともう少し速かったりして？
よく見ると"IntelATOM"らしい。それでもこれくらい時間がかかるのか。。どこに時間がかかっているのだろう？
昔に比べてCPUは何十倍も速くなったはずなのに。。
個人的には５秒以内が希望。
まぁemulatorアプリが起動する間にほかのことやっていればいいけど:-)
2015.2.4
別のPCにAndroid Studioをインストールしたところ、Emulatorまで正常に動作するようになった。
しかし、その状態でPCをsuspend/resumeし、Android Studioを再起動したところ、最初に作成したプロジェクトが消えていた。
きっと保存しなかったのだろうと、新規作成をしてみるが、メイン画面がいくら待っても出てこない。。
再インストールをやってみたが、状況が変わらず。（プロジェクトを新規作成してもメイン画面が出てこない）
三度目の再インストールで、なぜかできた！？
実機で動作させてみる
XPERIAにUSBで接続してすぐにできるのかと思ったら、色々と試してようやく実機で動作した。
Nexus7なら素直に動作したのかもしれないが。。
2015.2.8
実機でのアプリ起動時間が約５秒程度！Emulatorは遅すぎ。。ということは、Emulatorを使用する機会は、
・実機がないとき
・危険な動作を伴うデバッグを行うとき
・定型パターンテスト
くらいだろうか？
2015.2.10
UDACITYの"Developping Android Apps"講座のLesson2までクリアした。が、そろそろ挫折感が。その理由は、
・GUIアプリを作るというのにテキストでひたすら入力していく必要がある
というところ。
C++Builder5で長年GUIアプリを作ってきた人間としてはやや抵抗がある。
尤もJavaアプリはこれが普通だし、実際これを業務でやったこともあるが、趣味でやるにはちょっと辛いな。。
業務はどんなに面倒な処理でもそれが収入に直結するけど、趣味においてはできる限り面倒な作業は避けたいところ。
C++Builderだと画面のレイアウトを適当に作って、あとはハンドラーを書けばいいのでとても楽だった。
Android Studioも同じような感じだが、タイピングする量が圧倒的に多い。
C++Builder XEはどうなんだろうか？
C++Builder6以降はあの会社に失望したし、しかも十万円以上のお金を払ってでも使用する価値があるのだろうか？
C++Builder XEの長所は、
・一つのコードでメジャーなOSで動くアプリを作れる
・C++で作れる（PDICがC++で書いてあるからなので最初から作るアプリなら言語は何でもいい）
問題点は
・どのOSでも動くアプリがどのOSでもキビキビと動作するのか？
・知られざる落とし穴がたくさんあるのではないか？
C++BuilderXE(などのエンバカデロの製品）で作ったAndroidアプリって世の中にどれくらいあるのだろうか？
「お金をかけられるのならC++BuilderXE(あるいはDelphi)がいい」というのなら私はお金を払ってでもC++Builderにする。
ちょっとしたお遊びアプリならAndroid Studioで十分。自分が作るのは中規模ソフトなので、開発にかける時間はなるべく減らしたいところだが。。
C++Builder XEに踏み込めない一つの最大の理由は、Androidの開発関連のWebを色々と見ても、C++Builder(やDelphi)を使っている記事をまったく見かけないから。
仮にXEが優れていたとしても、C++とかDelphiというのは言語の選択肢としてはやや厳しいところがあるかな。。という気はするけど。
2015.2.11
C++Builder XE7 お試し版を試してみた。(FireUIを使用)
・インストール必要HDD ・・・ OSX, iOS, CORBAを外して10GB以上は食っている。正確に測ってません^^;が、とにかく大食い
・C++Builder5を使ってきたから使用説明書も無く使用できる。
・空のAndroidアプリ起動まで３０秒→使い物にならない。。
・空のWin64アプリ起動まで１秒→普段はこちらでデバッグすればいいので、３０秒起動は許せるかな
・すごいのはAndroid上で実行中ブレークし、逆アセンブルでステップ実行ができるよ！！
・アプリ実行速度 - それなりのアプリが無いのでなんとも言えないが、C++/NDKだから遅いことは無いだろう。。
・package size - Win64版=200KB(DLLが別に必要だろう)、Android版=7MB（でか！！）
→apkファイルの中身を見ると、アプリバイナリファイル(.so)だけで21MBもあった！！
→Win64もstatic linkにしたら14MBもあった！！でかーい！！
という感じで現時点の問題点を挙げると、
・実行ファイルがでかい。仕方ないが、独自コードを追加しても最終的にサイズはそれほど大きくならないだろう。
・ネット上でC++Builder XEを使っている人をほとんど見かけない
・エンバカデロのサポートが気になる。基本的にバグ放置→バージョンアップで修正→新たなバグが仕込まれる→という悪循環T_T
・同様に、AndroidがVUPしたとき動作しなくなるリスクがあり、（高い）バージョンアップ料金を支払う必要がある
・付属のヘルプは使い物になるのか？
逆に利点は、
・一つのコードでWin32/64,Android,iOS,OSXで動く
・とにかくvisualの開発が楽
・もしPDICをこちらに移植すれば、Win64版が作れるし、速くなるかも？？（実行ファイルはでかくなるけど）
C++Builderに傾いているんだけど、Visual Studioという手もあるんだよな。。
ほか使ってみると以前から変わらない問題がある。
・エディターの支援機能が遅くて使い物にならない
・エディターの機能は昔と変わらず、今となっては貧弱
・コンパイルのスレッドは１つしか使っていない（今どき・・・）
さらには新たな問題点もある。
・コンパイルでエラーが発生しても発生箇所に自動的にジャンプしない（なんだこの改悪は？）
JNI/NDKで作成した場合の問題点
Android Studioで作成する場合、JNI/NDKは必須になるわけですが(PDICの場合)、C/C++側には制約があるらしい。
こちらに書いてある通り(ここにも)。書いてある記事がかなり古いので現在はどうか知らないが。
もちろんできる限りJavaで書き直すという手もあるが、時間的には非現実的。（７〜８年はかかるんじゃないか？←Androidはもう無いかもしれない(笑)
現在ならもう少し緩和されているかもしれないが、full対応はまず無いだろう。。それにJNIだとdebugの難易度も増す。
→ますますC++Builderに傾いてきた。
■今日の結論
ゼロからAndroidアプリを作るのならAndroid Studioを使ってJavaで書くのが無難だろう。
しかし、C++で書いた既存のアプリがあり、しかも大量のコードがある場合はAndroid Studioは厳しいと思う。
となると、選択肢はC++BuilderかVisualStudioになる。（と思う）
VisualStudioはWindows版しか使っていないのでなんとも言えないが、「Microsoftのツール」というリスクがあるため、たとえ無料であっても気安く手を出す気になれない。
かといって、エンバカデロもユーザーのサポート面から言ってあまりお勧めできないが、自分のようにC++Builderで作ってきたアプリからの移植であれば、C++Builder
XEしかないような気がする。
１５年ぶりにC++Builderの新しいバージョンを使って、がっかりな面がちらほらと見かけるが、機能的には魅力的だし、多少のお金を払ってでも自分の時間を節約できる点では有益だと思う。C++Builderにはバグが多いがそれとはうまく付き合っていく。今までもそうだったからね。
2015.2.12
PDICをC++BuilderXE7に仮移植を始めた。が、
・Internal compiler errorがたまに出る
・Compile途中でIDEが突然落ちることがたまにある
C++Builder5の頃と変わってないな。。
まぁPDICはいろんな環境に対応しようとしたため、headerはifdef-else-endifの嵐なので、heavyなのかもしれんが。。
この辺りはまったく同じなんだね。
この手のエラーはプリコンパイルヘッダーを削除すればいいんだが、保存先の設定が消えた！？
→プリコンパイルヘッダーを使用しないに変更→とりあえずOK
→しかし再び"Internal compiler error""が！！！
これ、どうしたら解決する？まぁ無理だろう。。C++Builder5のときも散々悩んでプリコンパイルヘッダーを消去すればいいとわかったけど。。
テンポラリディレクトリにあるファイルもすべて消したけど、解決せず！！
ということで、
C++BuilderXE7 挫折！！
coreなところは全然いじってないんだね。。
スパゲッティ状態の一部のheaderをandroid用に書き換えればいけるかな。。
→なんと、compile errorの原因を探るために入れた#error命令で落ちていた。しょうもねぇ。
2015.2.13
PDICの辞書制御部の移植を始めた。Androidの中身はLinuxだから、かなり前にLinuxへの移植をやっていたコードが生きてくる。
ところで、Androidのnativeの文字コードはなんだ？LinuxなんだからUTF8だと思うが、とりあえず今はそのつもりでやっている。
→FireUIはUTF16とUTF8の両刀遣いだった(どっちがnativeかわからんけど)
2015.2.14
引き続き文字コード問題。androidのnativeはUTF8のはずだから、基本的にUTF8のほうがいい。しかし、FireUIのnativeがUTF16だとすると、効率の面から言えばUTF16がいい。けど、UTF16で作ろうとするとandroidの標準ライブラリが対応していないはずなので、UTF16用のライブラリを自前で用意しなければならない。ということで、
FireUIのみに依存するコード・・・UTF16(それがnativeだとすれば)
自前コード・・・UTF8
PDICの辞書制御部・・・UTF16
ということになる。FireUIがUTF8であればPDICの辞書制御部だけがUTF16なのですっきりする。
では、FireUIのnativeの文字コードは何か調べてみたが、よくわからん^^;
いずれにせよ、FireUIは基本的にUTF16/UTF8の違いを意識しなくてもいいつくりになっているような感じなので、基本UTF8でいこうかな。
2015.2.17
再び文字コード。文字列定数について。
普通に"xxx"で定義すると、SJIS(ANSI)
L"xxx"は当然UTF16(wchar_t)
日本語を扱うことを考えるとUTF16にしなければならない。
と思ったら、u8"xxx"なんていう定義があるんだね。
と思いきや、C++Builderではu8"xxx"と記述してもSJISじゃないか！？
PDICの場合、ほとんどのメッセージ、文字列はテキストファイルに保存しているため、大きな影響は無いのだが、"【】"と比較する、といった固定の短い単文字と比較する場合は困る。考えられるのは、
・UTF16で定義して比較時にUTF16->UTF8(または逆)に変換する
・UTF8を１６進数で書き込む（変換が不要になる）
いずれか。あなたならどれを選ぶ！？
効率を考えれば後者だけど、移植性を考えたら前者だよね。
→結局、文字列定数用のクラスを作ることにした。UTF16で宣言したものを必要なときに必要ならばUTF8に変換するもの。
2015.2.18
再び文字コード問題。
やっぱりUTF16がいいんじゃないだろうか？
PDICは完全にUTF16で書かれているし、それを前提にしたコードも所々ある。
FireUIのnativeもUTF16のような気がするし。
もしUTF16にした場合の問題点は、
くらいだろうか？標準ライブラリといっても数は限られているし、それらを一から書くといってもそれほど大変な作業でもない。
・・・と思ったらwchar.hというヘッダーがすでにあった。そりゃ今どきあるよねー。
2015.2.21
C++Builder XE7の問題点はARMにしか対応していないところ。PDICの正式版が出るのはあと２年はかかると思うので、それまでだましながら試用版を使い続けようか？それとも最終的にNDKで作ろうか？それともJava/C++に切り替えようか？
もしC++BuilderがARM以外のCPUをサポートした場合、最終パッケージのサイズはどれくらいになるのだろうか？
とにかくFireUIがどの程度のものなのかまだわかっていない。共通化によって貧弱なものになっているんじゃないだろうか？
PDICに必要なUIの要素はインクリメンタルサーチとポップアップ検索ウィンドウと、ポップアップウィンドウ、検索履歴。それに数個の設定画面。
C++BuilderのGUI設計は本当に楽だと思うけど、FireUIの制限で苦労するよりはnativeのJavaを使ったほうが苦労が少ないのではないだろうか？
となれば、AndroidStudio(Java)+JNI(C++)が良いような気がする。その場合気になるのはJNIの制約だが。。。
とにかく、今はC++Builder(試用版)で進める。試用期限が過ぎたらVMWareでインストールしなおして(笑)
最終的にC++Builderは使わないだろうからそれでいいだろう。だって高すぎる。新規で２０万円弱、バージョンアップのたびに１０万円くらいかかる。だからAppmethodというライセンスを用意したんだろうけど、一番売りのFireUIに期待をあまり持っていないので。。実際今のところ、C++Builderでなければできないことはやっていない。Anddroid
NDKでもできる移植作業。
C++Builderの困ったところ：
最終的にできるファイルが.soだから、使用していない関数までlink errorが出る x_x
これまでAndroid関連の本は数冊読んだ。（ほとんど斜め読み）
やはりこういうときは書籍が一番。ネット情報は散逸的で系統だった理解が難しい。明確なキーワードを知らないと的確な情報を得られないのがネットの欠点。
2015.2.22
辞書のopen/closeをGUIから動かせるようにするのが最初の目標。
現在リンクエラーが５５個。→０にできた！！しかし、実行開始ができなくなったx_x →出力フォルダにread onlyファイルが残ってました^^;
→起動OK
衝撃の事実
Pdicの辞書クラスも生成できるようになった。しかしファイルを作成しようとすると何かが変。
デバッガでwchar_t型のファイル名を見るとなんと！UTF32(?)じゃないですか！
ということは、wchar.hに定義してあるライブラリ関数もUTF32？
RAD Studioの説明書は「Androidは２バイト」とどこかに書いてあったような気がするんだけどな。。（Macは４バイトっていうのはあったが）
UTF32でもいいが効率悪くないか？体感できるほどのパフォーマンスの変化はないと思うけど。。
sizeof(wchar_t)=2のつもりでビルドが通っているので修正箇所は少ないと思うけど。。
UTF8にしたほうがいいんだろうか？？
その場合はもっと修正が必要になる。悩ましい。。
とりあえずUTF32で進めることにする。
→辞書が作成できるようになった！
次なる問題は、
・辞書ファイルのようなアプリ固有のファイルはどこに作成するのがいいのか？(今回は/sdcard以下に作ったが）
・実行ファイルに必要な付随ファイルはC++Builderではどうやって配置するのか？
・開発環境をどうするか？C++Builderの試用期限があと２週間ちょっとしかない。VMWareという手も考えているがUSBデバイスはちゃんと動かないような気がする。。でなければ日付をごまかして・・・というインチキをやらないと^^;
そういえばAppmethodがあったね。Android向けなら制限がないし。明日試してみよう。
2015.2.24
・付属ファイルの置き方は？
- assetsに置けば良いらしいが、C++Builderの場合はどうすればいいのかさっぱり
- assetsからの読み出しにはJavaのAssetManagerが必要らしいが、Javaを使用しない場合は？直接/data/data/<package>/files/でいい？
追記：メニューの「プロジェクト- 配置」にあった！
2015.2.25
辞書を正常に作成できるようになった。（/sdcard/TabbedApplication/test.dic)
# 三日前は言語プロセッサが無かったため辞書ファイルはできてもエラーで返ってきていた
次なる問題、ログはどうするのだろか？
__android_log_printf()を使うらしいのだが、IDEのどこに出てくる？？
2015.2.26
挫折気味。
C++Builderのヘルプは使い物にならない、説明書もあまり詳しいことが書かかれていない、ググっても情報がほとんどない、書籍にいたっては皆無。
付属ファイルはとりあえずだましだましで最終的にJavaアプリからの呼び出しにすれば問題ないけど、ログが使えないというのはかなり厳しい。
ステップ実行で見ていけばわかるけど面倒くさい。（それに昔のC++Builderに比べて変数表示が手抜き、使いにくい）
とりあえず必要なソースコードをコンパイルが通るまで進め、早々にAndroid Studioに移行したほうが良いかもしれない。
うむ、勇み足で購入しなくてよかった。
付属ファイルは[プロジェクト - 配置]でできることがわかった。
また、ファイルアクセスは
System::Ioutils::TPath::Combine(System::Ioutils::TPath::GetDocumentsPath(), L"filename") // Internal
System::Ioutils::TPath::Combine(System::Ioutils::TPath::GetSharedDocumentsPath(), L"filename") // External
だそうです。
2015.2.27
System::Ioutils::TPath::GetDocumentsPath()の実際の値は "/data/data/com.embarcadero.TabbedApplication/files/"
でした。
配置した場所は "./assets/internal"
これで普通にオープンできました^^/
次なる目標は小さな辞書を配置し、インクリメンタルサーチを実現することだ！
今後のステップを書いてみる。
・１つの辞書でインクリメンタルサーチ
・マルチ辞書でインクリメンタルサーチ
・不規則変化辞書を含めたインクリメンタルサーチ
・テキスト形式辞書を含めたインクリメンタルサーチ
ここまでできたらAndroid StudioでJavaUIのプロトタイプ作成。（２週間程度？）
・インクリメンタルサーチ画面
・辞書設定画面
・ポップアップ検索ウィンドウ
・ポップアップウィンドウ
以上でUIの基礎ができる。（２週間程度？）
・それぞれのUI画面とC++の辞書制御などを結合→基本的な検索が可能に（１週間程度？）
ということで順調に進めばあと一ヶ月で基本的な検索までは動作しそうだ。(4/Bくらい?)
この頃にはC++Builderから離れているだろう。
さらにさらに(笑)
・辞書設定画面のロジック設計→任意の辞書が利用可能に(1w)
・ポップアップ検索ウィンドウでポップアップ検索(2w~3w)
・検索履歴機能(1w)
これで普通の辞書レベルにはなるはず。(5/Eくらい？）
さらに。
・ポップアップ検索ウィンドウのブックマーク機能(2w~3w)
・ブックマークと検索履歴のcloud共有機能(2w)
・ネットワークからの辞書ダウンロード機能(2w)
これで当初目指していた原型がほぼ出来上がる(7/Mくらい？)
ここで試しにパッケージ化してα版として一般公開。(7/Eくらい？）
順調にいけば、8/Eには正式版公開！？
現実にはここに書いていない色んな細々としたことがあるし、空いている時間を使ったただの趣味でしかないので、実際は１０割り増し〜２０割り増しくらいでしょう。
なので今年の年末くらいまでにできればいいほうかな？
それでも何といってもWindowsCEで実現していたワンタッチで検索、というのは一日も早く実現したい。自分の知る限り、Androidデバイスでは世界初だ。
ところで、wchar_tがUTF32が一般的というのは知らなかった(つまりWindowsローカル)。PDICの辞書制御はUTF16を前提にしていたが、辞書自体はUTF16ではなくBOCU
encodingなので、文字コード変換だけ変更すれば済む。もし辞書の中身がUTF16 encodingだったら辞書制御部をいじくらなければならない可能性はあったけど、BOCU対応で苦労した分、wchar_tがUTF16だろうとUTF32だろうと基本的に関係ない、というのは助かった。
さて、次なる課題はインクリメンタルサーチの対応だが、幸いPDICのUnicode版は検索ロジックとGUI処理を分離してある。そうすることでWindows上の別のアプリでもインクリメンタルサーチを実現するつもりだったが、今や時代の乗り遅れ。だが、ここに来て生かすことができる。あのとき苦労して分離しておいた甲斐があった。
検索ロジックをAndroidに移植できれば、あとはC++BuilderのGUIとの結合だけ。でも実際はそれほど綺麗に分離しているわけではないので、ある程度の作業が必要だと思うけど。
2015.3.7
ようやくインクリメンタルサーチ部のコンパイルエラーが出なくなった。これからGUIと接続し、デバッグ作業に入る。
2015.3.8
検索処理のデバッグ中。。
PTHREAD_RECURSIVE_MUTEX_INITIALIZERを使ってmutexを作ったけど、同じスレッドでlockすると、deadlockを起こす！？
ググって見たけど、そんな情報は見つからない。
pthread_mutexattr_settype()はエラーが帰ってきている。
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NPは定義がないと言われる。
パフォーマンスの低下を嫌ったから？NP(non-portable)だから？
いずれにせよ、自分のところで対処しなければならない。
再帰的なmutexを必要とする構成がいけないが、今からそれに修正するのもつらい。（元々問題なく動いているから）
とりあえず再帰的なmutexを自前で用意するのが良いだろう。
→作りました
辞書オープンまでは動作。
インクリメンタルサーチで１文字入力すると落ちる。seek()呼び出しで落ちる？？パラメータは正しいように見えるが。。どこかメモリが壊れている？
次回は、辞書オープン直後に検索を行うテストコードでデバッグしてみよう。
2015.3.12
この問題は意外と根が深い。どうやらどこかでメモリを破壊しているらしい。これは厳しい。しかもC++Builderのdebuggerは貧弱だし。
（昔はC++Builderが先を行っていたが、今やVisualStudioにはまったくかなわない。Windowsでの話だが）
あと一週間くらいは覚悟しようかな。今はログの出し方もわからないし、デバッグ環境としてはかなり厳しい。
(今のところ)C++Builderは買わなくて良かった。。
2015.3.13
→解決。wchar_tを2バイト前提にしていたところが共通定義にあった。そりゃ動かんわ。
RAD Studio XE7をアンインストール、AppMethodに乗り換え。
環境設定をすべてやり直しになったが、既存のプロジェクトは問題なく動作。
今後：
・Android Studioを使った入門書で参考になるアプリをsampleで試作
・UI関連の書籍を読む
しかし、まだインクリメンタルサーチで落ちる。１文字なら良いけど、２文字以上になると落ちたり落ちなかったり。。不安定
2015.3.14
インクリメンタルサーチの結果が表示できるようになった。
しかし、まだ落ちる現象が。落ちる場所もタイミングもその都度異なるので厄介。
検索結果の文字は日本語（中国語、アラビア語など）も出るため、基本的な辞書アクセスは問題なさそう。
落ちるところは様々だが、必ず辞書制御部。どこか間違っているところがあるんだろう。落ちる場所の周辺を見た限りではそんな間違いは見つからない。
しかしこの問題を解決できれば、辞書制御部の問題はほとんど無くなるだろう。
さすれば残りの辞書関連（マルチ辞書、不規則変化辞書、テキスト形式辞書）もそれほど時間はかからないはず。（一週間くらい？）
それが終わればいよいよGUI側の設計の開始だ。
今日借りた書籍：
「Androidのなかみ Inside Android」「ANDROID HACKS」どちらも良さそうな感じ。
今日購入した書籍：
「Android UI Cookbook for 4.0 ICS」(kindle版) UIを勉強するために、ちょっとしたときに読む書籍としてこれを選んだが、今ひとつ。「とりあえず訳してみました〜」感のある書き方・内容で失敗だったかも。この著者の書籍はそんな感じがするので彼女の書籍はこれでやめておく。もちろん、購入したからにはサンプルはすべて試してみるが。
2015.3.15
久しぶりにAndroidStudioを立ち上げ、PDIC GUIのプロトタイプを作り始めた。
Activity/Fragmentの関係は昔からあるDoc/Viewモデル的な関係だと思っているけど、そうじゃない？（ググると意外と悩んでいる人が多そう）
個人的には単純なDoc/Viewというよりは、Activityが状態管理、FragmentがViewの管理だと思っている。
なので、１つのActivityで複数のFragmentもありうると思う。
とりあえず、PDICは１つのActivityで複数のFragmentを持たせようと思う。
インクリメンタルサーチとポップアップ検索ウィンドウは異なるFragmentになるけど、Activityは１つ。
何故そうなるかというと、検索ロジックのほとんどはC++のモジュールでやってしまうため、Java側で必要な処理のほとんどはGUI回りだけになりそうだから。
そんなことより今はプロトタイプなので構成はあとでやり直せる。それよりはJava/C++という仕組みで基本的な検索動作ができることをまず確認したい。
2015.3.16
辞書制御部で落ちる問題はなかなか厳しい。やはりログ出力がないと。
#define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, "TAG", __VA_ARGS__)
という定義があったのでこれを使ってみたが、一体どこに出てくる？？
それじゃ、ファイルに保存してみは？ということでやってみたが、これもいったいどうやって表示させるのだ？
そもそも正しく保存されない。バグっぽいところは見当たらないけどな。。
→なんと、wsprintf()はダミーでまったく機能しない関数だった！！
→vsnprintf()を使用することでとりあえずファイルにログを出せるようになった。
ログ機能(printfデバッグ機能）が無いのはかなりつらいぞ！
しかしまだ辞書制御部で落ちる現象が解決出来ない。。
もしかしてかもしれないけど、
・検索はidle時の処理のため、検索終了にもかかわらず検索処理を続けているのがいけないかもしれない（もちろんそれでも問題ないはずだが、その検証はやっていないため）
だろうか？
2015.3.17
辞書制御部で落ちる問題。
時々見出し語部がNULLになるときがある。
時々圧縮されたデータとなるときがある。（ないはずだが）
など、何らかのタイミングで誤ったデータになる。
こういう再現性のない問題が一番難しい。
こういうのはたいていメモリが壊れている場合だが。。
もしかしてだけど、
辞書ファイルからのreadがおかしいのではないか？
PDICの辞書制御部は何年も使いこんできた安定したものなので、今更メモリを壊すようなバグはないだろうし、いくらメモリを壊すといっても時々正常に動作するなんていうことは考えにくい。(100%と言い切れないが）
そう思ってファイルから読み込んだ内容のチェックを入れたら問題が起きなくなった。ということは核心に近いか？
2015.3.18
辞書制御部で落ちる・化ける問題。
ファイルから読み込んだデータのチェックサムを取ってみたが、変化がなかった。
一つ気になるのは空の見出し語がヒットするところ。
この問題はなかなか尻尾がつかめないなぁ。
2015.3.19
まだまだ辞書制御部で落ちる・化ける問題。
さすがに疲れ始めてきた。
今日も解決できず。
それでもだいぶ絞り込んできたのであと２〜３日で解決できるだろうか？
2015.3.22
辞書制御部の問題がようやく解決。
構造体のpackingの問題。
struct A {
unsigned short a;
unsigned char b;
unsigned char c;
unsigned char d[1];
};
ここで sizeof(A) - sizeof(unsigned char) この値はいくらになるか？
Win32では4になるのだが、Androidでは5になってしまう。最後に無駄な１バイトパディングが入ってしまうため。
今まで正常に動いていたように見えたのは「たまたま」だった。
マルチ辞書まで動作確認OK
2015.3.24
GUI(Java)側の設計を始めたが、なかなか自分のイメージどおりに進まない。
基礎的知識が足りないのでは？ということで、
・ポップアップ検索ロジック部の移植
・JNI化の準備
を先に進め、GUI側に関してはもう少し書籍を読んでみようかと思う。
と思ったが、やはりGUIのプロトタイプをまず作りたい。そこからJNIでつなげて基本的な動作をさせたいところ。
それらしいものは作ったけど、どこかがおかしい。
やはり基本的なところが理解できていないからだろう。
例のあんざいゆき著の書籍はいくつかサンプルを動かしたりしてみたけど、4.0ではこんなことができま〜す、以上。
という程度の内容で、実際の利用ではこうすべき、みたいな実践的な内容が書いていない（と思う）。
JNIやC/C++の部分はそれほど苦労しないと思うので、まずGUIの部分をクリアしたいところ。
最新のセンスのいいGUIはあとでやるので、とりあえず基本的にはこれだけあればOK、みたいものを作りたい。
オライリーの「ANDROID HACKS」はやはりいい本だったが古すぎる(2011年)。
やっぱり、4.0に対応した初心者向けのちゃんとしたGUI本を購入したほうが良いかな。
PDICのターゲットは4.0以上のつもり。
2015.3.26
Android NDKとcygwinをインストール。
これでJNIの開発環境は整った（はず）。
GUIのへんてこなところも修正。ちょっと難しく考えていたようだ。
これでJava/C++でインクリメンタルサーチが作れるはずだ。
2015.3.29
JNIアプリ作成にはEclipseが必要だった。
しかしそのためだけにEclipseをインストールするというのも・・・Android Studio(1.1.0)だけでできないだろうか？
http://matsu-world.qee.jp/?p=1752 こちらを参考にしてやってみたが、途中でうまくいかない。
> Android Studioのコンソールなどから、自動で実行されていたコマンドを入力します。
とあるけど、それらしいコマンドが見当たらない。
ここを無視して再度ビルドすると、Android.mkが元のファイルに上書きされてしまう。
ということは、Android.mkをビルドするたびに書き換えないといけない？
これじゃだめだ。使い物にならん。
やはりEclipseをインストールするしかないか。。
その程度で諦めるのはまだ早いので、ネットをウロウロと調べてみたら、
build.gradleの andoird/sourceSets/mainにjni.srcDirs = []; を追加しておくといい、みたいな記事があったので、やってみたらコンパイルエラーは消えた。
これでbuildが通ったかのように見えたが、肝心のobject fileが生成されていない？？
→どうやら、srcDirsを指定するとndk-buildが走らないらしい。だからうまくビルドができたように見えていた。
となると、ndk-buildのどこかに間違いがある可能性がある。
もう一度先ほどのサイトに戻り、ndk-buildが実行したと思われるコマンドを自分の環境に合わせて修正したところ、ようやく.soファイルが出来上がりました。
ndk-buildが実行しているコマンドは、
<NDK_DIR>ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=<PROJ_DIR>\app\build\intermediates\ndk\debug\Android.mk
APP_PLATFORM=android-21 NDK_OUT=<PROJ_DIR>\app\build\intermediates\ndk\debug\obj
NDK_LIBS_OUT=<PROJ_DIR>\app\build\intermediates\ndk\debug\lib APP_STL=gnustl_shared
APP_ABI=armeabi,mips,armeabi-v7a,x86
※結局、Windowsでは一工夫しないとうまくいかないということだ。
さらに先ほどのサイトの言う通りにやったらアプリが無事実行できました。(shared libraryのloadまで)
これでAndroidStudioでJNIが作成できるようになりましたが、問題は今後の開発サイクルをどうするか？
今回わかった問題点は、ファイル構成が変わるたびにAndroid.mkとbuild.gradleを書き換えてbuildし直す必要がある。
ファイル構成の変更が無ければ、C/C++側の変更があったときのみndk-buildを直接実行、.soファイルのコピーだけでいける。
それくらいなら許容範囲か。LinuxやMacならその手間が省けるが、JNIのdebugはその手間以上に厳しいだろうから、とりあえずこのまま進めることにする。
しかし、現在の完成度レベルでJNIによる実装を進めていいのか？っていうのはある。なんだかんだ言っても今の自分の認識ではAppMethodのほうがデバッグはやりやすいと思う。AppMethodで基本動作確認→それをJava/JNI@AndroidStudioで実行、みたいな開発サイクルが続くだろうか？
まぁとにかくJNIによる超簡単なアプリが動いたのだからあと一週間くらいはPDICのJNI実装に向けてトライしてみようかと思う。
本日の結論：
・cygwinは不要だったw
・AndroidStudioだけで作れそう(Eclipseは無くてもOK?)
・AppMethodはデバッグ用にもうしばらく使いたい
2015.3.30
AndroidStudioでJNIを、と始めてみたが・・・
・app/src/main/jni にあるファイルは拡張子に関係なくすべてコンパイル対象にしてしまう→Android.mkは自力で書かないと
・同様にinclude fileのpathも自力で追加が必要・・・当たり前といえば当たり前だが、要するにmakefileを書かなければいけない
・しかし、ソースコード以外のファイル（.vcxprojとか）がmakefileに入っていても何もエラーが出ない？？（本当にコンパイルしてんのか？）
・いやいや、明らかにinclude pathが通っていないheader fileをincludeしていても、正常終了するときがある（本当にコンパイルしてんのか？）
・コンパイルエラーは出るけど、ジャンプは手動？
・時々AndroidStudioが強制終了する（Firefoxも最近落ちるので環境の問題かもしれませんが）
などなど挙動が不可解。
まだβ版（？）だし、正式版まで待ったほうがいいだろう。そもそも正式版でも満足できるものになるかどうかわからないし。
しばらくEclipseにしておこうか。
そ・れ・と・も。
PDIC Android版の正式版が出るまで少なくとも半年以上はかかるし、現時点ではGUIも定まっていないからここでわざわざ苦労してJavaGUIを使ったアプリにする必要も無い。
当面は、
・AppMethodを使ってPDICの必要なコアな部分を一通り動作させる。
・GUIに関してはその辺に転がっているサンプルで勉強する
でいいのではなかろうか？
GUIを除いたPDICの完成度が上がるうちにAndroidStudioのNDKサポートが正式になるのではなかろうか？
PDICはGUIへの依存が低いから、そのときになって実装を始めても遅くは無い。
心理的にはとりあえず基本的なGUIを作ってから進める、っていうのがいいけど、現在のJNI事情はあまりよくなさそうなので、この方針がよさそうだ。
2015.3.31
やや食傷気味。作りたいものははっきりしているし、やるべきことはそれほど多くないのに、色々とあって面倒くさい。
とは言うものの、今はがむしゃらに知識を吸収するのみ。登山で言えばまだ２〜３合目を歩いているところ。
まだ林の中を歩いているから景色も開けないし、どこに向かっているのかすらわからないし、この先どういう景色が広がっているのかまったくわからない。
今後やるべきことは、
・AppMethodを使ってPDICコードの完成度を高める
・NDKを使って開発環境に慣れ、PDICのJNIを作る
・JavaGUI@AndroidStudioを使ってGUIのお勉強
この三本立て。ちょっと重いかな。開発者が三人いればここで分担できるんだけど。
そんな中、AppMethodを起動しようとすると、「コンポーネント名に"ActionLi{t1"は使えません」とか言うわけのわからんメッセージが出た後、例外メッセージが出て終了してしまう。どこかに誤まって文字を入力してしまったか？（でもそんな文字列を誤まって打たないよなー）だとしても、AndroidStudioと違って前回開いた状態に戻すわけではないから自分が作ったプロジェクトとは無関係のはず。険しいなぁ。。それともAppMethodはもう諦めてNDKに進め、っていうことなのだろうか？
AppMethodが起動しなくなったのはちょっと厳しいな。。再インストールしかないね。
※→試用期限が切れたためだった。
→PC再起動したらAppMethodが立ち上がった。しかし実行しようとすると落ちる。
→AppMethodの試用期限が切れていただけでした。（まだ３０日経っていないぞ？）
しかもうちのXperiaは6.4インチだから無料版として使えないのでしたorz
2015.4.1
ということでAppMethodは6インチ以下のデバイスを手に入れない限り、使えなくなってしまった。
C側のデバッグをJava/JNI/C++というのはやはりきついので、Javaは横に置いて、Nativeアプリから始めようか。
と思ったが、結局それだとlog出力しかできないので、最小のJavaGUI＋JNIがいいだろうか？
どちらにせよndk-buildでビルドすることには変わりはないし、完全Nativeである利点はほとんどないだろう？
しばらくは、
・AndroidStudioで最小限のJavaGUIとJNI/C++でC++側の開発
でいいかな。ndk-buildを使ってコマンドラインでコンパイル、AndroidStudioから実行。
デバッグは面倒だけどしょうがない。
そこで早速やってみたが、javahがなかなか通らない、実行するとJNI呼び出し時に落ちる。一体Java側はどういう関数を期待しているんだ？？
例外のメッセージに出してくれたら良いのにな。
それよりもとにかくjavah。JNIの関数をどういう定義にしたらいいのかわからない。「javah android」でググってもダメ？
NDKに関する書籍は３冊ほどあるけど、どのやり方で定義しても実行時に落ちる。javah、javah。。。
これはまた明日考えよう。。
2015.4.2
動いた。AndroidStudioの簡易アプリでJNIが動いた。
結局javahはいくらやっても通らないため、手打ちで関数を定義したら動いた^=^
javahが使えないのはちょっと面倒だけど、できないことはない。（最悪Windows用のJNIを作ってコピペすればいい）
これでようやくAndroidStudioベースでJNI開発ができる！
簡易JavaGUIからテストコードを書いて必要なJNIを一つずつ記述・テストを続け、最終的なGUIとリンクすればいけるはず！？
3.26から始めた作業はようやく落ち着いた。AppMethodはなくても大丈夫だ。
しかし最近のAndroid端末は安い。Amazonだと４インチが１万円で買える。テスト用に購入しようかな。。
PDIC Android版は大型のタブレットより、小型で片手でできるようなものを目指しているから。
（大きいタブレットはWindows8で、現在のPDIC/Unicodeを使えばいいと思う。Androidである必要性はあまりないかと）
2015.4.3
AppMethod(C++Builder)に移植したPDICコードをAndroidStudio+JNIへの移植を開始。
予定より一週間程度遅れている。（開発環境で右往左往したためだ）
同じAndroidでもAppMethodで通ったはずのコードがcompile error。
エラーがたくさん出る出る！
C++Builder固有の定義が意外と多い。
コマンドラインでコンパイル→ファイルを開いてエラー行へジャンプ
・・・この作業面倒x_x
→秀丸の「プログラム実行」で普通にできました^-^
2015.4.4
コンパイルエラーの多くは、UNICODEなどのC++Builderでは当たり前に定義していたものがなかった、など。
２０年以上使い込んできた秘伝の(?)共通ライブラリのコンパイルが通ったので、いよいよPDIC本体のビルド。
この作業もあと２〜３日くらいで終わるかな。
そうしたらJNIを作成し、簡易GUIアプリで一つずつ動作テスト。
これで一週間くらいかな？
2015.4.5
今日もPDIC本体の移植(?)作業。
基本ライブラリのコンパイルが通ったため多くのコードが変更なくコンパイルが通る。
ちょっと引っかかったのが、
・日本語文字列定義→UTF8で保存することで対応。コメントの日本語ですらエラーになってしまう場合がある
・dynamic_castが使えない→代替処理
など。
今日で半分以上が完了。
2015.4.6
例外(try〜catch)が無効だからコンパイルできないらしい。
JNIは例外が使えないのか？
幸い、自分は例外を使わない人なのでそれに引っかかるコードはほとんどないのだが。。
例外処理を知ってからかれこれ２０年以上は経つけど、いまだに例外の利点が良くわからない。
メモリの不正アクセスなど、想定外の動作をcatchできるという点ではいいと思うけど、例外を積極的に利用したコーディングにはどうしても抵抗がある。
例外処理が適切にされていれば問題ないが、例外の例外、つまり想定外の例外が発生しているとcatchはしているけど、発生場所が自分が書いたコードでないと探すのに大変苦労する（デバッガーにも依るが大抵の場合発生場所はわからない）。小さなアプリなら問題ないが、大規模になると大変。
2015.4.7
C++側の移植作業がほぼ終わった。(リンク時のmultiple definitionの意味がまったくわからない？？大量に出てくるがそんなところに宣言していないぞ？）
それが解決できれば次はいよいよ簡易GUIアプリと接続してテストだ！
2015.4.8
今日はRAD Studio XE8の発売。Androidに関しては特に大きな変更はなさそう。
C++BuilderのVUP料金が￥67,000！もうこれは個人レベルで使う代物ではなくなっている。。
重複エラーは使用していない関数をinlineをつけずに宣言していたため。C++Builderは使用しない関数は無視するから問題がなかった。
リンクまでOK！
合計約110個のcppファイル。
簡易GUIから実行してみたが、dlopen failed: cannot locate symbol "srand" ...などと言われる。
srand → srand48
rand →lrand48
に変更することでOK
これで簡易GUIアプリが起動できた！
JNI側の基本初期化処理も実行でき、次なる問題は辞書ファイルなどはどこに配置するんだろう？(C++Builderのときと同じ悩みが・・・）
これが通れば、あとはGUIにテキスト入力欄と一覧表示を追加＆更新してAppMethodと同じレベルになるぞ。
2015.4.9
NDKでのファイル処理を調べてみた。（あくまで印象レベル、正確な仕組みが良くわからん。辞書のようなデータベースファイルを扱うような場合）
asset ・・・ リソースという扱いで、AssetManager経由でアクセス（するしかない？）
sdcard ・・・ fopenを使ったアクセスができるらしい
assetはapkから展開されたファイルの置き場所で、readonly?、通常のファイルアクセスができない？メモリ不足になったらActivityが破棄されるように、assetも破棄されるのではないか？
C++Builderの付属ファイルはパスに"asset"とあるけど、assetに配置されたわけではなく、assetに配置されたファイルをコピーしているのでは？（今は実行できないので確認できない）
ググるとAssetManager以外の利用方法はコピーしてから、って言うパターンが多いような気がする。
assetは一体何者なんだ？もし本当にreadonlyだったらsdcardかどこかにコピーしてから利用するのがよさそう。（面倒だけど）
ただネット情報はやや古いようなので、4.0以降はどうなのかはっきりしない。。
とにかく一つ言えることは、AssetManager_xxx でファイルアクセスするようなのはだめ。ファイル処理をすべてそれに書き換える必要がある。まったく同等に扱えるというのなら仕方なくやってもいいが、そんなことはないだろう。同等で扱えるくらいならファイル処理関数の中で違いを吸収すれば言いだけの話(Linuxは元々そういう思想だろう？）。それをアプリ側に要求するのはおかしい。Googleならそんなアホな仕様にしないと思うので、assetに対する自分の理解がまだ足りないのだろう。。（アホな仕様だったらAndroid開発はやめる（笑）
ここは鬼門だな。。
手元にあるAndroid書籍ではこのような話は少ない。
ここをクリアできればあとは一般的な処理がほとんどなので一気に進めることができると思うが。。
そもそもAndroidはLinuxなんだから、installしたファイルを直接read/write openするというのは変。
（Windowsならunzipしたファイルを直接実行、付属ファイルを直接編集は当たり前だが）
やはり、assetに配置されたファイルをsdcardにコピーして利用するっていうのでとりあえず進めてみようか？
初期化時にコピーすればいいだけなので無駄だとしても簡単な解決策だ。（詳細がわかったら最適な方法に置き換える）
2015.4.10
前日に書いたとおり、AssetManagerを使ってassetからsdcardにコピーしてとりあえずやってみた。が、
AssetManagerの渡し方がわからない。
Java側：
AssetManager assetManager = getAssets();
nativeJni(assetManager);
C側：
JNIEXPORT jint JNICALL Java_com_xxx_nativeJni(JNIEnv* env, jobject assetManager)
{
AssetManager *mgr = AAssetManager_fromJava(env, assetManager);
// mgrがNULL!?
}
何が悪い？
ググってもcomplete codeが見つからない、断片的なものばっかりなのでわからない。。
→やっとわかった。
JNIEXPORT jint JNICALL Java_com_xxx_nativeJni(JNIEnv* env, jclass thiz, jobject assetManager)
をjclass引数を追加する必要がありました。
しかし、sdcardへのファイルがオープンできない。
fopen("/sdcard/Sample.dic", "w");
はダメ？
2015.4.11
/sdcardのアクセス問題。
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
をAndroidManifest.xmlに追加すればOK
(C++Builderではdefaultで色んなpermissionが設定してあった）
簡易JavaGUIで進めるつもりだったが、以前作成しておいたPDIC GUI第一弾で作りこむことにした。
JNIからJava classのcallbackをしたいと思って、NewGlobalRef()を使ってobjectを保持するのは良いけど、methodの呼び出しにenvが必要だよね？
任意のタイミングでcallbackをしたいのに、envがないとCallxxxMethod()が呼び出せないじゃないか！！
もちろん何かしらのJNI呼び出しのつながりでcallbackする（つまり別スレッドではない）からenvを渡せば良いけど、面倒だな。。
→とりあえずそうした。
callbackするところまで書いたが、GetMethodID()で返る値がNULL。
何がいけないのだろうか。。
これが通れば（なんちゃって）インクリメンタルサーチが動くはず。
2015.4.12
GetMethodID()の戻り値がNULL→またまたJNIの引数に"jobject thiz"がなかった。javahが使えればこんなミスはないだろうに。。
現在インクリメンタルサーチを実現すべく、Javaのcallbackを実装中。。
検索結果更新のcallbackが動いた！
しかし表示に反映されない。。
ひとつ気がついたことは、GetObjectClass()は引数がグローバルリファレンスであってもローカルリファレンスなんだね。GetMethodID()はobjectがグローバルならこれもグローバルのようだけど。callbackはややこしい。。それよりは普通にgetしたほうがいいのかな？
2015.4.15
ListViewにAdapterを追加して（これが面倒）、項目を追加したけど表示されない。（もちろんnotifyDataSetChange()は呼んでいる)
何が悪いんだろう。。layoutに問題があるのだろうか。。
2015.4.16
相変わらずListViewが期待通りに動かない。（やりたいことはすっごく簡単なのに）
一つわかったことは、Adapterのコンストラクタの第３引数にリスト項目の初期値を渡した後、adapter.add("item")
とやるとunsupported 例外が発生する！？
え〜っ！？AndroidのListViewってそんな変な仕様なの？
誰だこんな変な仕様にした奴は？出てこい！！
String[] members = { "mhidaka", "rongon_xp", "kacchi0516",
"kobashinG"};
ArrayAdapter<String> adapter = new ArrayAdapter<String>(this,android.R.layout.simple_list_item_1,
members);
adapter.add("Copy Text"); ←ここで落ちる
なんで？
"Unsupported"と言われても普通のやり方でしょう？
ListViewに関する記事やらなにやら色々と読んできたけど、やってはいけない事項にこういうことはなかったけどな。。
2015.4.17
AMD CPUでEmulatorは使えないものと諦めていましたが、考えてみればAndroidはLinuxじゃないか。ということは普通にVMWare上で動くのでは？
とググって見たらありました。しかし、色んなPCにインストールしてみましたが、色んなところに躓き、いまだにまともに動くAndroidはできあがっていませんorz
セットアップ途中で先に進まなくなったり、セットアップは完了したけどホーム画面から先に進めない、マウスで操作できない、などなど。（普通のLinuxに比べたら）意外とハードルが高い。
最近は色んなところではまってばかりいるx_x
ListView問題。
やはり、うまくいかない。野良サンプルコードを流用して簡単なアプリを作ったがやはりダメ。
そこでListViewのadapterの初期値設定問題は置いといて、コードを眺めていたところ、デフォルトで生成されるPlaceholderFragmentが気になり、これをコメントアウトしたところ、
インクリメンタルサーチの結果が表示された！！アラビア語もロシア語も正しく表示されます。
前から気になっていたが、このPlaceholderFragmentって何？
しかしスクロールはしてくれない。これは自前で用意しないといけないんだよな。。まぁWindows版PDICも似たような感じだったから（無限スクロール仕様）、大したことは無いけど面倒くせぇ。→いやスクロールした。何かおかしい？
それにしても色んな落とし穴があるなぁ。今まで色んな本やサイトを読んだけど、そんなことは見たことがない。Androidはもう少しまともなものかと思ったけど意外とダメ？それとも紹介サイトや書籍がダメ？こういう痛いところまで説明している書籍が本物だな。そういう書籍を探しにまた本屋に行ってみよう。
とにかく、第一関門は突破できた。JavaGUIからインクリメンタルサーチができるようになったのだ。
これからしばらくはインクリメンタルサーチの完成度を上げることにする。
それができたらポップアップ検索の実装に入ろう。こちらはちょっと難しい。
2015.4.18
インクリメンタルサーチの動作安定化。
現在の問題点：
・たまに落ちるときがある（再現性無し）
・"b"を入力したときと、"a"を入力して一旦削除、"b"を入力したときの検索結果が異なる（マルコフモデル状態？）
・"a"を入力したときにすべての検索結果をスクロールして表示されない
2015.4.19
VMWareでandroidを動かす。これを参考。
自宅のPCではうまく動作できた。インストール後にrebootしたからだろうか？
さて今の一番の問題はインクリメンタルサーチ。
現在抱えている問題は、ListViewそのものの扱い方の問題。
AndroidのListViewは意外とクセがあることがわかったが、教科書に書いてあるような理解レベルでは難しそう。
（まともなプログラマーならそのクセをできる限り排除したいと思うのだが）
書籍は体系的には学べるけど、本気で使おうとなると書籍でもネットでもなく、自分自身が調べ上げないとわからないことがある。
Windowsのときもそうだったけど、Androidもどろどろしたところをいじらないといけないのかな。。
2015.4.21
やっぱりJNIからはコールバックのほうが良いかな。ポーリングで取得する方式だとロジックがJava側に移ってしまうので面倒くさい。
逆にコールバック方式だとコールバックする関数が増えてやや煩雑になるけど。
久しぶりにPDICを実行したらインクリメンタルサーチが動かない？？
何も変更していないはずなんだけどな。。
2015.4.22
開発用PCをスタンバイ状態にしようとしたら"INTERNAL_POWER_ERROR"が発生してBlue Screen！
再起動したらHDDが異常に遅い。DiskMarkで0.8MB/s!!落ち着いた頃に再度測ったら28MB/s! これはUSB2.0 driveじゃないか。
再起動を繰り返したらBIOS画面でフリーズ。
これはHDDか何かが悪い、交換するしかないな。と思って電源を落としてしばらくして再起動したら何事もなかったかのようにサクサク動作。
とりあえず復帰したけど故障の前兆かもしれない。
気を取り直してAndroidStudioから実行したけど、インクリメンタルサーチが動作せず。
再起動すれば直ると思ったけど、これは本気でデバッグするしかないね。。
2015.4.23
インクリメンタルサーチが動かなくなったのではなく、昔のPDICが動いているだけ。
一体何が起きているのだろう？？
PDICをアンインストールしても昔のまま。
→Clean buildしたら動くようになった。というより起動時に落ちるようになった。timestampでも狂っていたのだろうか？
あれ？clean buildしたせいか、android.mkファイルが消えている？？
→.soファイルなども削除されている！
→android.mkを復活してJNI buildしたら起動できるようになりました。ホッ
そしてインクリメンタルサーチも何事もなかったかのように正常に動きました。
無駄な３日間だった。PCの不調でtimestampか何かが狂って最終ファイルが更新されなくなったのだろう。。
なんて人騒がせな。
さて気を取り直して、何をやるんだったっけ？^^;
そうそう、入力文字にあわせて選択・スクロールするようにしているんだが、とんでもない値が渡されてくるな。。
Windows版からの変更は何もないはずなのに。
きっとどこかちょっと間違っているだけだと思うのでそれを探すことに。
2015.4.24
現在抱えている問題。
・たまに落ちるときがある（再現性無し）
・２文字以上の入力した結果が正しくない
・選択状態を示す変数がゴミ状態
PCの調子はやはり悪い。今まで問題を起こしたのはOSが入っているHDDが原因だったみたい。
ちなみに今まで使っていたシステム用のHDDは７年前のHDD！
まぁそろそろおかしくなっても不思議ではないかな。
ということで128GBのSSDを注文しました。
トラブルで時間をとられるくらいなら少しお金を払ってでも安定したものに。
2015.4.26
システムディスクを入れ替え。OSの再インストール中。。
2015.4.28
また不安定になってしまい、OSを再々度インストール中。。
2015.4.30
ようやく安定して動くようになったかな？
まだAndroidStudioのインストールまではできず。
2015.5.19
開発用PCがようやく以前の状態に戻ってきた。GW休暇もあったけど、一ヶ月近いブランク！
開発を再開します！
2015.5.20
とは言うものの、現在のインクリメンタルサーチには色々と問題があってどれから解決していいのやら。
たとえば"J"を入力すると"Japanes"という見出し語が出てくるが、"Japanese"と正しく表示されないし、「こんにちは」という訳語が出てこない。
まずはそれからやってみようか？
そもそもこれはAndroid固有の問題というより、PDIC固有の問題が多い。（と思う)
そんなところはさっさと片付けたいところ。
それよりちょっと前から気になっているのは、JNIからcallbackされたときに渡された文字列をSystem.out.printlnすると文字化けする。
文字化けはするけどそれをそのままListViewに渡すと（ほぼ）正しく表示される。
log出力とListViewが扱う文字コードが違うのか？
化けた様子を見るとUTF16を別の文字コードで表示しているような感じだが。。。
まずはそれを解決しよう。とにかくログがまともに使えないというのはデバッグにおいて致命的。
2015.5.21
log出力の文字化け問題は、Java側ではなくC++側でUNICODE→UTF8変換することで正しく出せるようになった。
インクリメンタルサーチの結果が正しく出ない原因は、JNIのNewString()で渡す文字列の長さが少なかった。なぜか２倍にすると正しく出る！？(原因不明)
入力文字と異なる検索結果が出る原因がわかった。入力欄を空欄にしたにもかかわらず、内部(JNI側)では検索継続と判断してそれに続く見出し語が検索結果としてJava側にcallbackしてしまうためだ。
clear()を呼び出して初期状態に戻しているのだが、検索状態はstop状態で完全にクリアしていない。Windows版では問題なかったはずだが、何か手順が違うのかもしれない。とりあえずそれを追加したら入力状態と異なる結果は出なくなった！
ただし２文字以上入力したときも入力文字で始まる見出し語ではなく、検索途中からの結果が表示されてしまう。やはり何かが足りないような気がする。これが解決すれば直前の初期化処理は不要になるだろう。
これが解決できれば
・Android特有のスクロール処理に変更する（表示項目の使いまわし）
・入力文字列にあわせた選択表示
・検索結果表示体裁の検討
だろうか。
このあたりは今週中に終わらせ、来週からはいよいよメインのポップアップ検索ウィンドウだ！
2015.5.25
ListView問題。
PDICでやりたいことは、入力した文字列に近い見出し語をListViewのトップに表示し、あとは辞書をめくるように上下に自由自在にスクロールしたいだけなんだが・・・・
サンプルコードを見ると動的なListViewに関するものはあまり見かけないように見える。
サンプルコードの多くはstaticに項目を設定するものばかりで、以前にも書いたとおりstaticに設定したListViewに対してdynamicに更新しようとすると例外が発生する。
ListViewには色々と制約があるような気がするけど、今のところそれがはっきりしない。
ということで、PDICからちょっと離れてListViewサンプルを漁ってみようかと思う。
2015.5.29
なかなかListViewのお勉強が進まないx_x
ネットのサンプルを探してもどれが適切なものなのか知識量が少ない私には判断ができない。
やりたいことは難しいことではないのだが・・・
ネット情報では当てにならないので明日本屋に行ってListViewについてしっかり説明してある本を買ってこよう。
インクリメンタルサーチの肝だから、ここはしっかりと調べないと。
2015.6.1
ということで購入しました。「Android アプリ開発パーフェクトマスター」（秀和システム）
初心者向けで、知っている部分もかなり多いのですが、
・基本的な部分をしっかり解説している
・ListViewについてもそこそこ書いてある
ということで購入。ただListViewについてはこれだけでは不足なのでほかの書籍も買う予定。
SimpleAdapterを使ったカスタム表示方法は理解できたのですが、後から項目を追加・削除する方法がわからない！！
GoogleサイトのSimpleAdapterクラスを見てもそられしいのが見つからない。。
2015.6.4
書籍を読んでも今ひとつ。やっぱりネット、それも日本語のものでまともなものが無い。
ということで英語に限定し、"ListView android tutorial"でググると出てくる出てくる。
この辺を片っ端から学んでみる。日本語の書籍ではこれらを超えることはできないだろう。
しかし、Androidはちょっと難しいなぁ。Java自体はC++より簡単だけど、C++Builderのような洗練された簡単さがAndroidStudioには無い。
そういうよく使うものはListViewクラスの中に隠蔽して、使いやすくすればいいと思うんだけど、そういう文化ではないらしい。
基本的なものは用意するから後は使う側で好きなように使って、という感じ。それはそれでいいけど。。
とにかく予定よりかなり遅れてしまっているので、ここで巻き返しを図らねば。
予定では今頃、インクリメンタルサーチはもちろん、ポップアップ検索や、辞書設定、さらには検索履歴まで出せるようになっていたはずだ。
ListViewでかなり時間をとられている。
2015.6.7
ListViewに関してはだいたいわかったつもり状態。
しかし現在抱えている問題はPDIC固有の問題、ということがよくわかった。
ということでデバッグを進め、以前から抱えている問題のいくつかは解決。
4.18の状態からようやく進んだ。２ヶ月近くも止まっていた！
さてこれからは、
・現在抱えている問題の解決 - ２文字目を入力すると一覧表示が消える、くらいしかない？
・結果表示の体裁の改善 - これは勉強したおかげで難しくないだろう(Androidでできることがわかった）
・表示処理の高速化 - これも同様
これでとりあえずインクリメンタルサーチは一時休止にする。
この辺を一週間程度で終わらせ、次はいよいよポップアップ検索ウィンドウだ！
ようやく目処が立った。
ちなみにもう一つ書籍を購入。
「改訂2版 Android SDK逆引きハンドブック」
これは前々から目をつけていたもの。図書館には初版本があるけど、SDK4.0に対応していないからあまり参考にならない。なので購入しました。
書籍に関してはこれで十分かな？（ほかKindole版が２冊）
2015.6.8
インクリメンタルサーチが期待通りの動きになるようになった！！
苦節２ヶ月、ほとんどの原因はtest/debug codeだった^^;
残すは、
・無限スクロール対応、または絞り込み検索？
・表示の体裁
・・・これが悩ましい。
・完全一致した単語は太字表示？
・２行で表示？タップするとexpandするとか？
これは後回しにしてポップ検索ウィンドウに取り掛かろうか？
2015.6.9
ポップアップ検索ウィンドウの実装を始めよう。
最終的にはメインのインクリメンタルサーチとポップアップ検索ウィンドウはfragmentにして同じActivity上で動作させようと思うけど、とりあえず異なる独立したActivityで作ろうと思う。そのほうがデバッグはやりやすいと思うし、本当に一緒のActivityにしたほうがいいと思ったときに統合する。（もしかすると一緒にする必要性が低いかもしれないし）
現状のインクリメンタルサーチは完成には程遠いけど、片手間で改善していこう。
ということで、今後の方針が決定。
2015.6.11
現在ポップアップ検索ウィンドウの検討中ですが、今後のスケジュール。
・ポップアップ検索ウィンドウでポップアップ検索 - 7/B
・辞書設定 - 7/E
・不規則変化辞書、テキスト形式辞書を使った検索 - 8/B
・クラウドを使った履歴などの共有 - 8/E
・一般利用に向けた完成度を上げる作業＝α版 - 9/M
・β版 - 10/M
それほど無茶なスケジュールだとは思わないけど、誤差は一ヶ月くらいかな？
正式版は今年中！？
2015.6.14
ポップアップ検索ウィンドウ実装中。
ファイルからサンプルテキストを読み込み、タップを検知するところまで実装。
あとはタップした近辺の単語を取得、検索してその結果を表示するところ。
いずれもそれほど難しくないと思うので、今週中にできるだろう。（見た目は別）
勉強が進んだおかげでAndroidプログラミングの敷居もだいぶ下がってきた。
が、現在調べているのはTextViewで選択されているテキストを取得する方法。
getSelectedText()みたいなメソッドがあるかと思いきや、意外とそういうのが見つからない。
ちょっと捻ったメソッドで取得できそうな気がするけど、だったら素直にgetSelectedText()とか、getRangedText()とかわかりやすいメソッドを用意したらどうよ？
なんでそんなところに妙な小細工するかなぁ。。。
2015.6.15
タップした付近の文字列取得。
そういうメソッドはどうやらなさそう。getText()で取得して、substring()で抽出するしかなさそう。効率悪そうだけど、Javaだとそれほどでもないのだろうか？
さて２〜３週間と見積もっていたポップアップ検索はやはり今週中にできそう。
それができたら辞書設定という面倒な仕様を考える。
ここは一番難しい。なぜなら、
・初めてPDICを使用する人がとにかくすぐに利用してみたい場合
・PDICというものがわかって、自由自在に使用したい辞書を使いたい場合
このどちらかであり、これを両立させる必要がある。
Windows版では辞書グループをメインに系統立てたUIにしているけど、Android版ではそうしないほうがいいだろう。
辞書グループという概念はそのまま使うが、使い始めは１つの辞書グループに追加していくという形。
複数の辞書グループを使いたい人に限り、追加という形で用意するという感じ。
辞書グループという概念は基本的に意識させない。
2015.6.16
今日はいよいよ検索部。
だいぶ昔に作ったポップアップ検索部をそのまま利用しようと思ったが、自分が作ったものをすっかり忘れている^^;
ようやく思い出したので、明日はそれを使って検索＆結果の取得部分を作成、ようやくやりたいことの足がかりができる。
2015.6.17
ポップアップ検索の検索部を実装してみたが、検索部分で落ちてしまう。-_-
明日その原因を調べよう。
2015.6.19
ようやくポップアップ検索が動いた！
文中の"the first time"の"first"をタップしたところ。下の枠にヒット候補の一覧が表示されている。ヒット候補にthe
first timeも出ている。
実際にはポップアップではありませんが、最終的にもポップアップするような感じにならないだろう。ポップアップ検索はやめて「タッチ検索」でいいだろうか？
もちろんこれで終わりではなくまだまだやることはたくさんある。
ポップアップ検索の基本機能が動いたので、次は辞書設定画面？
2015.6.20
JNIでbuffer overrunしたらアプリが落ちるのではなく、OSが再起動！！
Androidでそんなに脆弱なの？
不規則変化形辞書に対応。テキストファイルの読み込みに問題があったため、buffer overrunとなりOSが落ちていた。
wchar_t=UTF16前提のコードがまだ多く残っていたため、その修正に時間がかかった。
これで不規則変化単語があってもヒットするようになりました。
さて明日は何をやろうか？
2015.6.21
細かいところを変更した後、設定画面の実装へ。
設定画面は単純なものであれば簡単に実装できるらしい。
今のところ設定が必要なものは無いので、まずは辞書設定画面から。
辞書グループは１つ（なので辞書グループの概念は出さない）、辞書は最大３０個まで。
辞書の利用方法はダウンロードと、ファイルからの追加。
この中で難しいのは、
・辞書ダウンロード
・ファイルからの追加方法（Windowsだと簡単だけどAndroidはどうなんだろう？）
これさえ実装できればあとは簡単（なはず）。
Androidの勉強を始めて４ヶ月余りだが、Androidプログラミングにだいぶ慣れてきた。
ちょっとした画面ならすぐに作られるレベルになった。
当初C++Builderのような簡単な開発環境がいい、と思っていたが今はテキストベースのxml+javaでもそれほど苦にならない。むしろ簡単だと感じる。
Windowsの場合は一つ一つの部品をpixel単位で配置・サイズ調整しなければいけないが、Androidはそういう発想ではないため、そのような面倒臭さから開放されている。
だからC++Builderという選択をする必要は無かったし、しなくて良かった。
今週は、先ほど書いたとおり、辞書ダウンロード機能とサーバーの準備、ファイルの追加を進める。一週間でできるかどうかは微妙なところ。（Windowsに比べれば楽だろうな、と楽観的）
という観点から今後の予定を再び。
・辞書設定 - 7/B
・検索履歴 - 7/M
・ポップアップ検索ウィンドウのbookmark - 7/E
・クラウドを使った履歴などの共有 - 8/B
・テキスト形式辞書を使った検索 - 8/M
・最適化、GUIのブラッシュアップ - 9/B
・α版 - 9/M
・β版 - 10/M
予定より進んだけど、β版のスケジュールは変わっていない。今のところスケジュールの精度はかなり粗いので。
2015.6.22
辞書のダウンロード、辞書追加を実装しようと思ったけど、やや敷居が高いのでまずは普通の設定画面から。
そもそも設定情報はどうやって保存していいのかわからないし、どういう形式を保存できるのか知らない。
2015.6.23
設定はできるようになった。やはりWindowsに比べてsimpleだと思う。
余談：Windowsのレジストリの生のAPIで設定保存・復元なんかをやろうとしたら気が狂うと思う。そこでまずやらなければいけないことはそのアクセスのためのクラスを自前で作らないといけない。それを一発で作れたらいいけど、それは無理。試行錯誤してようやく使い物になる（自分の場合）。
AndroidプログラマーがWindowsで初めてC++(VisualStudio)でアプリを作ったら、気が狂うか、WindowsなんてクソOSだと思うだろうなぁ。
commit操作が要らないくらいで、あのレジストリAPIの複雑さに比べたら・・・
辞書ファイルの追加を実装しようと野良サンプルを使用してみた。
一応動いたがDialogベースのため、ディレクトリを移動するたびに画面が切り替わるのが鬱陶しい。
見た目は良くないが機能的には問題なさそうなのでしばらくはこれを使う。
最終的にはActivityにしたほうがいいだろう。
Dialogは初めて使ってみたが、画面遷移が多いファイル選択には向かないということがわかった。
Windowsでは目的がはっきりしているものはDialogにしたほうがいいのだが、
Androidではそれに加えて単一的な機能の場合に限定して利用したほうがよさそう。
辞書設定は7/Bの予定だけどなんとか今週中に実現したい。（あくまで機能として）
2015.6.24
今日は会社をずる休みしたので^^;、ちょっと進んだ。
辞書ファイルの追加を実装、さらにネットワークからの辞書ダウンロードまで実装。
あとは辞書ファイルの展開、追加処理。
それができたらそれを使って辞書のオープン処理。
あと１〜２日くらいでできるかな？
やはりJavaは楽だ。C++のような妙なミスが無い。それにクラスライブラリがまともだから使いやすい。(C++はboostがあるけど、あの中でまともに使えるクラスはどれくらいあるんだ？）
2015.6.25
ダウンロードした辞書ファイル(PDIファイル)をunzipする処理を実装したが、ファイル名の最後にゴミ文字が２文字ついていてうまく動かない。zipファイルの中にはそんなゴミは無い。一体なんだろう？
→しょうがないのでtrim()でそぎ落とす。→動いた！
これで大雑把な機能としてはほぼ実装できた。
実験的なコードでごちゃごちゃしてきたので、これを整理。
そして辞書削除など辞書設定編集作業を充実させる。
それができたらそれらのファイルを使って辞書ファイルのオープン、エラー処理。
これを今月中に終わらせたい。
辞書設定には色々とやることがあるので、予定通り7/B完になるかもしれない。
2015.6.26
Windowsのようなポップアップメニューは無いものだろうか？→と思ったらそのままのPopupMenuがあった。
ただこの野良コードそのままでは動かないけど、これなら使える。
2015.6.28
辞書設定周りは、必要最低限はできるようになった。（ネットからの辞書ダウンロード、ファイルからの追加など）
そして任意の辞書ファイルを開けるようにJNI周りにちょっと変更を入れたら、身に覚えの無いビルドエラーがたくさん。
一体何が悪い？？
まぁそこそこ進んだし、このエラーもきっとどうでもいい違いで発生しているんだろう。
このくだらないエラーが解決できれば、辞書エラー処理、テキスト辞書対応くらい。
今週中にはいずれもできるだろう。
2015.6.29
.o .dファイルをすべて消去してビルドしてもだめだったのに、.cppファイルのいくつかを保存しなおしてビルドしたらundefinedエラーは無くなった？？
そもそもJNIのclean buildってどうやるんだ？
→ndk-build.cmd <hoge hoge parameters> clean
と最後にcleanをつければいいみたい。
→android.mkのtouchでもいける
辞書設定周りもあと一息、辞書オープン処理を実装。しかし、検索をすると落ちる。
それじゃ以前からの辞書に戻すと・・・検索結果が出てこない？？
以前JNI callbackを整理したからそのときにデグったかもしれない。。
ということで辞書設定はひとまず通ったけど、デグレの修復をしないといけない。
2015.6.30
以前の辞書に戻して検索ができない問題は、今回の対応によるデグレ。（複数のパスから探す処理を削除していたため）
それと、任意の辞書を指定しての辞書検索が落ちる問題は解決したが、原因不明？？(wsdisp.cppを再コンパイルしたらOK）
どうやら、何かの環境が変わり、リビルドが必要にもかかわらず差分ビルドをしていることが原因ではないかと思われる。
→clean buildしておく
これで7/Bに予定していた辞書設定は（まだ色々とあるけど）とりあえず達成。
マルチ辞書で動くし、不規則変化もヒット。
試しに英辞郎を入れたらサクサク動く！ポップアップ検索もタッチと同時に瞬時に出てくる！
恐らくフリーの辞書アプリとしてはこのレベルで公開しても問題ないだろうし、ここまでできるアプリは見たことが無い。
明日７月からはdropboxを使ったファイルのクラウド共有の実装に入ろうと思う。（予定と違うぞ？）
それと同時に辞書設定の改善も。
クラウドでファイルの共有ができると、Windows版PDICと共有ができてとっても便利。
そういうAndroid辞書検索アプリもたまに見かけるけど、PDICでは辞書だけでなく、検索履歴、bookmarkなどデータのほとんどを共有できるようにしたい。
ということで、次はこれを優先的に実装するつもり。
2015.7.1
DropboxのSync APIを使った実装を始めた。野良コードを使ったけど、deprecatedが多くてこれはだめだ。
Sync APIのdocucmentをしっかり読んでからもう一度実装し直そうと思う。
2015.7.2
Dropboxに対応中。適切なサンプルが見つからないのでうまくいかない。仕組みも良くわからない。。
access tokenを取得するためになぜアカウントの中にさらにアプリを登録する必要があるんだ？
それはともかく、Dropboxはオプション機能として有料化してはどうだろうか？
Dropboxを使用しない人はもちろん無料で。
Dropbox自体、いつまで続くサービスなのかよくわからないから、おまけ程度の扱いでいいと思うし。
Dropboxはもう少し時間をかけて取り組むことにして、メインの開発はPDIC本体の機能を進めていこう。
2015.7.3
Dropboxのほうは仕様書を読んでもよくわからん。試行錯誤しながら実装したほうがよさそう。
恐らくDropboxと連携するAndroidアプリが少ないんじゃないかな？そもそも。
現在はテキスト形式辞書に対応中。オープン途中で落ちてしまう。原因はテキストファイルの読み込みで落ちるというプリミティブなところだった。
明日はこれを解決し、そうすればそれほど苦労なく動いてくれるだろう。
テキスト形式辞書が動いたら、次は検索履歴をやってみる。やる気が萎えたらポップアップ検索ウィンドウのbookmark機能を実装する^^
2015.7.4
落ちる原因、バイト数を文字数に計算するマクロで、逆の計算をやっていた！！
2015.7.5
落ちる原因はまだあった。辞書制御オブジェクトを二重開放していたことが原因。(Windowsとifdefで切り替えていた)
少し時間がかかったが、これでテキスト形式辞書にも対応できた！！
【開発用PCの不調】
開発用のRAID HDD(2TBx2)の調子が悪い。CrystalDiscMarkでSequentialWriteが5MB/Sec！！(WD10EZRX)
HDDの音を聞くとretryしている感じ。
昨年の８月に購入したばかりなのに！！
壊れる前兆だと思われるので新しいHDDを注文。(MD04ACA200)
数年前までHDDの寿命は４〜５年程度だったけど、最近のHDDは１〜２年で壊れる！？(SeagateとWesternDigitalの安いモデル)
またすぐ壊れたらNAS用のものにしようかな。。
ともあれ、テキスト形式辞書ができたので、次は検索履歴＆Dropbox対応だ！
で、再びDropbox対応を再開。
authenticationは通ったみたいなので、ファイルの一覧取得をしてみる。
野良コードを参考にDropboxAPI.search()を呼び出すと例外で落ちる。
documentに書いてあるすべての例外をcatchしようとするがどれもスルー。
undocumentedなことは一切やっているつもりは無いのになぁ。
で、作り直したDropboxのappで別のkeyを使ったところ、authenticationで落ちる。
こういうのは大体originがろくな情報を提供しないから野良コードに頼るしかないけど、情報が少ないので何が悪いのか良くわからない。
しかもDropboxは「今までのAPIが使いにくいからv2を提供します」とか言っているけど、まぁだいたいこうういうのは自社都合で決めている。
あと一週間くらいは格闘してみるけど、もし駄目だったらGoogle Driveに切り替えようかな。。
Google Driveも駄目だったら自作するしかないか？？
自分がやりたいことはWindowsアプリなどとファイルを共有したいだけなので、自作したほうがいいかもね。。
2015.7.6
【続・開発用HDDの不調】
届いたHDD２台のうちの１台が初期不良。
症状として、電源投入後いきなり、ピッ、ピッ、ピッという音がHDDから！
「なんだ、時限爆弾か！」と思ったが、しばらくすると止んだ。
すると今度は大き目のシーク音のような音が0.5秒おきに継続的にする。
（片方のHDDは静か）
Windows7を立ち上げ、formatするが、しばらくすると突然「未接続」状態に。相変わらず0.5秒おきの振動は止まない。
自作派の自分はこれまで何十台というHDDをインストールしてきたが、こんなにわかりやすいHDDの初期不良は初めて。
耐久性の高いと言われるHDD(MD04ACA200)を購入したが、大丈夫か？
ということでしばらく綱渡り状態で開発を続けることにします。→そのつもりだったけど書き込みがほとんどできなくなってしまった。
2015.7.7
初期不良のHDDは明日返品予定。
考えてみたら、HDD RAIDでソフト開発というのもそろそろ時代遅れだなぁ。それにHDDの交換を待つ時間ももったいないのでSSDを注文。
明日から開発が再開できるはず。
ソフト開発だけなら120GBで十分。ということで信頼性の高いIntel の535シリーズにしました。（ほかのSSDよりちょっと高いだけ）
これでシステム、ソフト開発、データ＋アプリが３ドライブに分散することになるので信頼性は上がる。
システムは再インストールが当たり前なので別ドライブ、ソフト開発は小さなアクセスが多数なのでSSDが吉（といってもほとんどキャッシュに乗るけど）、データ＋アプリは大きいのでHDD
RAIDが向く。
これで適切なドライブ構成になるかな。
2015.7.8
【続・開発用HDDの不調】
SSDが届いて開発環境をコピー。サクサク動くようになった！
体感的にはHDD RAIDより若干速くなった感じだけど、Android版PDIC/JNIのコンパイル時間はかなり短くなったような気がする。
正確に計測していませんが、１０分弱→５分弱くらいに短縮したかも？
さて、引き続きDropboxをやっているが状況は変わらず。
Dropbox SDKのsampleを使ってみるがそのままでは動かず。
本当にこれは動くものなんだろうか？
まずまともに動くものから探そう！
Dropboxはじっくりやらないといけないが、検索履歴はロジック部分は実装したし、残りのGUI部分はすぐに実現できると思うのでちょっとやる気が無い。
その次のbookmarkは開発版で公開しているWindows版にやや重いバグがあり、まずこちらを解決しないといけない。
したがって今のところAndroid版は大きな機能追加はなさそう。
地味なところをしばらく続けようかな。
2015.7.11
【続・開発用HDDの不調→解決？】
Intel SSDも突然ドライブが未接続状態になってしまう！
信頼できるIntel製のSSDですらこうなのだから、こりゃMotherBoard(MB)のSATAがおかしい以外に無い。ということでMBとCPUを交換！
PC履歴を調べたらなんと５年ぶり！昔は毎年のようにMB/CPUのグレードアップをしていたものだが。。
ちなみにAMD PhenomII X4 945からIntelCore i5 4460へのアップグレード。
効果のほどは起動は１分弱くらいから１０秒弱(Win7)、SSDは30%以上速くなり、PDIC/JNIのコンパイルも５分弱→３分弱に！
怪我の功名じゃないけどHDD不調をきっかけにシステムの大幅変更で開発環境は快適、安定、静かになった！！
それに今まで使っていたタワーケースにはケースFANが無かった！！
それがHDD不調の原因の一つかもしれないが。。
これで開発環境は正常に戻ったが、肝心のPDICがビルドできなくなった。xmlファイルの最初に￥x00が入ってしまうのだがそれを削除してもAndroidStudioが復活させてしまう？？
前の不安定な環境でどこかにゴミを仕込んでしまったのかもしれない。。
→連続した余計な￥x00の前に適当な文字列をAndroidStudioのエディターで入力・ビルドし、そしてその適当に入力した文字列を一緒に不正な￥x00を一緒に削除するとビルドが通った。
でわかったことは、AndroidStudioから実機で実行するまでの時間が３秒もかからなくなった！（今まで５秒くらい）
たったの２秒程度しかないけどデバッグサイクルが短くなることは嬉しい。
2015.7.12
【続・開発用HDDの不調→まだ解決していなかった？】
MB+CPUを交換して調子は非常に良くなった！しかも書き込みができなくなっていたRAID HDDも何も問題なくなった。初期不良で交換したHDDも届いたし、これですべて解決かと思いきや・・・
交換されたHDDもおかしい。しかも正常だと思っていたもう１台のHDDもおかしい！？
しかし確率的にそんなことはありえない。ということはMB/CPU側がおかしいことになるのだが、今回新たに購入したものだし、それに接続したほかのHDDは問題は無い。購入した店に初期不良で返品することはできるけど、さすがに３回連続の初期不良は無いだろう。。困ったx_x
個人的な事情はさておいて。
現在取り組んでいるのはListViewのAdapter。
UdacityのAndroid講座を見るとCursorAdapterを使っているようだが、一般的にはSQLiteのAdapterとして使っているらしい。今までArrayAdapter<String>を使っていたのでそのままでは置き換えができなさそう？
2015.7.13
【続・開発用HDDの不調→今度こそ解決】
調子の悪いHDDをもう一度つなぎなおしたところ、二台とも問題なし！？
原因は接触不良か何かで、HDD自体には問題なさそう。ということで一連の問題は解決！
ListViewのAdapterは野良コードを使ったけど落ちる。ViewHolderは良くないぞっていうことで野良コードを使ってみたのだが。。。
このレベルになると書籍には書いてないし、基礎知識が足りないせいか何が悪いのか良くわからない。
AndroidのListViewは独特でちょっと難しい。
2015.7.14
ListViewの高速化・効率化は動いた。参考にしたサイトは、
https://github.com/codepath/android_guides/wiki/Using-an-ArrayAdapter-with-ListView
https://www.bignerdranch.com/blog/customizing-android-listview-rows-subclassing/
http://qiita.com/mofumofu3n/items/28f8be64d39b20e69552
最終的には一番下のリンク先の形に近くなった。真ん中のサイトはItemViewをわざわざstatic宣言までする必要は無いだろう？ということで参考程度。
動かなかった原因はlayoutのxmlで指定するタグをURLのフルパス指定する必要があった。
次はインクリメンタルサーチ一覧の無限スクロール化。
少し苦労しそうだが、基本的に難しいところは無いはずなので、今週中にはできるだろう。
それが終わったら次はbookmark。
Windows版のbookmarkに重大な問題があったが、それらはほぼ解決できた（公開済み）。
Android版も対応できれば、Windows版とbookmarkを共有し、ポップアップ検索ウィンドウで英語学習ができるようになる。
再びスケジュール案。
6.21の予定のうち「辞書設定」「テキスト形式辞書」がほぼ完。8/Mまでだった予定を書き直すと、
・無限スクロール対応 - 7/M
・ポップアップ検索ウィンドウのbookmark - 7/E
・検索履歴 - 8/B
・クラウドを使った履歴などの共有 - 8/M
結局お尻は変わらない(笑)
その理由は意外とDropbox対応が難しいんじゃないか？というところ。
しかしそこまでできれば機能的にはLevel1の実装がほぼ終わることになる。
その後は全体的なbrush upに一ヶ月程度。それが終わればようやくα版レベルになるだろう。
ということを見越して現在はUIに関する書籍を読んでいる。
「Smashing Android UI レスポンシブUIとデザインパターン」
開発当初から気になっていたんだけど、ついに購入。
「レスポンシブって何？」っていうくらい時代遅れなエンジニアに成り下がっていたんだけど、翻訳はちゃんと日本語になっているし、読んでいて面白い。まだ３章程度しか読んでいないけど、自分に無かった概念が書いてあり、とても参考になる（と思う）。
2015.7.15
無限スクロールを実装中。
ListViewに現在表示している項目より前に登録されている非表示の項目を削除すると現在表示されている項目がずれる！？
表示位置を再計算しているからなのだろうか？
AndroidのListViewは項目の動的追加・削除ができないのだろうか？？
これだと使い物にならない。。う〜む、困った。
2015.7.18
こちらを参考に無限スクロールに対応できた。変更前に現在の状態を保存、変更処理後に復元する処理が必要だった。
2015.7.19
ようやくincremental searchの上下スクロールができるようになった！
若干ガタつくけど、今後のスキルアップかチューニング時に解決しよう。
次はDropboxかbookmark。どちらも難易度が高そう。
Dropboxはまだ挫折中なので、bookmark（TextViewでのハイライト表示という感じ）を調べてみる。
→Spannnableクラスを使えばできるらしい。
選択したときに出すメニューを置き換える
→どうする？
2015.7.20
PSWのテキスト選択時のメニュー。
setCustomSelectionActionModeCallback()を使ってカスタマイズできるらしいが、やりたいことは単純なメニュー追加ではなく、本当にカスタマイズされたwindow。
ということでPopupWindowを使ってみたが、選択状態が解除されてしまう。。
CustomSelectionは無効にして独自の実装が必要なんだろうか？
→setFocusable(true)にしていたためだった
これだとcloseのタイミングを制御しなければいけないが、フルカスタマイズできるからこれがいいだろう。
このメニューで必要な項目は、
・文字装飾 - bold/italic/under/strike-out
・ハイライト(bookmark) - color
・コメント
・検索(popup式でなければ不要？）
・copy(action barに出るからいらない？）
でググりながらやったらbold設定ができるようになった！
2015.7.21
bold以外も、under/italic/strikeout/hiliteどれも機能するようになった！
しかしまだ課題はいくつかある。大きなところでは、
・Popup表示の位置調整 - 今は画面の中央固定
・文字装飾・ハイライトの消去 - どうする？まったく仕様が未定
・ファイルへの保存、復元処理 - パスの問題が・・・。それにDropboxが使えないとあまり意味が無い
・コメント入力処理
いずれも大きな課題。あと一週間では無理かな・・・
2015.7.22
まずはファイル入出力処理から始めた。これだけで２〜３日はかかりそうだ。
それ以外の処理も一週間以上はかかりそう。
ということでリスケジュール。
8/B - bookmark
8/E - dropbox
という感じで。９月中には何とか試用できるレベルにしたいなぁ。
2015.7.24
bookmarkのファイル保存部分を実装中ですが、ここに来てvswprintfがサポートされていないことが発覚。これはちょっと重いな。。wide文字は基本的にサポートしていないから当然なんだけど。
2015.7.25
ポップアップ検索ウィンドウのEditTextとListViewのlayoutが期待通りに行かなくて悩み中。
EditTextは上側７割、ListViewは下側３割くらいで表示してくれたらいいんだけど、layout_weightを指定すると「Androidバグってるんじゃね？」というくらいとんでもない挙動をする。
高さをdp指定すると期待通りになるんだが、当然のことながら他の端末では使いにくくなる可能性大。悩ましい。。
bookmarkのファイル処理はまだ終わらない。テキストファイルを出力するとゴミが一緒に出てくる。
まだほかにもやらなければいけないことがたくさんあるし、あと２週間はかかるかなぁ。
bookmark以外にもやることはたくさんあるし、８月までにbookmark&dropboxにめどが立たなさそうだったら一旦仕切り直し、機能dropするくらいで進めよう。
2015.7.26
テキストファイルへの保存はwrite時にUTF16を２バイト単位ではなく４バイト単位で保存していたためゴミが出力されていた（予想通り）。
それにbookmark保存されたファイルから、テキストファイルロード時にbookmarkを復元することができるようになった！
bookmarkって一体何？という人のためにcapture画像。
次はbookmarkの一覧だ！
2015.7.29
ようやくbookmarkの一覧表示ができ、削除までできるようになった。
しかしbookmarkに関してはやることがまだたくさんある。ふー
2015.8.4
まだbookmark関連をやっている。
classもだいぶ増えてきて、こういう実装じゃまずいんじゃないか？
などと思いつつ。
bookmark関連はあと２〜３日くらいかな。それで大体の実装は終わると思う。（デザインは別として）
そしたら次はDropboxかな。
Dropboxは本当に頼って良いんだろうか？
普通に使う分には問題ないんだけど、APIを使い始めると色々と問題が出てくる。
Dropboxは止めてGoogle Driveにしようか？
いやいや独自のclouldにしたほうがいいんじゃないか？
などなど悩む。
一般の人はDropboxやGoogle Driveなどのサービスはタダだからいい、などと思うがAPIを使い始めると色々と制約があり、しかもそのタダのサービスがいつ終わるのかわからないからベッタリと頼ることができない。
かといって自分が立てたサービスも自分が病気になったり死んだら誰もメンテナンスができない。
自分の寿命と他人のサービスのどちらが寿命が長いか？
みたいな話になる。
2015.8.6
まだ問題があるものの、bookmark機能の大筋は大体実装できた。
次はタッチ検索画面のファイル履歴閲覧・選択。これはbookmarkの延長で仕様を作ったので１日くらいで終わるだろう。（予想通り）
それが終わったら本当にDropboxの検討に入る。
Dropboxは１〜２週間もがいて難しそうだったら一旦諦める。
もし諦めたら機能的なものは大体入っているのでテスト版公開のためのbrush upをしようかと思う。
それとソースコードは同じなのにビルドするPCによって挙動が異なるという現象が生じている。
AndroidStudioのバージョンは同じにしているので違いはNDKのバージョンくらいだろうか？
使用しているAPIなどは一般的なものばかりで、特殊なことは何もやっていないはず。そんな高度な知識はまだないですから。開発環境の違いによる動作の違いは面倒だな。。
2015.8.7
Dropboxを再び始めた。やはりstartOAuth2Authentication() で例外が発生し、IllegalStateExceptionが発生する。
ソースの中を追っていくと、AuthActivityクラスで例外が発生しており、context.getPackageManger().queryIntentActivities()で返されるactivitiesが無いらしい。
例外文を見えると、
"URI scheme in your app's manifest is not set up correctly. You should
have a com.dropbox.client2.android.AuthActivity with the scheme: db-tz5htk9j7alxxxx"
「schemeを正しく定義せよ」
ということらしいが、正しく設定しているつもり。
2015.8.10
例外の原因は、AndroidManifest.xmlで定義するappkeyとjavaで指定していたappkeyが違っていた。
これで認証は通ったが、metadataの取得でこれまた例外が発生する。
2015.8.11
相変わらずmetadataの例外で悩まされている。
2015.8.12
例外はnetwork taskはmain threadではダメ！というありがちな理由が原因でした。
これでmetadata取得ができるようになり、ファイルの一覧を表示、選択してdownloadが可能に！！
UI処理はほとんど入っていないので完成までは程遠いけど、それを除けばそれほど難しいことではありませんでした。
次はfileの更新チェックとupload。その次は設定。
ですが、長期休暇が終わるまでのお預け。
2015.8.19
ようやくDropboxの更新取得ができるようになった。わかってしまえばDropbox APIは難しくなかった。それより、
・Dropbox Core API SDKはタコ。pathが指定できないとか、/delta/latest_cursorが無いとか・・・
なので、DropboxAPIクラスを派生させないと使い物にならない。
2015.8.20
相変わらずDropbox対応中。Dropbox folderのpolling処理に関連して、Dropbox関連のファイル処理を構築。Dropbox
APIアクセスは大したこと無かったが、システムへの組み込みに時間がかかる。
そして、設定画面の構築も始めた。
2015.8.21
Dropbox関連と格闘中。動作チェックは行わず、ひたすらコーディングを進めている状況。
そのコーディングで言えば、bookmarkのDropbox共有はできるようになり、現在はポップアップ検索ウィンドウで使用するファイルのDropboxからのダウンロードに対応中。
これができればDropbox対応は一巡。
あと２〜３日くらいでDropbox対応は落ち着くと思うが、まだまだやるべきことがたくさんある。自分のTODOメモにはかなりたくさんの項目が・・・
なんとか自分が使えるレベルになるのは9/Bくらいだろうか？
自分はとにかくDropboxが使えないと不便だと思う。
Tablet１台だけで完結する人には不要かもしれないが。。
2015.8.22
Dropboxのダウンロード機能。/delta APIで更新ファイル情報取得はいいけど、これが意外と難しい。というか、まじめに実装しようとすると色々とやらないといけないということがわかった。API自体が悪いわけではないけど、client側の処理が複雑になる、ということがようやくわかった。(PDICのネット共有辞書もクライアント側の処理がかなり大変だったし、そんなもんだろう）
でもこれを乗り越えればDropbox関連の基本機能の実装は終わる。
今週一週間でDropbox関連は完結したいところ。
これが終わればいよいよ実用的なレベルになるはず！
2015.8.23
Dropboxのファイルのrevision情報を扱うように対応を進めていたら、なんと！
SDK APIには"revision"を受け取る処理がない！！
Dropboxはうまい具合に手を抜いている。
→いや、revisionはdeprecatedになっていた。revを使う必要がある。。それ用に書き直すかorz
Dropbox関連のコーディングは一通り終わった。デバッグを開始。サーバーが更新されてdownloadまでは動くようになったが、テキスト形式辞書からの変換が動かない。
しかし、これでようやく山場は越えた。まだまだ開発項目は山ほどあるけど、残りは既知のものをどう組み合わせるか、あるいは新しい項目があってもほかの人もやっている常識的なものばかりだ。
しかし、しかし、Dropbox対応を実装したら、アプリの終了時、MainActivityのonDestroyが呼ばれなくなった？？そんなことがあるのか？
2015.8.24
Dropbox対応のデバッグ中。なかなかうまく動いてくれない。疑問なのは、
・MainActivityのonResume/onPauseが何も操作していないのに時々呼ばれる。Dropboxの影響か？
・Dropbox APIにkey/secretは本当に必要なの？Handy英辞郎を見るとそれ無しでアクセスできている
など。
Dropbox対応でAndroid版開発にちょっと疲れた。
2015.8.26
ようやくDropbox経由による辞書共有ができるようになった！
原因はいどれも大したこと無かったけど、デバッグは大変だった。
次はbookmarkの共有など。
しかし、やはりやや燃え尽き症候群気味。
会社の仕事ならばやる気になれるのだが。。
タダで作っている以上、モチベーションは自分自身のみ。
2015.8.27
今日も進捗なし。やるべきことはたくさんあるし、その中に難しいことは無いのだが。。
2015.8.28
自分がほしい機能から、ということで開発を再開。
2015.8.29
Dropbox関連のデバッグをやっているが、バグがたくさん。
マルチスレッドにdownload/uploadの通信、さらにlocal fileの更新処理のタイミングなど色々と絡んで複雑。
Dropbox対応はあと２〜３日はかかるかなぁ。意外と重い。
2015.8.30
Dropbox: ようやく正常系が正常に動作するようになったかもしれない。
そこでいよいよWindows版とDropboxで経由しようかと思ったところ、仕様がよろしくない。そこで変更したところ、Android側に問題が・・・
getExternalCacheDir()で取得したディレクトリはその下にディレクトリを掘れない！？
これは困ったx_x
2015.8.31
getExternalFilesDir()で返される値は、
"/storage/emulated/0/Android/data/com.example.tnishi.pdicgui1/files/dbx/pdic"
になっており、これは実際のパスではない。実際は、
"/storage/emulated/legacy/Android/data/com.example.tnishi.pdicgui1/files/dbx/pdic"
らしく、ここならmkdir()できる。
なんでだろうと、ググってみたら、"rebootせよ"とあったので、rebootしてみたらあっさり解決。
mount状態がおかしくなっていたのかもしれない。（なぜ？)
この状態になるとソニーの「レコプラ」も異常動作を繰り返すし、システムとしてやばい状態になっていたのかもしれない。
そのような状態になる原因はわからないが、とりあえず仕様的には問題なさそう。
さて、Dropbox関連はまだ終わらない。予定をさらに超過して今週中に終わらせる。が、たぶん無理だろう。。ということで２週間の延長！α版は10/E以降になりそう。
2015.9.1
Joota Text EditorのTextLoadTaskを導入してみた。（jjuniversalchardetも)
標準のままでは文字コードの問題があり、色んな弊害があったがこれで一気に解決！
ソースコードを提供していただいた方々に感謝！！
しかし、まだ問題が多い。今目指しているのは自分が使えるレベルにすること。
あと一週間はかかるかな。。
2015.9.3
昨日は風邪でダウン。熱は無いけど頭はボーっとしてほとんど何もやる気がおきず。
１０時間寝たら回復！
予想していたが、Windows版とbookmarkのハイライト位置がずれる。
行番号とpositionの対応表を作らないといけない。
2015.9.8
これまでXperiaのZ Ultraで開発してきたけど、coviaというマイナーな端末で動かしてみた。残念ながら、ファイルの読み込みで落ちるorz
Android4以降を気をつけながらやってきたけど、やっぱり互換性の問題はあるよね。
2015.9.9
coviaをAndroidStudioでデバッグしようとした。しかし、ドライバーが無署名じゃないか！！
そんな危険なものをインストールできる環境が無いので、AlertDialogでデバッグするか・・・
→修正完了。単純なnull pointer accessでした。
2015.9.11
自分ひとりで使えるレベルにようやく到達できたと思う。(Androidの勉強を始めて７ヶ月！）
これから（凄い）久しぶりに英語の勉強を再開したいと思う。
あと問題はデザイン。いまどきのアプリはどれもデザインがいいので・・・
Androidはちょっと頑張ればそこそこのUIが作れるのでやってみないといけない。
（文字だけじゃなくてアイコンも一緒に、程度なんだけど）
さて、その英語の勉強の素材だけど何がいいだろうか？
PocketPC版のPDICを作った頃はJapan Timesを中心に読んでいたけど、Japan Timesは今はもう読まなくなったし、New York
TimesとかFinacial Timesとかを読んでいたけど有料化されてしまったし！！
こういうreading中心の英語学習で最適な素材ってなんだろうか？
2015.9.12
自分専用で学習中。実際に使ってみると色々と不都合な点が・・・
あと２〜３日かけて安定して使えるレベルにしよう！
2015.9.17
しばらく更新をサボっていましたが、自分だけの使えるレベルになってきました。
Android版の開発は一段落、Windows版の改良をしばらく進めます。
2015.10.25
Windows版の改良を進めていたのですっかりご無沙汰。自分自身も使うようにしてきたので改良すべき点がポロポロと。
その中でWindows版と共有する部分、bookmarkの位置情報をどういう形式で保存するか？
それはEditTextの位置情報のわけだけど、現在はファイルからの文字位置で保存している。が、できれば論理行＋桁のほうが扱いやすいはず。しかし、Androidではそうやればできるのだろうか？
ちなみにWindows上で論理行を扱おうとした場合、そのようなAPIが無いため独自コードを書いて管理しなければならない。ありえないよな・・・絶対に内部では計算・管理しているはずだが。
2015.10.30
論理行の件は解決策が見つからないので、現在はクリップボードとファイル保存関連を実装中。。
2015.11.25
前回書いた日記はつい最近のことかと思ったら、もう一ヶ月近く経ったのか！
クリップボードとファイル保存は対応できた。次にdropboxへのuploadを対応しようと思ったが・・・
tabletでほかのアプリからコピーして、ちょっと体裁を整えてファイル名を入力して保存して・・・という作業はPCとかAndroid上のほかのアプリでやったほうが楽だろうと。ということでdropboxのupload対応は止めました。あくまでAndroid版PDICはすでにあるテキストファイルの閲覧・検索・マークに特化したほうが一番いいだろうと。
そこは一段落して、「片手で検索」ができるように実装、現在はNavigationDrawerを実装するかどうか？
NavigationDrawerを実装しているアプリは多いけど、現在のPDICに必要なのかどうか？というところ。
片手でできるという点ではNavigationDrawerは適切だし、ActionBarに比べたら使いやすい。しかしNavigationDrawerをほぼすべてのActivityに実装しなければいけないのはなんだか面倒だな・・・というところではまっている。
20015.11.26
NavigationDrawerは取りあえずいらない(笑)
それより問題なのがDropboxの扱い。現在の作り方だとステップ数が多いし、とても一般の人が利用できるものとは思えない。でも一般公開されている情報ではそれしかなさそう。でもDropboxを使っているアプリではもっと簡単なんだよな。。これを解決しない限り一般公開はありえない。
# 一般公開するために乗り越えなければならない問題がまだいくつかあるが・・・
2015.12.3
さて、色々と課題はあるものの、α版リリースを2016.1に決定しました。
自分が意図する使い方としてはほぼ問題はなくなってきたので、あとは一般の人が使うレベルにするくらいかな？
α版をリリースしてからブラッシュアップしようかな。
2015.12.19 Dropbox対応
どうやら、Dropox AppをProduction Statusという状態に移行すればできるらしい。
これにすれば、App Key/Secretを入力する必要がなくなるはず。
だけど、自分の個人的なDropboxのappだったものをProduction Statusにするだけ、と言われても本当に大丈夫？
もしかして自分の個人的なDropboxが一般公開されるんじゃないの？・・・これはかなりマズい^^;
実際にやってみないとわからないけど、この作り方はちょっと変じゃないの？＞Dropbox
2015.12.21 Android版公開
ようやく公開！(野良アプリとして)
2016.4.9
ほかの作業で時間が取られ、すっかりご無沙汰。
正式版に向けて再開。
まずはGoogle Drive対応から。
Dropboxにはすでに対応しているが、正式な認証の仕組みを利用するにはPDICを正式登録する必要があるらしい。となると正式版を公開するまでは正式なDropboxの機能を使用できないということになるので、Dropboxは一旦保留。
ということで、Google Drive対応を初回正式版に搭載する予定。(Google Driveも同じ仕様だったらNGだが、Googleはそんなことをしないだろう・・）
まずはこちらのtutorialでやってみる。SDK APIバージョンやpackageが無いなどのエラーが出たが、ビルドまでOK。
2016.4.10
実行してみたら、"Invalid field selection items"とエラーになる。
setFields("nextPageToken, item(id, name)")
で例外が発生しているみたい。
2016.4.13
いまだに動かない。誰もメンテしないから問題が放置さているんだと思う。
Google Driveは諦めて、自分でネット共有フォルダーを作るかぁ！
としたいところだけど、さすがにそれをやり始めるとさらに時間がかかるのでどうしても動かさないといけない。
ネットはなかなか正しい情報にたどり着けない、特に更新が頻繁な情報は。
この点は昔から変わってない。
MLなり、FAQなり用意すればいいと思うんだけど。
Google DriveのAndroid APIに関してHOTな情報はどこにあるの？
Google先生に聞いても無さそう。。
2016.5.17
再びGoogle Drive対応。もう一ヶ月以上経つのかぁ。
まったく進捗がありません。
もう少し調べてにっちもさっちもいかない状況になったらteratailにでも質問を投げてみます。
質問するよりググッて調べたほうが早いと思うけどね。。
こんな小さな壁にいつまで躓いていてもしょうがないので、一週間以内に実現します！
2016.5.18
ようやくsample programが動いた。というより、異なるsample programに変えたらあっさり。
googledrive/android-quickstart
このsample codeを参考にすれば作れることはわかったが、問題はGoogle Drive側の設定が非常に煩雑であること。一般ユーザーには対応不可能。なぜそんなに複雑にしているのだろう？IDとPW、それに「APIを有効にする」くらいで十分だと思うのだが。。
まずは複雑にしている理由を調べる必要がある。
2016.5.24
ユーザーにとって複雑かどうかはとりあえず置いといて、とにかく実装することにした。
これまでAndroidStudio Ver.1.1でやってきたけど、Ver.2.1にしたらビルドエラーが出るわ出るわ。。
開発進行中のものはいつもそうで、昔のLinux kernelも同様、ググってもどの情報を信じていいのかわからない状態だった。
ただAndroidStudioはそういう開発者のことを配慮してか、エラーメッセージが比較的親切。
WindowsやLinuxでのエラーメッセージとは違うよね。
一週間で実現する！と宣言してちょうど一週間経つけど、今は開発環境やら、Google Drive API libraryの導入でもう少し時間がかかりそう。たぶんあと一週間くらいで実装はできるかな？
2016.5.25
android-quickstart サンプルから移植しようと思ったら、単純な機能しかなくて参考にならなかったorz
それより、移植の前にやるべきことがあった。従来のDropbox関連のクラスを抽象化してGoogle Driveとclassを共通化する必要がある→ほぼ完了
さて再び参考になるサンプルを探したところ、android-demos はどうだろう？
methodごとにコマンドが用意されているから行けそう。しかし、EXISTING_FOLDER_IDとやらを設定しないと、metadataを取得できないらしいが、これは何？
Google DriveではIDで管理しているのかもしれないが、そんなものを意識してコーディングしなければいけないのだろうか？
自分がやっていることの一つはDropboxとGoogle Driveの共通部分を抽象化する作業だが、どれくらいの違いがあるのか気になる。
2016.5.26
Google Drive APIの作りはわかってきたが、Google Driveに「パス」という概念はないのだろうか？
例えば、/abc/def のファイル一覧の取得、というものを作ってみたがとても面倒。
（ヘルパーライブラリも無さそう）
Dropboxに比べるとアプリ側の負担が大きいし、コードの見通しも悪い。
2016.6.2
なかなか進まず。root folderをlistChildrenで呼び出してもファイル・フォルダーがゼロで返ってくる。何がいけないんだろう。。
2016.6.3
APIでroot folderにfolderを新規作成したら、そのフォルダーがlistChildrenで見えるようになった。しかし、Windowsクライアントからは見えない！？一体どこにそのフォルダーを作ったのだろう？getRootFolder()って一体どこを示している？？
2016.6.4
さっぱり進まないGoogle Drive対応。やればやるほど疑問点が増えていく。
・APIで作成されたフォルダー、ファイルは他のアプリからは見えない。どうやったら見られる？
・フォルダー名、ファイル名に相当するのはTitle？同じ名前が大量に作れてしまうが、同じファイル名を作れるのはGoogle Driveの仕様？
・Google Developer Consoleで生成されたクライアントIDって使わなくていいの？一体何に使う？(WebAPIでは使用しているようだが）
・Google Driveのsampleはたくさんあるようだが、どれも参考にならない、まともに使えない。なぜだ？
2016.6.12
ようやく謎が解決。単純に使用していたアカウントが異なっていた^^;
さて、自分のくだらない手違いでかなりの時間を浪費してしまった。
こんな初歩的な間違いで躓いてしまうと先が思いやられるが、基本的なスタートがやっと出来たので実装を本格的に進めていく。あと一週間くらいで基本的な動作ができるようにしたいと思う。
2016.6.19
しかし、まだわからない点が残っている。
・パスの概念がないのだろうか？
・metadataからファイル名を取得するメソッドは？
2016.6.20
Google Drive対応をはじめてすでに二ヶ月以上。ほとんど進捗がありません。
とにかくよくわからないんですよ。
何となくですが、DriveIdというIDがすべてでそれですべてを処理しようという思想なのかな？ファイルを扱う場合、パスやURIが基本ですが、Google
Driveの仕様やサンプルコードを見てもそのような概念が全く出てこない。
DriveIdですべて扱う、というのならそういうことを仕様書なりに書いて欲しいけどまったく書いていない。
もしそういう思想であるのなら、APIを提供する側はかなり大変なことになるはず。
例えばファイル選択のためのUIはライブラリ側が提供しないとうまくいかない。
実際用意されているからそれを使用すればいいけど、一度ファイルを開いて再度ファイル選択をするとき同じフォルダーのファイルから開きたい場合が多いだろう。しかし、Google
DriveのAPIにはそういうものが見当たらない。
通常なら、前回開いたファイルのパスを保存しておき、次回ファイルを開くときにそのパスのフォルダーから選択するようなUIを出せばいい。
しかし、開いたファイルのDriveIdからはどのフォルダーに属するのか取得するAPIは（今のところ）見当たらないし、そんな感じのAPIも見当たらない。
一体どうしたらいいのか？
とりあえず今は出来る限りネットからサンプルコードを拾って試す。
それでダメならGoogle Drive APIはダメAPIという烙印を押すことにする。
2016.6.26
demo sampleで試しているがsample自体が手を抜いているのでエラーが発生するとnull exceptionで落ちるわ、そのエラー原因を調べようにもそのサンプルがないから何がいいのかよくわからない。
DriveIdResult.getStatus()で見ると、「そんなDrive Itemはない、または認証が取れてない」とご親切なメッセージが入っている。
これではユーザーが同じ問題に遭遇した場合、通常自力では難しいだろう。
Google Drive API(Android)はダメダメAPIかもしれない。
Google Drive対応は一旦諦めようかと思う。
2016.9.4
気がついたら二ヶ月以上も開発がストップしていた！！
久しぶりにビルドしたら
Error:Execution failed for task ':app:compileDebugJavaWithJavac'.
> java.io.FileNotFoundException: ...￥dropbox-sync-sdk-android.jar (指定されたファイルが見つかりません。)
なんていうエラーが出る。色々なことをやったが解決せず。
2016.9.6
まだエラーの原因はわかっていないが、ようやく道筋が見えてきた。
開発を継続しようと思ったら、今度は突然開発用SSDがまったく認識しなくなった。。。
（本当に突然。ほかにもSSD,HDDが４台もあるのに開発用SSDだけ。しかもIntel製のお高めのSSD）
ようやくAndroid版に本腰を入れようと思ったらハード的なトラブル。
Android版は止めなさい、という暗示だろうか？
そんなことになれば燃え上がる私なので、なんとかせねば。
2016.9.7
例の問題は解決した（みたい）。
たまたまここを見た人のために書き留めておく。
イベントログを調べると、
予期しないエラーが発生しました。エラー コード: 490@01010004
ソース：VDS Basic Provider
が発生していた。
これでググると、IntelVTという言葉がやたらと出てくる。（しかしそれが原因とは書いていない）
で、試しにBIOSのIntelVTをOFFにしたら、これまでの絶不調がウソのように解決、Android版PDICも今まで何事もなかったように正常動作！！
IntelVTがそんな大問題を引き起こす悪者だったとは！！
というより、IntelVTに対応できていないノロマなドライバーか何かが悪さしたんだろう。
だからデフォルトはOFFになっているんだね。
これで動くようになったが、ビルドが通らないエラーの原因は不明。正常に動作していた別のPCからツリーごとコピーして解決。違いを比較してもよくわからない。
2016.9.8 Dropbox v2対応
さて、開発の再開。
Dropbox v2への対応。現在のPDICのDropboxはv1対応なので、いずれ使えなくなります。
早急に対応しないといけない。
2016.9.9 Dropbox v2対応
早速躓いている。認証関連のところで、
java.lang.VerifyError
サンプルコード通りに書いているんだけどなぁ？
ググってみると、SDKとかのバージョンが合っていないと出るとか。
変えてみても何も変わらない。。
micgrationではすでにOAuth2使っているなら問題ないよーって書いてあったけど、問題大あり。
これまでDropbox SDKの認証APIを呼び出せば簡単に出来ていたけど、サンプルには”自分でアクセストークンを用意しろ”ということになっている。はぁ？ですよね。ユーザーにも「自分で用意してね」なんて言えるわけねぇだろう！！
ということで、これ以上の情報がないのでDropbox v2対応は諦め。（早っ！）
Bookmark対応を先に進めよう。
Dropbox v2対応はDocument等をよく読んで知識を深めてから取り組むことにする。
2016.9.29 Dropbox v2対応
ちょっと手を休めるともう20日も経っている！
ここに参考になるサンプルコードがあった。
しかし、このコードはdeprecatedだったり、それに対応するとさらにlibraryが必要だったり・・・まともなサンプルコードがない。
「OAuth2を使っていれば変更はないよ」みたいなことが書いてあったけど、少々手を加えないと動かないことがわかり、ようやく認証まではできるようになった。（今までDropboxAPI経由だったが、DropboxのAuthクラス経由に変更する必要があった）
しかしまだ問題があり、DbxClientV2オブジェクトの生成時に "NoClassDefFoundError: /com/dropbox/core/DbxHost"みたいなエラーが出る。ググってもヒントになる情報は出てこない。
2016.9.30 Dropbox v2対応
com/dropbox/core/DbxHostがimportしている com.fasterxml.jackson がソースコードを参照できないため、さらにjackson-coreを追加したが変わらず。
AndroidStudioを2.1→2.2にupgradeしたら、解決、DbxClientV2が生成できるようになった。（一体何だったのだ？）
原因はよくわからないが、次の段階。
client().files().listFolder()
を呼び出すと、
com.dropbox.core.NetworkIOException: Unable to resolve host "api.dropboxapi.com":
No address associated with hostname
と出る。
2016.10.4 Dropbox v2対応ほか
ようやくファイル一覧を表示してダウンロードできるところまで動作するようになった。
ここまでくるとv2の設計思想がわかるようになってきた。
・v1と機能的には大きな違いはなさそう
・Java APIはwebのURLの対応に近いものになった（なのでわかりやすくなった？）
・deprecatedなAPIは単なるBuilderパターンへの対応によるもの（だったらdeprecatedにする必要はないと思うが・・・最近はBuilder教が流行っているようで、deprecatedにするほど優れたパターンとは思えないが・・・）
・OkHttpはたまたま私が見たサンプルで使用していただけで使用しなくても動く。が、標準のHttp clientより速いらしい。
・標準のHttpもOkHttpもいずれもProxyに対応していない？（だからUnable to resolve host...エラーが出る）←これはいずれ解決しないといけない
といった感じであと１〜２週間もすれば対応を完了できるだろう。
次はrelease版への対応。signed版のbuildをやってみたが、色々とエラーが出る。
さらに並行してすすめるのが、タッチ検索の検索結果のタッチ検索の対応。
機能的にはここまで進めばあとはデザイン系。
順調に進んでも１１月にαリリースになりそう。ようやく先が見えてきた感じ。
2016.10.12
Dropbox v2対応は一段落ついたので、現在はファイル選択の画面を使いやすくするよう改良中。
その必要性はちょっと低いようにも思うので、時間がかかりそうであれば実用的な動作を検証してα版としてGoogle Playに公開するかも。Developerとして登録も完了しています。($25払った)
予定ではα版を12月にしていますが、前倒しして今月中にアップするかも？
2016.10.21
様々な問題があるものの、今はAndroid版を中心に開発を進めています。
現在はTEDを自分の教材にしてPDIC Android版を使用していますが、これを中心に開発をすすめると色々と問題点や改善点が見えてくるので、α版の公開はもう少し完成度が高いものを公開したくなってます。なのでα版公開は１１月の予定ですが、もう少し遅れるかも？
2016.12.26
ようやくα版を公開。
2017.3.27 Qtの検討
Android版はα版を公開しましたが、正式版のターゲットは定まらず・・・
これまでAndroid Studioで開発を行ってきたが、これによる開発はLevel1で止めようかと考えている。
それに代わってQtを使ったマルチプラットフォーム対応にしようかと考えてます。
Qtはかなり昔から存在するフレームワークですが、最近ではWindows, Mac、Linuxだけでなく、AndroidやiOSに対応しており、一度Windowsで動くQtアプリを作れば原理的にはどのOSでも動作することになります。
最近のQtはかなり洗練されており、通常のアプリであれば難なくできそうな気がする。
Windows上でのQtしか現在は開発を行っていないので、Android上ではどうなるのかわからないが、現時点ではQtでPDICアプリを試しに構築してみようと思う。
もしそこそこのものが実現できれば、Windows, Mac, Linux, Android, iOSで動くPDICが実現できることになる。しばらくQtの学習します。。Qt版PDICの始動！
2017.5.25 Qtその後
Qtでアプリをいくつか作ってみたが、概ね好印象。
こちらのページに書かれているQtインプレ記事がほぼ同意見だ。
今のところ大きな問題は付属のDLLサイズが非常に大きいところ。多機能ファイルコピーツール(非公開)を移植してみたが、実行ファイルが200KB強なのに対し、付属DLLが合計16MB。
小さなツール的アプリには不向きと感じる。
Android版ではどうなるのだろうか？
DLLサイズを小さくするには地道にカスタマイズするしか無いのだろうか？
今時のPC環境であれば、気になるサイズではないとは思うが。。
ちなみに、同アプリを別コンパイラ(C++Builder5)で作成したものでは1MB程度(DLLは不要)。
2018.11.25
SonyのXperia XZ1（香港版）を購入。
購入の理由はいくつかあるけど、Android 8.0で問題が多いらしいのでそれを解決するため。
Emulatorでは問題ないのに、実機では色々と問題がある、というのを実際に動かしてみて気がついた。
今はネットをググれば必要な情報は手に入れられる、と思われているが、Androidプログラミングはそれほど容易ではないように感じる。
Android8.0で困っている問題は、
・ファイルの一覧を取得できない（辞書ファイルの選択などで）
・Dropboxの認証にManifestファイルに固定のApp Keyしか利用できない
ネットを一日中ググってもそれらしい回答がなかなか見つからない。
前者についてはDocumentsProviderを使うことでファイル選択はできるようになるが、得られる値がURI形式であり、そのままでは利用できない。それをファイル形式に変換してみるも、JNIでfile
openするとアクセス権限がないと言われる。Android8.0になって一体何を変更したのか、概要を読んだ限りではヒントが見つからなかった。
特別なことは何もやっていないので、ググれば出てきそうだが。。
あと一日頑張ってわからなければteratailだろうか？
→teratailに投稿した直後に前者についてはAndroidManifest.xmlではなく、個別にpermissionを取得する処理を追加することで対応できた。検索キーワードが悪かったと言うことか。。。
(checkSelfPermissionあたりでググると出てくる）
後者のDropboxに関してはもう少し調べてわからなければやはりteratailにて質問予定。
2020.1.23
Android版のPDICをいくつか改善して公開しようと思った。
しかし、なぜか64bit版が入ってないからreject。
昨年の７月に同じように64bit版も含めて公開できたはずなのにreject。
なぜrejectしたのか詳細な理由を書いてくれれば良いのに、まったくわからない。
色々と変更して１０回以上試したけどダメだった。
そろそろGoogleも殿様になってしまったのだろうか。
あと一ヶ月くらい頑張ってダメだったらGoogle Playでの公開は諦める。
多くの人に使ってもらいたいとは思うけど、それが目的ではないので野良アプリとして公開すれば良いかな。
2020.1.27
その後も何度もトライしたけど、「64bit非対応アプリだ」と蹴られてしまう。お陰でバージョン番号も20以上上がった。
アップロードした時点で自動チェックすれば良いのに、その次の段階で自動チェックをするので、同じバージョンが使えない。
→Googleさん、ここはいい加減改善しましょうよ？
→何が原因で64bit非対応なのか詳細なメッセージを出すようにしましょうよ？＞Googleさん
天下のGoogleがお粗末なチェックシステムなので苦労させられますが、それ以前にPDICをビルドすると警告メッセージがいくつか出ているので、まずそれを対応した方が良いかもしれない。(64bitとは関係ないものばかりだが）
完全無欠の状態にしてからGoogleに文句・苦情を言ってみることにした。
順調に解決できれば良いけど、あと２〜３週間はかかるかな。
2020.1.28
警告の出ている内容を一つずつ対応しているが、気になるAndroid側の変更点が。
API26でProgressDialogがdeprecatedになったが、その理由がここに書いてある。
ユーザーを長い時間blockingするのがよろしくない、というのが一番大きな理由。
確かにblockingしなくてもいい場面もあることはあるがすべてではないはず。
ProgressDialogであってもcancelはできるし、blocking自体が問題ではないはず。
なのになぜProgressDialogをdeprecatedにしたのだ？
blockingが不要なところはこうすべき、と注意程度にすべき。
自分の場合は、blockingすることでユーザーが不用意な操作をしないようにしているためblockingは必須。
まだ検討中だが、ProgressDialogと同じようなもんを自前で用意する必要があるだろう。
Googleは優秀な人が多いと思うが、なぜこんな（昔のMicrosoft的な）アホな判断を下したのだ？
もし、注意喚起のためにAndroidの仕様を変更していく、というバカな方針ならAndroidの開発は止めたいところだ。
2020.2.2
公開は地道に警告を一つ一つ潰しているが、未だにrejectされる。
そろそろrejectされるような警告はなくなってきたので、Googleに直訴したいと思う。
それはそれで、今日は別のアプリを作ってみた。
KMLMarkerList(仮名)というアプリで、Google Mapなどからマーカー情報の入ったKMLファイルを読み込ませ、現在位置から近い順で表示、距離と方角を一覧表示するという簡単なアプリ。これは非常に便利なのだが、ほとんどのナビには無い。（自分が知っているのはGARMINのみ)
登録済みの「最寄りのコンビニ」みたいなものなら大抵のナビならあるのだが、自分が入力した位置情報の一覧というのは見たことが無い。
いずれフリーウェアとしてGoogle Playに公開しようと思う。（アプリ名は未定）
そこでなぜこのようなことを書いたのかというと、このアプリを使って高速の次のSA/PA/ICまであと何キロかというのを知りたい。
現在持っているナビでもその機能はあるのだが、古くて高速によっては使えない。（10年以上前に開通した新名神すら載っていない）
そういう情報ならネットに転がってる・・・と思いきやなかなか見つからない。（昔なら普通にあったと思うけど）
もちろん、自分でコツコツと一つずつ入力していけばいいのだが、高速道路は年々更新されるため、それに追従するのは面倒。しかも更新忘れがあると痛い目に遭うこともある。
・・・だったら新しいナビ買えば？
と言われそうだが、バイクで使えるという条件でのいいナビはなかなか見つけられない。
ということで、高速道路の位置情報お待ちしてます！
KMLMarkList(仮名)はこんな感じ
Google Mapでマーカーを設定、それをKMLファイルにExportしてそのファイルをアプリに読ませているだけです。
Google Mapのマーカーで設定した色も小さな四角で表示されます。
地名をタップするとGoogle Map(など)が起動して周辺の地図を見ることができます。
突貫で作ったアプリ(２〜３日くらい？）ですが、便利！
2020.2.5
Googleに直訴した。（質問した）
２営業日以内に返事が来るらしい。
25回以上もアップロードしたので、バージョン番号がかなり上がりました。
散々調べて・試して解らなかった、一体何が問題なのか。。
2020.2.6
Googleから返事が来て、ようやく解決しました。
原因は、古いデバイスのために公開を維持していたバージョンが64bitに対応していないため、新しいバージョンは公開できないと！
アップデートしたかったら非64bit版の古いバージョンの公開を止めなさい、と。
そんなことどこにも書いてなかったよね〜
Googleの方針としては (今後Google Playで公開する場合は) 64bit非対応アプリの新規登録はもちろん、たとえ旧デバイスのためと言ってもアップデートすら許さない、という戦略のようです。
この戦略のため、Kitkatより古いデバイスはPDICを新規インストールできなくなりました。（すでにインストールされている場合は問題なし）
そのような古いデバイスは、PDICがインストールされたデバイスのうち１％程度しかいないので、ここは切り捨て御免、ということでご容赦ください。
(Googleの戦略ですから)
最新のPDIC Ver.0.7.36でサポートされているデバイスは、
Android 4.4以降(Kitkat以降)
今回の対応で新規インストールできなくなったデバイスは、
Android 4.0 - 4.3(Ice Cream SandwitchとJelly Beans)
※それでも古いデバイスで使いたい、と言う人はリクエストください。Google Playからはインストールできませんが、ダウンロードして利用することは可能なのでここで公開できます。
かなり時間がかかったけど・・・早めに質問しておけば良かった。
2020.2.8
公開できなかった問題はようやく解決できたので、本格的に改良を進めます。
まずはNavigation Drawer対応。タッチ検索を使用しているときに辞書検索をしたいときがよくあるのですが、現在は一旦タッチ検索を終了しないといけない。
しかし、Navigation Drawerで検索するとみんな実装が違っていて何が正解なのかわからない。
本当はNavigationUIでやりたいけど、そうなると最近の端末でしか利用できなくなるのでそれはあと数年後の話。
あとはGoogle Playのフィードバックでフォントが小さいというのを二件ほど頂きましたが、個人的にはちょうどいいと思うし。PDICだけが小さいというのならわかるけど、そうじゃなかったら使っているアプリすべてにリクエストしているのかって思う。
理由をいちいち聞くのは面倒なので、pinch in/outでできるようにしようかと思う。
それとタッチ検索でのファイル保存機能とか。Dropboxからのダウンロードは一応機能しているけど、これは自分のアカウントでしか動かないと思う。
などなどやりたいことはたくさんあるので、Windows版が落ち着いた今、進めたいと思います。
2020.2.12
ようやくNavigation Drawerで動作するようになった。
まだ小さな問題がいくつかあるのだけど、もう少しFragmentの理解が進めば解決できるだろう。
Navigation Drawerの実装はサイトによってみんな違っていて何が正解か解らなかったのですが、恐らくここが私が目指したいものに近かったと思う。日本語のサイトもいくつか読んだけど、どこも今ひとつ。
（後日：日本語にも似たようなサイトはあった。検索キーワードがよろしくなかったようだ）
実はこのサイトのsampleは AndroidStudio3.4.2のNew Project -> Navigation Drawer にかなり近い。
ちなみにAndroidStudio3.5.3 -> Navigation Drawerで作るとこれまたちょっと違うframeworkで作られてしまい、私が目指したいものとは違ったものになってしまう。なので、どの世代でsampleを作ったかに依るのではないかと思う、だから正解がすぐにはわからない。
最新の機種だけでよければNavigationUIで作るのがbetterだけど、Kitkatなど古い機種では動作しなくなる。
ということで、Navigation Drawer+Fragmentはやや敷居の高いframeworkでした。
2020.2.13
Navigation Drawerの実現のために小さな不具合が発生するようになったのですが、そのうちの一つ、Fragment内で動作するswipeの挙動がおかしい。ちょっと調べたところ、派生元のFragmentが実は本物のFragmentではなく、Support Library というやつの偽物だった。
Navigation Drawer自体が Support Library で動作しているのはわかっていますが、それを使うために芋づる式にさまざまなcomponentが
Support Library化してしまう。Support Libraryのcompoenentが本物と完全に同じ挙動をすることを保証しているのなら良いが、そんなことは絶対にないだろう。
ということで、Navigation Drawerのために偽物componentで我慢するのか、それとも古い機種を切り捨てて・・・と思ったら、
https://teratail.com/questions/234765
AndroidXはAPIレベル14以降で動作！？！？
API Level 19のEmulatorでAndroidXアプリが動作しなかったのでてっきり・・・（それじゃその原因は何だった？？）
Navigation DrawerではなくNavigationUIを使用した方が良さそうだが、ではAndroidXを使った場合、Fragmentとか本物なのだろうか？
2020.2.14
偽Fragment(android.support.v4.app.Fragment)のswipe scroll問題が解決できるかもしれない（正確には偽Fragmentの中にあるTextViewのswipe
scroll)、ということでNavigationUIにチャレンジしてみようかと思う。
しかし懸念材料としては、
・AndroiXになっても、androixのFragmentであり、swipe scroll問題が解決するかどうかはやってみないとわからない
・NavigationUIの情報がまだまだ少ない (参考になるsampleはまだ３つほどしか見つかっていない！）
・情報が少なくて行き詰まる可能性がある
だが、Navigation Drawerに比べてコードは簡単そうだし、失敗しても大きな犠牲にはならないと思われる。
また、swipe scroll問題が解決できなかったとしても、
・最新のライブラリがKitkat上で動作する（はず）
・今後も改善が見込まれる (Navigation DrawerはメンテしないとGoogleは宣言している）
くらいの利点は残る。
見識のある人なら明確なアドバイスをしてくれそうだが、NavigationUIは比較的新しいlibraryなので頼れる人はほとんどいないだろう。。
swipe scroll問題がなければ、Navigation Drawerで決まりなのだが。
やってみなければわからないということでやってみる。
2020.2.15
NavigationUIを調べてみたが、２時間程度であっさりと終わった。
Googleが提供しているsample、NavigationBasicSample を試そうと思ったら「AndroidStudio 3.6を使ってくれ」というエラーメッセージ。
現在の最新版は3.5.3。非正式版を使ってまでやるつもりはないので終了。
ググってもサンプルが出ていないframeworkは使っちゃいけないと言うことで。
そうなるとNavigation Drawer、Support Libraryを使って作ることになるが、名前と違い、Fragmentなど多くの基本的なcomponentがSupport
Libraryにある偽物に置き換えないといけない。Googleにしてはちょっと頭の悪い作りになっている。というのは言い過ぎか？
一言で言えば、double standardを自ら作ってしまったと言うこと。さらにはAndroidXなんていう新たなSupport Libraryを作ってしまい、triple
standard状態となっている。frameworkとしてかなり苦しい作りになっているのではないかと思う。だから"Support Library"なんていう紛らわしい名前はよろしくない。
2020.2.16
ようやくNavigation Drawerで一通り動作するようになった。
デザインに関してはもう少し変更が必要ですが、かなり使いやすくなった。
あと１〜２週間、自分で試して問題が無ければ公開しようかと思う。
ようやく少し肩の荷が下りた。ホッ
2020.2.18
新しいUIになって使いやすくなった。
次に見えてきたのがそろそろ正式版にしようかという考え。
野望はまだたくさんあるけど、個人的には実用的になってきたので、正式版に向けたブラッシュアップをしてもいい頃ではないかと思う。
あと１〜２ヶ月後、つまり３〜４月くらいを目処に正式版にしてみようかと思う。
個人的な余談を書くと、20年くらい前にやりたかったことがようやくAndroidみたいなデバイスで実現できるようになった。
偉そうな言い方で言えば時代が自分に追いついた、かもしれないが、実現してみると意外と自分のやりたかったことは大したことは無かったのかもしれない。
多くの英語学習者は様々な投資・学習をして成果を得られないという苦い経験をしていると思うが、結局のところお金を出せば得られるものでは無く、自分に合った学習を続けることで着実に実力が上がるものだと思う。
Android版PDICはそれ単体では難しいけど、PDICと何かしらの辞書や音声データを組み合わせることで自分一人でもある程度英語力を上げることはできると思う。(実際それで上がったはず)
英語力を上げたい人は一つのアプリで英語力を上げてくれるものを探しているかもしれないけど、そんなに都合のいいものはなかなかないと思う。
（あれば私も欲しい）
2020.2.19
正式版の前に、まず現在のアルファ版の公開。
自分で使ってみて問題・改善点がいくつかあり、それらが収束するのはもう１週間くらいだろうか。
それでもかなり使いやすくなって英語学習が楽しい！
2020.2.24
新しいUIで使いやすさを追求していたら標準とは異なる動きが多く、かなりはまった。
ようやく安定してきたのであと１週間動作確認をしたら公開できる見込み。
標準と異なると言っても、感覚的には直感的な動作だと思う。
Android版をもっと進めようかと思ったけど、isGrepでやりたいことが溜まってきたのでまずそちらを片付けてみたい。
2020.3.4
Navigation Drawer版を公開済み。
直近で対応しようと思う機能は、
・タッチ検索におけるファイルの再読込
・ピンチイン・アウトによるフォントサイズの変更
・Dropboxの対応（たぶん私のアカウント以外では使えないはず）
くらいかな。
フィードバックには色々とコメントやご質問を頂いているのですが、これまで返事を書いたことが無くてすみません。
対応できるものは対応していますが、個人的にやりたいことがまだたくさんあるため、個別に対応して改善するというレベルには至っていません。
ということで、あと１〜２ヶ月ほどを目処にβ版レベルに引き上げ、頂いたコメントは真面目に対応させて頂きたいと思います。
2020.3.6
Dropboxの対応のため色々と調べたけどやっぱり解らない。
ActivityのXMLにapp keyを記載しなければならない、という時点でおかしい。これだとアプリを作った人しか利用できない。
Dropboxはそういう仕様なのかと諦めるしかなさそう。Dropboxを使用したい人はDropsyncなどのアプリで同期を取って頂くと言うことで諦める。
（私自身は自動同期してくれるので非常に便利なのだが）
そうなるとDropsyncみたいなアプリは一体どうやっているのだ？という疑問がわいてくる。。
あと直近で残すのはフォントサイズの変更かな。これに対応できたら公開する予定。
Dropboxの機能は隠し機能として残すつもり。（自分は使いたいので）
2020.3.7
フォントサイズの変更、実は簡単では無かった。
メイン検索の一覧はListViewを使っており、サンプルの通りにやると期待通りに動かない（ピンチイン・アウトしない）。
ググるとXamarineのサンプルはあったが、AndroidStudio/Javaでは動かない。
ググってもググっても出てこないので諦め。
タッチ検索についても考えてみたが、フォントサイズを変更すべき場所は色々とあり、そもそもどのサイズを変えたいの？
という基本的な要求自体が明確で無いこと、それにViewコンポーネントごとに拡大・縮小をしなければならず、かなり面倒。
（fragment単位、とかではない）
そもそも私自身は現在のサイズに不満は無く、再度リクエストが来たら詳細を聞いてみる。
機能追加はもうないと思い、公開したところ、クラッシュが頻発？？
自分のところではもちろん起きないけど、クラッシュしている場所はJNIっぽい。
でもJNIはまったくいじってないはず。
ビルドし直してとりあえず公開。
もしそれでダメだとしたら、
shrinkResources true
かな？
これまでクラッシュはほとんどなかったのに何だろう？
この問題が落ち着いたら、いよいよ正式版に向けて進める。
機能的にはひとまず十分なので、残るはデザインかな。
2020.3.8
クラッシュの原因は圧縮と難読化の設定。圧縮だけだと何故か落ちる。原因を調べるのは難しいと思われるので、両方とも外したらとりあえず問題は無し。ProGuardを外したので、１〜２週間クラッシュが起きないようであれば、再び圧縮・難読化したものでリリースする予定。
2021.2.15
久しぶりの更新。開発意欲がなくなりつつあったけど、AndroidOSのセキュリティ強化などでやるべきことが増えた。
直近でやるべきこと・やりたいことをまとめると、
・SAF(Storage Access Framework)への対応
これができないと辞書登録が基本的にできなくなってしまう
・SAFでのDropboxへの対応
これはできなくてもいいが個人的にはあると嬉しいかも→SAFのprovider側ですでに対応していた
・音声再生のServiceでの再生
登山中にPDICで音声再生、YAMAPで登山道確認、写真撮影をやっているとPDICの音声再生が止まってしまう
・<→xxx> の対応 - 現状リンク先を参照できない
2021.2.16
SAF対応。ググってみた感じ、ほとんど使い物にならない気が。
例えば、webからダウンロードしたPDIC用の辞書ファイルを登録したい、というとき、PDIC用辞書はMIME Typeにはないから、SAFで一覧に出てこない＝選択できない。
考えられる回避策としては、PDIC用辞書の拡張子を.mp3とかにして選択させる方法。
しかしこんなことをやってまでもGoogleは制限を厳しくしたいと考えているのか？
Google Playでの公開は諦めて野良アプリにしようか？
自分はいいんだけど、使ってくれる人がいるので何とかしたいと思うけど。
一言で言うと、PDIC以外で取得した辞書は使用できなくなります。
SDCardで持ってきたり、WebからダウンロードしたPDIC用辞書は使えなくなります！
PDICは辞書があってのソフトウェアなので、Google Playとおさらばするしか無さそう
これがセキュリティ対策だっていうんだから、なんともお粗末な発想だよね。。
2022.3.3
ファイル選択に必要とする権限(MANAGE_EXTERNAL_STORAGE)を追加して、Googleに申請したが却下された。
以下、一部抜粋。
問題が見つかりました。 重要な機能ではない
この権限を必要とする申告対象の機能は、アプリの重要な機能に不可欠な機能ではないようです。
辞書ファイルの設定は必須なんですけどね。。
本当にSAFでできることなの？
仮にSAFで辞書設定ができたとしても、タッチ検索のファイル選択の際もファイルの付随情報を一緒に表示しないととっても不便。
SAF対応をとりあえずやってみて、使い物にならないようなら野良アプリに切り替える。
古いバージョンに戻せば？と思う人もいるでしょうが、Google Playはそういうことを許していません。
開発者にもユーザーにも厳しい、自分を守ることが一番のGoogle Play
2024.4.7
Googleからメールが届き、適切な対応をしないとPDICがGoogle Playから削除されるそうです。
対応内容を大雑把に言うと、「私のアプリに害はありません」ということを色々聞かれる。
そんなの意味あるの？不思議なことをやらせるけど法律の関係だろうか？
悪意のあるヤツにそんなこと聞いたって全く意味はないし、多くの開発者には悪意はないので意味がない。
もしかして悪意のある開発者が増えてきたからそういう措置をしているのだろうか？
だとしたら野良アプリより、Google Playのほうが危ないかもしれない。
ソースコード全部渡すからGoogleのAIで解析してくれよ、って思う。
これが一番確実だと思うけど、なんでやらないんだろう？
もちろんいやだって言う人はいるので、そういう人はGoogleと禅問答を繰り返せばよい。
開発者である私から見ても呆れるセキュリティ対策なので、それを知らない一般ユーザーがこれを知ったらヤバいと思うだろう。
それはともかく、どこまで申告すれば削除されるのかがはっきりせず、もしかするとGoogle PlayからPDICが削除されるかもしれません。
そもそもPDICは長い間ずーっと基本野良でしたので、Android版が野良であっても何の違和感はないですけどね。
連絡先：
