Site Preference without SiteSwitcherHandlerInterceptor

[ghillert]

Hi,

I have been diving into Spring Mobile today. For my app I want to use existing Spring MVC controllers to render different views depending whether the client is a mobile device or a classic browser.

That part works flawlessly so far by injecting a org.springframework.mobile.device.Device into my Controller methods using the DeviceResolverHandlerInterceptor. In my simple use-case I want to keep the mobile and non-mobile content on one domain (aka I don't plan on using the SiteSwitcherHandlerInterceptor)

However, I want to also provide an additional feature to let mobile users switch to the full version of the website and stay on that full version for the duration of their session without having to use the SiteSwitcherHandlerInterceptor, which has the "site preference" feature that is part of the SiteSwitcherHandlerInterceptor.

Unfortunately, the "site preference" feature is somewhat embedded and I cannot use it stand-alone.

In the GIT repository I saw that in an earlier version there was a SitePreferenceResolvingHandlerInterceptor which was unfortunately removed in a later revision (http://git.springsource.org/spring-m...c6cb4e148278f4)

What was the rationale behind it? Does the current implementation of Spring Mobile 1.0.0.M2 allow for my scenario without doing my own customization?

Thanks!

[Keith Donald]

Gunnar,

Let me see if I understand:
- You don't need site switching; you only want to render a different view based on site preference.
- SitePreference resolution has been embedded into the SiteSwitcher, which makes it difficult to get this behavior standalone.

The rationale behind removing the SitePreferenceHandlerInterceptor was one of convenience--instead of having to register two intereceptors, we simplified it where you only had to register one. Also, I was unclear at the time if having a separate interceptor for SitePreference resolution would be worth it (looks like it it may just very well be).

That said, the SitePreference resolution code has been factored out into its own component, so it should be trivial to implement a thin HandlerInterceptor adapter that invokes it. Perhaps give that a try? BTW, feel free to also contribute any improvement back using the new Social Coding model (see http://blog.springsource.com/2010/12...ring-projects/).

Hope this helps.

Keith

[Keith Donald]

Gunnar,

As I noted on Twitter, I've pushed some improvements that better decouple SitePreference management from site switching. This includes adding a SitePreferenceHandlerInterceptor. Would you mind trying out the latest and see if it meets your needs?

Thanks!

Keith

[ghillert]

Hi Keith,

I am in the process of evaluating the changes now. Still working on a general write-up but things look good as far as I can tell, except for one issue.

In my controller I inject:

public String execute(ModelMap model, Device device, SitePreference sitePreference) { … }

I wonder if the SitePreference enum needs a default value "UNDEFINED". The reason is the scenario where I want the mobile version having access to the full version. Unfortunately, the value of SitePreference is always normal unless set to mobile.

Therefore, how can I determine that a mobile client is browsing my site but that mobile client wants to access the "normal" version instead?

Cheers,

Gunnar

[Keith Donald]

Gunnar,

I'm not sure I understand what you'd like to see--you said "I want the mobile version [to have] access to the full (normal?) version. Unfortunately, the value of SitePreference is always normal unless set to mobile. "

I don't quite understand, as a mobile user can get access to the full (normal) version by indicating a NORMAL site_preference. A SitePreference.NORMAL value should result in the full (normal) version being served to the user, which seems to be what you want.

When you say "Therefore, how can I determine that a mobile client is browsing my site but that mobile client wants to access the "normal" version instead?"

The user of the mobile browser needs to indicate his or her SitePreference by submitting a query parameter named 'site_preference' with the string value 'normal'. This is generally achieved by having the user click somewhere on the footer, for example, like you see at the bottom of http://speakerrate.com (View: Normal | Mobile). The lite-showcase sample provides a barebones demonstration of this. The indicated SitePreference will be saved in a cookie so it is remembered on future requests. All of this requires a SitePreferenceHandlerInterceptor (or SiteSwitcherHandlerInterceptor if you also want domain switching) to be plugged-in and declared after your DeviceResolverHandlerInterceptor.

In general, the site preference management behavior is now much better described in the reference manual, which has gotten a significant update in the 1.0.0.M3 release.

Let me know if I am missing something.

Keith

BTW, a side note: you can inject a "Model" reference instead of a ModelMap, which reads a bit better in the code.

[ghillert]

Hi Keith,

It turned out to be my bad - sorry for the confusion and the faulty message - I had a few configuration issues on my side.

Ultimately, in my opinion everything is working perfectly now. It turns out that I can even simplify my web controller to:

public String execute(Model model, SitePreference sitePreference) {

...

if (sitePreference.isMobile()) {
...
return "index-mobile";
}

return "index";
}

Thanks to the StandardSitePreferenceHandler, SitePreference will always be sesibly populated, even if no site preference parameter is explicitly set or the cookie does not exist, yet.

Great work! Did not encounter any further issues. You can see a working sample of the site preference feature at: http://www.devnexus.com/

Cheers,

Gunnar

http://blog.hillert.com/

[ghillert]

As I investigated the site preference feature of the M3 release over the past few days, I blogged about my experience at: http://hillert.blogspot.com/2011/02/...reference.html

Thanks for adding that feature!