Siesta はページ分割された URL をどのように処理しますか? 結果の複数ページを単一のリソースとして管理するメカニズムはありますか?
1 に答える
Siesta は、ページネーションの特別な処理を提供しません。ページ分割された URL は他の URL と同じように動作します。すべての URL は一意のリソースです。Siesta には、異なる URL からの応答を 1 つのリソースにマージするための魔法はありません。
つまり、ページネーション スキームが のようになっている/dingbats?page=3&per_page=10
場合、Siesta は「1 ページあたり 10 個の dingbats の 3 ページ目」を 1 つのリソースと見なします。ページネーション スキームが のようになっている/dingbats?since_serial_num=31415&max=20
場合、Siesta は「シリアル番号 31415 以降、最大 20 個の絵文字」に対して 1 つのリソースを持ちます。</p>
例
これは実際にはどういう意味ですか?たとえば、API がX-Next-Page
ヘッダー ( Github のページネーション スキームの単純化されたフレーバー) を返し、その結果を 1 つの無限にスクロール可能なテーブル ビューにマージするとします。
あなたは次のようなことをするかもしれません:
private var firstPageOfDingbats: Resource?
private var dingbats: [Dingbat] = []
private var dingbatsDisplayed: Int = 1
func resourceChanged(resource: Resource, event: ResourceEvent) {
refreshPages()
}
func refreshPages() {
// Naive implementation reconstructs the entire dingats array
// with each update — which is probably just fine, since array
// concatenation is cheap.
dingbats.removeAll()
var nextPage = firstPageOfDingbats
while let curPage = nextPage {
// This is a noop if data is up to date, but triggers a
// that runs down the list if it needs updating.
curPage.loadIfNeeded()
// Assuming you’ve set up a content transformer to parse
// the response as [Dingbat], you can pull them out of
// the Resource cheaply.
dingbats.appendContentsOf(
curPage.contentAsType(ifNone: [Dingbat]()))
// Don’t fetch everything if we’ve covered as far as the
// user has scrolled.
if dingbats.count >= dingbatsDisplayed {
break
}
// If we have data and there’s another page, keep going!
nextPage = curPage.optionalRelative(
curPage.latestData?.header("X-Next-Page"))
}
tableView.reloadData()
}
override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return dingbats.count
}
// etc.
// Add code to increase dingbatsDisplayed and call refreshPages()
// when user scrolls to the bottom
Siesta のキャッシングは、既にデータが存在し、すべてが最新である場合、ページのこの単純なトラバーサルを非常に高速に実行しますが、物事が古くなると更新のカスケードをトリガーします.
たとえば、古いエントリが変更されず、新しいエントリが上部にのみ表示されることがわかっている場合は、よりインテリジェントなアレイの更新を行うことができます。これは、使用している特定の API とその保証によって異なります。
Siesta のキャッシュをバイパスする
洗練された更新スキームを使用していて、要求された内容と結果をメモリに保持する方法を正確に制御したい場合は、Siesta のリソース キャッシュを完全にバイパスすることをお勧めします。ただし、そのためにシエスタを放棄する必要はありません。より伝統的なリクエストベースのアプローチにフォールバックするには、 および の代わりに メソッドを使用しResource.request(…)
ます。load()
loadIfNeeded()
paginatedResource.request(.GET).success { newData in … }
これによりpaginatedResource
、API の他の部分に Siesta のキャッシュを使用しながら、リクエストを自分で管理できます。