Queueing in offline mode

[ilab]

Hello,

Queueing does not work in offline mode.
I'am not sure whether it is intended or not (I havent' found any restrictions in the docs) but in my understanding, there should be no reason for disabling queueing in offline mode.

Example:

public class dummyModule implements EntryPoint {

    public Canvas getViewPanel() {

        RestDataSource dummyDS = new RestDataSource();
        DataSourceField itemIdDsField = new DataSourceField("itemID", FieldType.TEXT);
        itemIdDsField.setPrimaryKey(true);
        DataSourceField itemNameDsField = new DataSourceField("itemName", FieldType.TEXT);
        DataSourceField unitCostDsField = new DataSourceField("unitCost", FieldType.TEXT);
        dummyDS.setFields(itemIdDsField, itemNameDsField, unitCostDsField);
        dummyDS.setDataURL("http://127.0.0.1:8888/dummyData.jsp");        
        dummyDS.setUseOfflineStorage(true);

        final ListGrid grid = new ListGrid();
        grid.setWidth(400);
        grid.setHeight(250);
        grid.setDataSource(dummyDS);
        grid.setAutoFetchData(true);  
        grid.setCanEdit(true);        

        HLayout hLayout = new HLayout();
        hLayout.setMembers(grid);

        VLayout layout = new VLayout(10);

        final IButton offonButton = new IButton("Clickme", new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                RPCManager.startQueue();
                Offline.goOffline();
                dummyDS.addData(new Record());
            }
        });
        layout.setMembers(hLayout, offonButton);
        layout.setAutoHeight();

        return layout;
    }

    public void onModuleLoad() {
        getViewPanel().draw();
    }
}

Just press "Clickme" and you will see "WARN:Log:Data cannot be saved because you are not online" on the console.

SmartClient Version: v11.1p_2018-07-14/LGPL Development Only (built 2018-07-14)

[ilab]

Isomorphic, would you be so kind as to drop a note whether this is considered a bug and just there is some work in progress or it is not?
It would be nice to know whether it is worth waiting or we should start developing the functionality which is pretty much the same as queueing.
Thank you!

[Isomorphic]

What specifically were you expecting with this use case? Is the problem that a subsequent fetch in the same queue (not shown in your test case) wouldn’t work because the queue immediately fails once an “add” is attempted?

[ilab]

The expected behavior is the queue doesn't fail and the "add" succeeds.
Later, RPCManager.sendQueue() can and should fail if the app is still offline.

Considering that no network communication would be triggered by the "add" even if the browser was online, I see no reason for failing with the message "Data cannot be saved because you are not online".

[Isomorphic]

Ah - the problem here is that the browser doesn’t give us a reliable way to detect that a URL starting with “http” is going to be accessible in “offline mode”, both because of different DNS configurations and because offline mode may mean the network adapter is actually disabled.

Does this test case represent your actual use case (a service on the end user’s machine) or is it contrived? If it’s contrived, what is the actual use case? The only solution here may be to add a flag that forced a network request to be attempted even in offline mode.

[ilab]

It is contrived.

As for the real use case, the service is on a remote server as usual. The user goes to an area where she has no internet connection temporarily, still, she needs to be able to use the application readonly mode (with restrictions, of course), which can be satisfied using Service Workers and SmartGWT DataSource::setUseOfflineStorage().

However, the user needs to be able to make basic changes in data grids also, which changes are to be synched to the remote server later when she is online again.
In my understanding, this could be implemented by using queueing, if queueing wasn't blocked for some reason when the browser is offline.
IMHO, online status shouldn't be checked if queueing is switched on, since actually there is no need to be online, only when sending the queued request to the server with RPCManager::sendQeuue().

[Isomorphic]

Storing up changes for later delivery to the server while making local updates is totally unrelated to what queuing does - read about what it actually does in the QuickStart Guide.

We’ve implemented what you describe before (for a specific customer), and what you basically want to do is implement a dataProtocol clientCustom DataSource, and when the server is not available, provide a DSResponse that matches the request and store the DSRequests for later execution when the server is available again.

Because we’ve already got a working version of this in an older project, this would be a relatively inexpensive Feature Sponsorship, if you prefer this as a built-in.

[ilab]

I know that the intention of queuing seems to be different for the first glance but if you consider collecting changes in offline mode for later delivery as providing the user a possibility to collect a set of changes to a transaction which will be commited later on her decision - and actually this is the very case, then you can see that this is not that different at all.

Moreover, being offline is irrelevant here. Let's consider the following use case: the user wants to be able to start a transaction for whatever reason, make some changes (possibly on different data grids but thats optional) and commit them (or fail) at a point of time as a whole. Something very similar is actually written in the quick start guide, by the way

Then, imagine the following conversation between the user (advanced version, knows about browser developer console) and the app support:
(user): Hey support, very nice app, but... I started the transaction and made 2 changes in the grid, then lost network for a few minutes and wasn't able to continue my work until I was online again, why is that?
(support): But... man, you have just said you lost connection.
(user): Okay but I checked and it seems the app didn't need the connection for the first 2 changes, then what happened at the 3rd?
(support): Erm... okay...

As for the feature sponsorship: thank you for the proposal, if I fail to convince you that our use case is valid for queuing and that its current behavior is not right :) we will consider it

PS: thank you for your time, I might be totally wrong with my theory but it really seems valid to me :)

[Isomorphic]

What you're missing is that queued requests do not have their changes reflected in local components, which makes it entirely inappropriate for the use case described.

For the use case of modifying multiple records described in the QuickStart, what happens is that the grid component accrues the unsaved changes (not using queuing), then submits them all together, synchronously, using queuing to do so. So no such problem as you describe would occur. Users can and do continue to interact with a ListGrid while offline, and nothing is lost, even if a save to the server is attempted while offline (and fails, obviously).

Finally, if you left an unfinished queue sitting there during further interactions, that would mean that other network requests would also be blocked, which is obviously not intended or desirable.

So again, the queuing feature is as described in the docs, and has basically nothing to do with the feature you're looking for. Further, trying to cram the functionality you're looking for into the queuing system would be an architectural disaster - it's just a totally different use case, so you'd end up with a bunch of weird flags that would toggle the queuing system between what it does now, vs behaving in this totally different way. So if added as feature, we would use the approach we've already proven, which would appear as a separate set of APIs unrelated to queuing.

[ilab]

Thank you for very much your answer, I am off for 2 weeks, I will respont after.

[ilab]

Okay, I get it now (more or less) thank you!