Looking further, I keep seeing threads on this forum about the inherent problems in Server Push in light of multiple browsers and environments, which threatens to make this problem seem unsolvable.
My initial problem is unchanged: I wish to send arbitrary information from server to client with the following restrictions:
the information is not the entire state of a component, but rather a small change to the state of one
a single update is expected to be a few hundred bytes or less
the entire state of the component may grow too large to efficiently send via onStateChanged in a custom connector
the client JavaScript is custom code (think section 16.13 in Book of Vaadin), not a ready-made Vaadin UI or widget
the transmission will need to work on different browsers eventually (i.e. no rush right now, but I don’t want to lock in to something that will only ever work on, say, Chrome)
I had thought that this would be achievable by a little extra code in MyComponentState.java and mycomponent-connector.js, but as far as I know, the only channel I have there is to set the entire component state and trigger an onStateChange.
Is there any other way to do this? Do I need to brave Server Push, or is it too unstable as yet? Should I use long polling? (I understand the theory behind it, but have no idea how it’s implemented in Vaadin, let alone Vaadin and custom JavaScript.)
If you configure your application to use push, Vaadin will determine the tech that works best for your particular server/browser combinations. You don’t actually need to specify a specific techniology (e.g. long polling).
However, you are somewhat correct about the state of the push technology itself; there are still lingering issues with certain servers / browsers / technologies that make life difficult for developers using push. You can get an overview by browsing the topics here and on SO, as you have done. Ultimately, the choice is up to you; something like long polling works quite well on most platforms and should be relatively safe to use.
Regarding how to actually implement the feature; I can’t remember if Vaadin always pushes the complete state or only the changes. Maybe someone from R&D can shed some light on this?
Regardless of whether push or regular HTTP is used, Vaadin only sends those shared state fields that have actually changed. In case of push, nothing gets pushed if there are no changes. In the client-side onStateChanged, you can query the event to see which fields have changed, or you can use @DelegateToWidget or the new @OnStateChange annotation to automate this work somewhat.
Note that the diffstate functionality does not extend to collections - a thousand-element List will always be sent as a whole even when only a single element has changed. If you need to pass collection changes efficiently, you might want to use RPC methods instead.
Aha, good news to hear, Johannes! I did not know Vaadin was smart about sending state.
It also make sense that it sends whole collections even so. …and that will make a difference in this case, since I will soon need to send just that. Hmm. There are ways I can take around that. RPC may be the better way. However, isn’t RPC only allowed from the client to the server, as opposed to the other way around? Bear in mind, again, I’m somewhat new to what web technologies are available, and what their tradeoffs are.
In general, it still seems odd to me that it would be so difficult to have the server immediately send information to the client when something happens on the server, on an ongoing basis. That’s essentially all I’m looking for here (I think). I see what appear to be instances of this happening all over other sites on the web - for example, chat windows, or even one of Facebook’s many widgets showing activity changes. I don’t have access to the underlying code on the server (all I have is the client), so I can’t tell how they’re doing it. I’m also not familiar enough with monitoring tools to see what’s happening that way (I wouldn’t sufficiently trust my ability to interpret what I’m seeing). Is it just continuous polling or long polling all around?
Vaadin allows you to use RPC in both directions, so you are good to go on that part. The difficulty with server to client communication is that the web was never designed to do that: basically the HTTP standard was meant to be one-way only (client contacts server). So, if you want to use server to client communications, you have to try to skirt the issue (long polling or HTTP streaming) or bypass it entirely (websockets).
Working from that, I went to the Book of Vaadin again, looking specifically for server-to-client methods using RPC, and came up empty, but I did find an article about it on Vaadin’s wiki. In the event anyone happens across this forum thread first, and wants to save some time:
You might notice some small modifications I made to that page - basically classes in the sample code that weren’t clear from the article itself, and made sense only if you had read certain other articles first.
I tried some of this code in my project, and it isn’t working yet. I’m not yet sure why. There are a lot of moving parts I still need to check. To be specific, I wrote test code that does nothing but have the server tell the client to put up a JavaScript alert with a simple test message; the code compiles and runs, but I see no alert.
One thing I read somewhere suggests to me that I might not see anything happen until the client sends its first request and gets its first response. The test code sends a number of JSON objects to the client JavaScript code, and then tries to send that alert. This is all in response to visiting a certain URL on my server. But maybe it needs to make another request, or the timing is somehow wrong? I’m making wild guesses here so far.
If you aren’t using push, you won’t seen anything before the client does a request to the server (because normally the server can’t contact the client itself, you need push for that).
Thank you for updating the wiki As far as example code goes, the Eclipse plugin can actually generate a simple component stub with RPC implemented both ways. Just go to file-new-vaadin widget, and select the ‘full fledged’ template. You can check all the parts needed from there.
As a traditional alternative to push techniques, you can resort to polling the server at a regular intervals. Just call UI.setPollInterval(milliseconds) to start polling. This is actually a fine option if you know the updates on the server are somewhat regular, so that unnecessary polling requests are not that common. As it only uses vanilla HTTP, it’s reliable and supported by pretty much anything.
Aye, Johannes, after some reflection, this sounds like the way to go as well. I can even get smart about it on the client, ramping down polling if activity drops, ramping back up if more activity appears. I dislike polling on principle, but in this case it shouldn’t be too bad.
As far as example code goes, the Eclipse plugin can actually generate a simple component stub with RPC implemented both ways. Just go to file-new-vaadin widget, and select the ‘full fledged’ template. You can check all the parts needed from there.