UI Refresh

Vaadin 6 / 7 / 8
1

Hi All,

We are embedding a vaadin app in a host app. The host app refreshes at a regular interval. As the host app refreshes, sending the same http request to the vaadin app, we’d like to treat it as a normal browser refresh. This way, a user who has navigated off of the vaadin app’s main page will not be suddenly re-directed back to the main page on refresh.

Today when the host app issues the same request, the vaadin request that gets created is given a different v-wn and hence a new vaadin UI. Is there a way for us to achieve the above?

Thanks,
Rebecca

2

Do you have @PreserveOnRefresh
annotation on your UI?

3

@Override
protected final void refresh(final VaadinRequest vRequest) {
init(vRequest);
}

4

Thanks Agata. Yes, we are already using the @PreserverOnRefresh annotation. In fact, when we run the Vaadin application on its own (not inside the host app), the browser refresh works as expected.

Thanks Thanh Luan Vo. I am afraid overriding the refresh method doesn’t help because we are already in a new UI. More explanation below.

Our host application launches the Vaadin application in an iFrame. The iFrame initially shows the Vaadin application’s main page but the user may navigate to other pages. The host application refreshes at a regular interval, issuing the same http request to update the same iFrame. What we’d like to achieve is, on host app refresh, the vaadin app stays where it is, maintaining all its context. What we get appears to me is that when the embedded Vaadin app gets the same http request, it treats it as a new request (by giving it a different v-wn) and gives it a new UI.

I tried ‘borrowing’ the PageRefreshHandler code from https://dev.vaadin.com/ticket/12191. I changed the code (see attached) so that when the same request comes in, it re-uses the request saved in the session and hence re-using the existing UI. It works really well except that after about 15mins, it appears to time out with an NPE from the LegacyCommunicationManager.getClientCache (LegacyCommunicationManager.java:104), see attached. Any idea how to prevent this?

22311.java (4.72 KB)
22312.png

5

I wonder if a doFilter could be positioned to help with this? If the http request can be identiefied as due to the refresh, and/or if the UI is in some condition where you know a refresh is not wanted, then have the doFilter drop the incoming request before it gets to Vaadin.

6

Thanks Steve. Unfortunately we don’t see a way to detect a refresh before it gets to Vaadin. However, we do have a way to tell if it is a refresh once a request gets to Vaadin. Here’s how we do it.

When the host app first launches the Vaadin app, it uses, for example,
http://localhost:8081/#!aPage/logon=aUser/callerId=xxx, where xxx is UUID.randomUUID().toString().

Seeing this is a first time request, the UI renders the main page. The user may navigate off to a subpage.

  • When the host app robotically issues the same request, using the exact same callerId, we know that it IS a refresh.
  • If the user navigates back to the host app (and hence closing the iFrame hosting Vaadin) and then launches Vaadin again, the host app issues the http request using a different callerId and so, we know that this is NOT a refresh (and thus direct the user to the Vaadin’s main page).

I was hoping that there is an easier way to do this instead of using the ‘hack’ I sent out earlier. Also, with the ‘hack’, I am not sure exactly what causes the NPE and if there is a way to get around it. Any help would be most appreciated.

7

We were hoping this would be a good way to allow us to migrate different parts of our application to Vaadin.