loggers | Loggers

2021-03-04 (木) 21:16

作業日報

やったこと

コンテンツ取得用不定期型バックグラウンドタスクの実装

わかったこと

v13から導入されているBackground Task Refresh/processingが導入されている。(Background fetchは非推奨)
- 注意点
  - 実機しか動かない。
  - デバック方法がめんどい。※参照
  - 不定期で実行される。
    - BGAppRefreshTaskRequestのearliestBeginDateは実行しない間の時間を示す。したがって、タスクをいつ実行するかはシステムが決める。
  - バッテリーなどシステムの状態で更新頻度に影響が出る！？。
- 感想
  - 基本的にドキュメントとサンプルに従えば、実装は用意。
  - 問題はバックグランドタスク内での非同期処理である。WebAPI呼び出しやDB操作などは、処理と処理の結果は分離している事が多いので、Operationは処理の結果を待つ前に消滅する。そのため、結果が反映がされない。結論から言えば、その対応の答えは上のサンプルの中にある。先ず、必要なのはOperationを非同期型に対応することである。このタスクが完了するまで、待たせるように実装する必要がある。Operationのいつくかのプロパティ、メソッド(isAsynchronous、isExecuting、isFinishedなど)をオーバライドするだけで、非同期処理に対応することができる。非同期処理自体はオーバライドしたstartメソッドの中で呼び出せば良い。また、バックグランドタスクでは、複数のタスク依存関係を定義することで、(一部)直列的にチェインすることができる。なお、今回の実装はswiftuiのlifecyleを利用しているので、Appのinitの中でタスクを登録し、バックグランド移行のイベント(.onChangeのnewScenePhase==.background)の中でスケジューリングを開始している。

つぎすること

to be continue

2021-02-10 (水) 19:38

作業日報

やったこと

画面パーツの作成

わかったこと

scrollview、list内での、子要素ジェスチャーの使い方バージョン2。
- scrollviewやlist内でジェスチャーを使う場合、子要素のviewが親のviewより先にイベント通知をキャッチする。これはjsのイベントフローで言うところのバブリングフェーズに相当する。DOMだと一般的にV字型に通知が渡っていく。通常、片側の上りのときに、イベントが処理されるため、上で言ったような反応になる。したがって、この場合、子要素以外の領域ではスクロール可能だが、当然、子要素のコンテンツ内では、スクロールは許されない。jsのようにこのキャプチャリングフェーズを指定して、下りでイベントを処理すれば、先に親が通知を受け取ることができる。swiftUIでこれを実現するには、親となるviewに対して、.highPriorityGesture(TapGesture())を実行する。この関数によって、親イベントが子イベントより先にイベント処理可能となる。引数はダミーである。TapGesture以外のジェスチャーの場合、そのviewでジェスチャーがずっと領域を専有して、スクロールができない状態になる。こうすることで、コンテンツをスクロールでき、同時に子viewのジェスチャーも操作できるようになる。

つぎすること

to be continue

2021-02-06 (土) 20:15

作業日報

やったこと

画面パーツの作成

わかったこと

当初の意図として、リストの中にあるオブジェクトをドラッグした後に見た目の反応を変えたいと思っていた。今のiOS14向けのSwiftUIでは、ScrollViewの中にDragGestureを持つ子供のViewがあるケースで、さらにScrollViewのドラッグとその子供のドラッグが同時に動作している場合、子供用ドラッグのonEndedイベントが発生しない(SwiftUIのバグ？？)。なので、子供のDragGestureにupdatingメソッドを追加して、ドラッグ状態をトラッキングするフラグを作る。そのフラグが立ってない場合、表示が初期化される。つまり、事前に表示する条件を決めておけば、フラグ状態変化でViewの表現を変えることができる。

つぎすること

To be continue