Thoughts on Spring Mobile: Adam’s POV

Adam Thody | November 9, 2012

Our “POV” series features insight and opinions from Architech’s thought leaders on the software development industry, technology issues and trends.

I was recently in Washington for the SpringOne 2GX conference and was keen to participate in a session presented by Craig Walls and Roy Clarkson titled, “Extending Spring MVC with Spring Mobile and JavaScript.”

The session sought to address several issues web developers face when dealing with mobile devices. There are two leading overarching approaches for coping with users browsing the web on mobile devices: responsive/adaptive design, and discrete mobile-specific experiences. As Walls and Clarkson demonstrated, Spring Mobile will help you with the latter approach.

The three standout features in Spring Mobile are the device resolver abstraction, site preference management, and the site switcher.

Device Resolver Abstraction

This resolver is useful when requests from mobile devices need to be handled differently than those from desktops by providing server-side device detection. On the surface, this appears to be useful, however I have some concerns about the approach.

First, the Device abstraction could be improved.

public interface Device {

boolean isNormal();

boolean isMobile();

boolean isTablet();

}

From a naming perspective, I take issue with “normal” being used to represent a desktop PC. With the way the industry is headed, mobile could easily be the new “normal” very soon.

Second, I’m questioning the value of distinguishing these devices purely by an arbitrary product label. There are now large phones and small tablets, and the use of screen size to distinguish between these classifications is likely to become increasingly problematic. For this to be truly valuable, I would much rather see this abstraction expose the qualities and/or capabilities of a given device, as opposed to its product category.

Next, we face the challenge of how to responsibly integrate these abstractions into our codebase. The approach can inherently introduce a lot of conditional logic and duplication to your application, which will make controllers much more difficult to read and maintain. One suggestion was to move as much of this logic as possible up into the ViewResolver abstraction. However, it would depend on how you intend to leverage this knowledge of which device is making the request.

Site Preference Management

It’s good practice – given a multi-site approach – to allow users to switch back and forth between a mobile version and a desktop version. I believe this practice will become less popular as responsive design practices become more commonplace. But it’s useful in the interim as many mobile sites don’t contain the same breadth and depth as their desktop counterparts.

In Spring Mobile, site preference management is implemented as a Spring MVC interceptor, which will determine the user’s site preference from the request. The site preference can then be accessed via a static SitePreferenceUtils method, or it can be injected directly into your @Controller as an argument.

Site Switching

In scenarios where it’s desirable to host a mobile site in a different location than the desktop version, the site switching component can manage redirection.

Overall, these tools are handy. But I can’t help but wonder how useful they’ll be in the not-too-distant future as the strategy for handling mobile users appears to be trending towards responsive/adaptive design, as opposed to serving discrete mobile sites. Perhaps we will see an opportunity to adopt a hybrid approach, where switching is used to choose between radically different experiences, and responsive is used for finer-grained tailoring to account for subtleties between devices.

Adam Thody leads our Web, Mobile & Cloud Practice. His team builds great-looking, powerful applications that leverage open web standards, cloud technologies, and open source. Connect with Adam on Twitter or Linkedin.

Leave a comment

Your email address will not be published.