[draft] a simple PagedIterable / PagedResponse #43484
Conversation
| * | ||
| * @param <T> The type of items in the page. | ||
| */ | ||
| public final class PagedResponse<T> implements Response<List<T>> { |
There was a problem hiding this comment.
For azure-core, the PagedResponse is an interface. The implementation is in PagedResponseBase. Should we do the same for clientcore?
In such case, we can even generate the implementation class in emitter (so clientcore does not need to have the PagedResponseBase class).
| private void receivePage(AtomicBoolean receivedPages, PagedResponse<T> page) { | ||
| receivedPages.set(true); | ||
| addPage(page); | ||
|
|
||
| continuationToken = page.getNextLink(); | ||
| this.done = continuationToken == null || continuationToken.isEmpty(); | ||
| } |
There was a problem hiding this comment.
The receivePage (and related var) would be different, if server support both continuationToken and nextLink.
SDK likely would only provide one pageRetriever with either of the approach. It may also provide a e.g. continuationTokenRetriever to specify whether to call getNextLink or getContinuationToken.
|
API change check APIView has identified API level changes in this PR and created following API reviews. |
weidongxu-microsoft
changed the title
design https://gist.github.com/srnagar/e9373153593920dcf1977c928c59e988
Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:
General Guidelines and Best Practices
Testing Guidelines