ListDataProvider vs AsyncDataProvider

[tong123123]

in a search page, assume the result return many record like 8000 records, and in the simplepager, each page display only 10 records, if using ListDataProvider, the 8000 records will be sent to client at once time and then render the celtable with all 8000 records in one time, the result is static.
if using AsyncDataProvider, each time the server only sent 10 records to client.
1) so AsyncDataProvider response is much faster, is this correct?
2) but how about if the user press the "last button" in the simplepager when the celltable using AsyncDataProvider? the speed is still similar to get the first page? that is, it only fetch records from 7990 to 8000 records only, bypass all the others (record before 7990)?
3) assume user input criteria fieldA = "XXX", if using asyncDataProvider, while searching, other user may enter record which fulfill the criteria fieldA = "XXX", so the total number of records in simpepager is continually changing? and so the first ten records in first page is keep continually changing?
4) anyway, in my case (searching with result return thousands records), AsyncDataProvider is more suitable then using ListDataProvider?

thanks

[Robert W]

ListDataProvider  with view creates only  item renderer count neccesary to fill view. You can override simple pager to implement eg constant row count com.google.gwt.view.client.HasRows in while searching

[tong123123]

Sorry, I am not quite understanding your reply.
anyway, I found that if my search results return near 10,000 records, the time spent in sql (DAO class) is only 4 seconds, but the time to return to the first line of method onSuccess (RPC call, async callback method, onSuceess method) need about 2 minutes. and once enter the first line in onSuceess method, then the time spent to go to the last line of onSuccess method is near 0 second!!
so where is these 2 minutes spent?
I think is these the time spent from copy 10,000 records from server to client?
and I think if I use asyncDataProvider, will these 2 minutes decrease dramatically?

[Ümit Seren]

That's not correct. You can still have a ListDataProvider that fetches all 8000 rows from the server but if you use a Pager and set it to page size 10 it will only render 10 items at a time. 

But I would not recommend it as you experienced yourself that parsing 10,000 records takes around 2 minutes. The reason why it takes so long is that it takes quite a long time to de-serialize 10.000 items (in case you use RPC). I think de-serializing JSON directly using for example JsonUtils which uses the native browser JSON parser should be faster than using the RPC transport format. 

But still I wouldn't recommend to transmit 10.000 rows. I guess around 2.000 should be fine. 

But if you don't transmit all records or if you want to support server-side searching you have to use AsyncDataProvider. 

However I also wouldn't transmit only 10 rows at a time as you suggested because the overhead of the HTTP request is not worth when you transmit only 10 items at a time. 

You can have a CellTable with page size 10 but use an AsyncDataProvider backed by a ListDataProvider. When the CellTable is rendered it will call the onRangeChanged event of the AsyncDataProvider. You fetch 2.000 rows and cache it in a ListDataProvider or normal list. Then if you go to the next page (rows 11-20) you don't send a request to the backend because you already have fetched rows 0-2.000, so you just get it from the ListDataProvider that you have stored/cached. 

2.) When you click on the last button of the simplepager the onRangeChanged of the AsyncDataProvider will be called and you can fetch the last 10 rows from the backend or your cached in memory list.

3.) I don't understand, can you elaborate

4.)  It depends. If you transmit all records in one request then you can do client side searching. However if you have thousands of rows or you search fields which you don't transmit to the client you have to do server side searching and for this you have to use an AsyncDataProvider. You can also mix both concepts. 

On Sunday, April 29, 2012 8:08:08 AM UTC+2, tong123123 wrote: