の呟きは 58
久々のオフラインの夜
- (UPD ) #
オフラインなのでIDPWMemo10はお預け・・・（実機テストができない）
moneymemoのほうは作業やろうと思えばできるはず
公式ドキュメントは付属してるわけだし
- (UPD ) #
あー、実機テスト
その気になれば
スマホを直接PCと繋いでapkファイル移動という方法も・・・あるのかなまぁ一応、開発用のドライバはダウンロード済みでインストール済みでもあるから
スマホ本体のほうの開発モード解放すれば
その名のとおりの実機テストを実行できるが・・・SIM無しの遊び機ならまだしも
普通に家族との連絡用なので
開発モード解放はちょっとためらわれる
待って、スマホ本体とＰＣとを繋いだ状態でファイル移動って、このスマホではやったことないのだけど
microSDカードとか入れてなかったと思うし
できるのかなぁ・・・
まぁスマホ側に持っていけそうならやるか・・・？
ボーナスダンジョンの鍵、３個ともゲットできて
結果は
ドラキー１、ゴールド１、ハズレ７
まぁまぁラッキーの結果錬成武器
まさかガイアのつるぎが来るとは思わず・・・
これでまた輝石入手が必要に・・・orzつか経験値稼ぎも辛い
プラズマウエーブ（？）
まぁまぁの強さだけど
１１章２話フィールドではややきつい
４３フィールドでは上ブレすれば一撃そしてその全体攻撃は強化されない・・・という・・・かなしい
ジバリア単体の高火力はこれしか持ってないので強化されるのは純粋にありがたいことでもある
さて、IDPWMemo10
時間制約をどうつけるかだが別のアクティビティを開くとonPauseが呼ばれる、と
Ativitiyのドキュメントの図に無くテキストで説明だけの罠っぽいのが
onStartからonResumeに移る場合と、onStartからonStopに移る場合と、があると…
これは、罠では？ユーザーに見えるような状態になったときにonStart来るけど
ユーザーがなんらかの方法で非表示にするとonStopに移行するらしいonDestroyって使い方不明だな・・・
システム側はともかく
アプリ開発者にとってどういう意義が・・・？
onPause後からでもonStop後からでもシステムが強制的にKillすることがあると書いてあるしまず
親ビューア側
これ単体ならonResumeとonPauseだけで済む- (UPD ) #
問題は子アクティビティを開いたとき
onPauseもonStopも呼ばれる可能性はあるもののkillされなければ親アクティビティのメモリは維持されるため、時間制限の情報は生存するが、killされたら、保存しないかぎり消える、がしかし、killされたらOpenしたMemoも消えるので、そもパスワードなしじゃ復帰しようがないというのがあるそも、子アクティビティ開いて長時間放置という状況はあまり・・・ないような
Service/Value/Secretの追加・編集・削除・エクスポートのアクティビティであり、長時間開きっぱはまず無さそうなので、onStopはまず来ない（まぁエクスポートはあるかもだが
とはいえ、ブラウザなど他のアプリと行き来しながらIDPWMemoにデータを入力していくとなると、親ビューアがkillされる可能性がある（最悪、子アクティビティもkillされうるがｗ- (UPD ) #
IDPWMemo10は軽量なアプリのはずなので
そう滅多にKillされないと思いたいが・・・
ポケGOプレイではkillされた形跡があったブラウザはわからｎ
- (UPD ) #
子アクティビティからの戻り
onResumeとonActivityResultのどっちが先に呼ばれるかという部分をどうするか、という
子アクティビティを開いてonPauseなのか
外部の他のアプリに移動してonPauseなのか
まずこの区別
後者の場合のonResumeではそのまま時間制約処理していいが
前者の場合は…onActivityResult呼び出し前なら復帰処理を保留してonActivityResultで復帰処理を決定する…？、onActivityResultが先に呼び出されている場合は…どうする？、どちらもUIスレッドのはずなので同時並行処理はないので必ずどちらかが先に実行されて一方はその実行後なので状態情報を持てば状況の区別はできるはず・・・？- (UPD ) #
状態表？
子表示 onResume onActivityResult
yes before before
no after after
存在しうる組み合わせは
onPause内 no before before (子じゃないアプリ）
onPause内 no before before (killでyesが消えた）
onPause内 no before before (killでyes,afterが消えた）
onPause内 no before after （killでyesが消え先にonActRes）
onPause内 no before before (killでafterが消えた）
onPause内 yes before before
onPause内 yes before after
onActivityResult内 no before before (killでyesが消えた）
onActivityResult内 no before before (killでyes,afterが消えた）
onActivityResult内 no after before (killでyesが消え先にonResume）
onActivityResult内 no before before (killでafterが消えた）
onActivityResult内 yes before before
onActivityResult内 yes after before
状態多い・・・？- (UPD ) #
killでafterが消えるとしたら
かなり特殊な状況で
onResumeが呼ばれたあと即onPause移行でonActRes呼ぶ前にバックグラウンドに来てkill
と
onActResが呼ばれたあと即onStop移行でonResume呼ぶ前にkill（onActRes時にはKill前でMemoの編集には成功している可能性もある、onActRes時点で一度killで失敗している可能性もある）
の２パターン？
ユーザ操作のスピードと、プログラムの処理のスピードは、雲泥の差があるので、奇跡的なタイミングで起きるかもしれないレベルだが、起きない保証はない・・・といったところかonActResでは、おそらく、killでMemoがnullになっているので処理失敗に終わる、というだけで（それはそれで悲しいが・・・Value/Secretに設定した値を脳みそで覚えていられなかった場合は・・・
onPauseのほうではどうだろう
killが前提ならどのみちMemoはnullなわけで
その後にonActRes呼ばれようが失敗に終わるだけだし・・・？
noのシチュではyesやafterが消えようとも関係なく、Memoはnullで子は失敗、という結果か- (UPD ) #
kill前にonActResだけが呼ばれたというシチュ以外では、Memo変更は失敗
という感じだな（afterが消えたケース
noのシチュは考慮必要ないという感じなので
yesの分岐について考えれば・・・よい？- (UPD ) #
onPause内 yes before before
… 表示復帰処理をonActResに任せる？
onPause内 yes before after
… 表示復帰処理はonPause内？子はキャンセル以外の結果ならタイマークリアというのがありうる？タイマーどおりの時間切れ判定でよい？
onActivityResult内 yes before before
… 表示復帰処理はonPauseに任せる？キャンセル以外の結果ならタイマークリアしとく？
onActivityResult内 yes after before
… onPauseは表示復帰処理を保留したはずなので、表示復帰の処理をやっておく必要がある？キャンセル以外の結果のときは表示タイプ維持で、キャンセルのときは時間切れ判定がいる？つまり
onPauseではyes before beforeのときのみ、メソッドから即脱出し
それ以外では通常処理で無問題onActivityResultでは
キャンセルもキャンセル以外も
表示復帰するかの判定が必要か・・・
- (UPD ) #
onActivityResultの説明によると
onResumeの前に呼ばれることが保証されているぽい・・・？
setResultを見たかんじ
RESULT_CANCELEDでもIntentデータを渡せそうな雰囲気だな？今気付いたけど
android-29のソースをダウンロードしてた
Activity.javaを見たが
setResultはシンプルに同期処理
onActivityResultは空なんだが・・・？superを呼び出せとかじゃなかったっけ・・・？そんなことは書いてなかった・・・
noHistoryがtrueだと呼び出されないらしい
startActivityForResultの中身を眺めると
なんか色々かいてあるな・・・
デフォルトの戻るがキャンセルでデータなしなのは、初期値なだけか
どころでフィールドのプリフィクスmは何なの？
private以外にもついてるが・・・
アクションバーの戻るからだとonActivityResultが呼ばれなかったのは
単純なfinish()じゃないルートで呼ばれていたから？
よくわからん
このソースをjavadocでドキュメント出力するとかすれば
ＡＰＩリファレンスを得られそうだけど
ソース無限大あって
時間かかりそうだし
何より、アノテーション・・・ちゃんと処理できるのか否か・・・
