Recently I was accepted to become a co-maintainer of the Mobile Tools module. Originally created by Tom Deryckere a.k.a. twom it was and still is one of the most popular mobile site development modules in the Drupal-verse. It allowed site builders to manage their mobile URLs, switch themes for mobile devices and override a few site settings.

For the Drupal 7 release of the module, which is my main focus and reason for becoming a co-maintainer, we wanted to take advantage of the new APIs in Drupal and expand the tools available to mobile site builders. But there was a problem; the original module code base had become quite large and difficult to maintain.

Sufficed to say, we had to come up with a battle plan. And we did. We posted our plan in the issue queue for mobile tools.

Here's the breakdown:

1. Reduce the maintained code base by leveraging new core APIs or contrib API modules.
2. Refactor the code into submodules for easier updates and more granular deployments.
3. Remove any unnecessary or superfluous functionality.
4. Re-evaluate the requirements for building a "mobile" website and create new features accordingly
5. New Features
6. Performance and caching optimizations

Reduce the code base

The bulk of what Mobile Tools accomplished was the following

• Theme Switching
• URL Rewriting
• Device Detection
• Automatic Redirection
• Site Settings Overrides

Those four features encompass essentially everything the module could do. If we wanted to reduce our code base and keep all this working, we needed to bring in some friends to help us out. After scouring the contrib repository, we came up with the following breakdown of the features and which modules would contain the core functionality.

• Theme Switching: ThemeKey
• URL Rewriting: PURL
• Device Detection: Browscap
• Automatic Redirection: Mobile Tools API
• Site Settings Overrides: Spaces

Mobile Tools will now implement these APIs to rebuild the functionality it used to house itself.

Refactor into submodules

Since we're building a module for the masses, we have to include a wide variety of features into the code. But not everyone is going to use each feature and so if we aren't careful we can bloat down a site with unused code. For those reasons, we decided to break up the module into a set of submodules.

So far, here's the new structure:

• Mobile Tools
  • Mobile Tools Context
  • Mobile Tools Browscap
  • Mobile Tools Views
  • Mobile Tools Redirect
  • Mobile Tools WURFL

We kept the implementations of the new APIs for theme switching, URL rewriting and site settings overrides in the main module since these features are more than likely to be used all together most of the time.

Device detection, feature detection, roles, views and the rest of the other APIs and features we implement are now optional modules.

Remove superfluous functionality

Some features just need to go away. For example, in Drupal 6 the Mobile Tools Roles module allowed you to assign an arbitrary role to any mobile site visitor. Site builders could then use the access system to get their sites to display different menus, views displays, and the like. The goal of the module wasn't that mobile users needed a different role necessarily, it was more to allow different site building options to be changed or switched for more appropriate ones for mobile users.

Mobile Tools Roles may remain for users who actually want to assign a different role to their mobile visitors, but we're implementing some new contrib APIs to handle the bulk of what the roles module was used for primarily.

Features we're removing altogether are:

• Mobile Tools Roles
  • May be added back in but needs reimplementation in D7 if required
• Site redirection overrides (?device=mobile, ?device=desktop)
  • This is mostly used by developers which can instead use user agent spoofing to achieve the same result
  • For regular site users would want to view the full site can use the site switch URLs which automatically bring them to their current page but on the desired site type
• Site switch links in hook_menu()
  • Use the given block instead
• mobile_tools_goto() implementation of drupal_goto().
  • Replace by purl_goto()
• Default device detection
  • No device detection will be supported by Mobile Tools itself. You have to use contrib modules to do so (see Browscap)

Re-evaluate mobile site design requirements

A lot has changed in the last few years in the mobile space. Not only that, but with the loss of Flash for mobile and the focus on HTML5 and the new APIs within, we need to ensure we support those APIs where appropriate. Adding support for offline caching and manifest file generation and web sockets are two which we're looking into supporting.

Things like polyfills with Modernirz, socket.io to enable web sockets on older browsers, local or session storage in the browser. All things we'll be using to build new mobile applications. We need to ask the question "how can mobile tools help developers take advantage of these features?".

But beyond just the code, the way we build mobile sites and applications is changing. Responsive design and progressive enhancement are the big buzzwords right now and they introduce some new elements which we should consider integrating into Mobile Tools.

For example, with a responsive design you no longer need to switch to a totally different site design between users. But you may need some slightly modified elements on your page. Most of what you may want to do can be done with markup/css but in some cases you may want to have a table replaced by a definition list. Whatever it may be, if we can help site builders with making small adjustments for their responsive designs we should.

Another example would be with progressively enhanced sites. These sites work on a basis of "send the basic markup, test to see what the browser can do and enhance as necessary". Essentially a series of javascript tests are done to see what the browser can support and the javascript "enhances" what it can based on those test results. If we could capture those test results from the device we could then adjust the markup or the files sent.

For example, say a device doesn't support javascript at all, meaning the XMLHTTP Request function doesn't work. Since we didn't hear back from the device, we know the next time they request data, we can just skip sending the javascript. Or if the test results came back, we can adjust which files to send based on the tests.

I'm not saying all of these features will make it into Mobile Tools or if they're necessary to be included. This is more of an ongoing process of how to help new site builders using new methodologies and APIs.

Performance and caching

A big aspect of the redesign has been on performance. We reduced the code base to reduce the memory footprint (mind you if you weren't already using Purl, Spaces and ThemeKey then you'll probably see an increase in the memory used). But not only that, we chose modules which implement caching layers, work safely with HTTP request caching and set out to reduce the data sent to/from the user.

ThemeKey fully supports static caching for each theme switch. PURL has it's own caching mechanism to optimize when/if it needs triggering. Spaces uses the default object loaders and its own object loaders cache data as well. All in all, the new module should run very quickly in most environments and as lean as possible.

One major item, as I alluded to above, is the removal of hook_boot() and hook_init() in the main module. An any instance where another drupal bootstrap was required has been removed.

I'll be writing a followup post on caching with Mobile Tools and its new friends once we iron out details and do some testing with Boost, Varnish and any other cache we see fit.

How you can help

As you can see, there's a lot of work described here. Right now, there are three of us working on the module. There's the original author twom, myself (minorOffense) and mcrittenden who are maintaining the module.

As of the time of writing, we have the PURL integration working, some preliminary Spaces integration and a new "device groups" system for defining arbitrary site configurations (i.e. you can have a mobile site, a tablet one and a desktop, or an iPad site, an iOS one, an Android one and no desktop)

If you've got some free time to test, write documentation, or even contribute code we could use the help. Check out the Mobile Tools module page for more information.

If you have any questions or comments, you can leave them here, in the issue queue or on IRC in #drupal-mobile.