Thanks for all the quick replies. When having to consider the back button
in a browser or an Android mobile device, it certainly changes the way you
think about architecting the standard goto(Place). My solution was to
build in a static placeCache into each Place, that way when getPlace is
called from the tokenizer the placeCache can be returned rather than
parsing the token.
//MyPlace extends Place
public static MyPlace placeCache;
@Prefix("tok1")
public static class Tokenizer implements PlaceTokenizer<MyPlace> {
public MyPlace getPlace(String token) {
//deal with null case if necessary
return placeCache;
public String getToken(MyPlace place) {
MyPlace.placeCache = place;
return "unused_tok";
}
}
//in another file once the item has changed
MyPlace.placeCache = MyPlace.create(newItem)
//then when the back button clicked on browser the new place is used
I am not too proud of the solution, but it works. I might try and put it
all in one class as you suggested.
On Wednesday, January 6, 2016 at 12:32:37 AM UTC-8, Thomas Broyer wrote:
>
> You need to somehow notify your cached data that it has changed; there are
> many ways to do that depending on how you architected things.
>
> You could have the cached list in a "holder" class and simply call a
> method on it from your update activity.
> Or you could send an event in the event bus for more decoupling.
> Or you could mediate all data access through a class that handles the
> caching and could update the cached list in-place.
>
> And when your list activity starts, either unconditionnally update your
> view, or check whether the list has changed before doing so.
>
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
