検索結果を共有する
ここまでの実装は、地図と地球儀と、個別に設定していたので、
それぞれの表示を選択するたびにデータベースに接続してデータを取ってくるという、
とっても不経済なことになっていた。
AWSの無料お試し期間も終わってしまったことだし、コスパも考えないと。
それにこの方法だと、表示間の行き来もスムーズじゃない。
なので
- 検索ページで一括してデータ処理をする
- 結果をTab-Topで受け取る
- 表示形式に合わせて、データを各ページに配分する
という仕様に変更した。
これで、データペースの呼び出し回数を減らし、
同じ検索結果を、いろんな表示方式で見比べる、
･･･ができるようになる、はず。
沼って学んだこと
表示Tabは以下の五つ
- CLASSIC 事象のTileが時系列に並んでるだけの、古典的「年表」
- Scalable 事象を固定している時間軸を伸縮させることで、全体を見たり、詳細を見たりできる
- 大西洋中心地図 xy平面が世界標準の世界地図 z方向は時間軸（対数目盛）
- 太平洋中心地図 xy平面は緯度を205°シフトした太平洋中心地図 z方向は時間軸（対数目盛）
- 地球儀 球表面をBIGBANG時として、時間軸が放射状に広がる設定
だいぶ使い慣れてきたCLASSICとScalableは、スムーズに移行できた。
が、案の定、Scatter3D系がうまくいかない。
データは受け渡せているはずだが、
Div element not found と出て、表示されない。
基本的なことは4oに、悩みが深いときはo1と相談しつつも、
問題にピシッとフォーカスが合わないまま、悶々と過ごしているうちに、
来た！ o3-mini-high ！！
結果としては、o3が賢かった、のはもちろんだが
「悶々」の中で得た私自身の勘と、推論型AIとの対話の歯車がうまく合ったのだと思う。
一日150質問、という大きな枠が、積極的に対話する気分にさせてくれたのもうれしい。
- Scatter3D独自のrenderingとFlutterのrenderingのタイミングが微妙にずれている
が、問題点。
なぜ、これまでは問題にならなかったのか。
- アプリの時はパッケージflutter-echartsがよしなにやってくれていたらしい
- 個別実装の時は、まず地図を表示して、その後データを取りにいったので、その分の時差があった
今回は、Tabの行き来で即時表示を目指したのだが、
Flutterの非同期処理だけではカバーしきれず、
独自にDOM(Document Object Model)を待つよ、と明示的に処理する必要があった。
とはいえ、せっかくつけたloadingも表示されないほど瞬時に表示された。
ほんとに、ほんとに、微妙な差だったんだな、と思う。
非同期だけではなかった
五つの表示がきれいに出た！
と思ったのもつかの間、表示間を行き来すると、ときどき地図が出なくなる。
loadingも出ないまま真っ白に固まっている。
いつもではない、なら、どんなときか。
どうやら地図から地図に移ったときらしい。
echartsにはidがある
アマチュアが独学で進んでいて問題なのは、
「なぜそう書くのか」わからないまま書いているcodeが多いことだろう。
今回はechartsのid。
地図の時はecharts_div、地球儀の時はecharts_div_globeというidを
Sampleどおりに書いていたのだが、
これが二つの地図で競合した。
- アプリの時はパッケージflutter-echartsがよしなにやってくれていたらしい
- 個別実装の時は、そもそも地図間を行き来する、という仕様ではなかった。
このidは自分で設定してよい、らしいので
echarts_div_atlantic と echarts_div_pacific に分けて、無事、解決。
さ〜 まだまだ先は長いよ〜
コード詳細にご興味がある方はこちら
実装結果はこちら
日本語を選んでStart → 詳細版 → 検索と表示 → 適当に検索して確定してSHOW
だいぶ奥の方にあるので、なかなか到達しませんが笑
Discussion