Hi all, the company I work for has agreed to let me allocate a good chunk of my time towards getting a stable D7 version of mobile_tools together, so I'd really love to help out. It looks like there's some good progress being made here, with commits made as recently as a few days ago, and the last thing I want to do is start writing patches for stuff that others are already working on, so I'd like to collaborate if you guys are up for it.

Basically, what's the status of the D7 version? What major things still need to happen, or is it all just fixing the misc bugs posted here? Is there anything specific you guys would like me to get started hacking on so that I'm not stepping on anyone's toes, or is anything fair game at the moment?

If you'd prefer to discuss on IRC or elsewhere then of course that's fine, just let me know. Thanks!

Comments

minoroffense’s picture

Status: Fixed » Active

Hey,

Great news, always looking for help! I'm the new co-maintainer and I'm still kind of ramping up on what to do and getting things organized. I've been working on a plan for mobile tools in D7. Based on feedback from twom (original maintainer/creator) I think we need to trim out some code and do more integration with modules which implement features we want. Stuff like theme switching, roles, access controls, etc...

Here's my initial breakdown of what I'd like to do. Looking for lots of feedback so go for it.

Project Maintenance

  • Create test cases
  • Enable automated patch testing
  • Create guidelines for patch creation
  • Set a regular release schedule (monthly? bi-weekly?)

Code

7.x-2.x

Split into submobules

  • Mobile Tools Roles
  • Mobile Tools Context
  • Mobile Tools Wurfl
  • Mobile Tools Browscap
  • Mobile Tools Panels
  • Mobile Tools Views
  • Mobile Tools API

Move any legacy D6 "tricks" to proper D7 API calls

  • Ex: Instead of hook_page_alter() to add javascript, use drupal_add_js()

UX and Documentation Improvements

  • Rewrite Mobile Tools administrative forms to use new D7 elements
  • Create an API doc
  • Create sample server configuration presets (using CTools exportables)

Update theme switching code

HTTP Request Triggers (PURL)

Replace any duplicate functionality with integration Spaces

Access controls

  • Use spaces_access to control user access to content

Enable Views display modes for mobile devices

  • Use Spaces to trigger views display switch. See spaces_og in the Spaces module for an example
  • See spaces_og in the Spaces module for an example

Replace/Update automatic redirect code

  • Use simpler method of redirection. purl_goto with location headers.
  • Move redirect call from hook_boot into hook_init()?

6.x-2.x

  • Mimic changes from 7.x as much as needed
  • Stabilize, bug fixes only
  • Requested features from D7 version can be backported
mcrittenden’s picture

Status: Active » Fixed

Awesome, thanks for the reply. I'll get started.

minoroffense’s picture

Great!

I think we should start with the Mobile Tools Context and Mobile Tools API modules. Since they both should give the most benefit to the most users right now.

I'll create the following structure inside the mobile tools module. We'll keep the main API module as mobile_tools and have it sit in the root of the mobile_tools directory. I'll move the submodules into their own module folders.

Ex:
mobile_tools
-- mobile_tools_roles
-- mobile_tools_context
-- mobile_tools_views
etc...

I'll also create an "unstable" release of the current dev version of 7.x-2.x to avoid surprises to anyone using the module right now. That way we can work without breaking too much for too many people.

What do you think?

mcrittenden’s picture

All good ideas, please do go ahead with them. :)

I'm going to spend a little time just digging around in the code and maybe knocking out a few small issues from the queue to get a feel for how everything's working in the meantime. If you'd like to chat on IRC at all, I try to hang out in #drupal-contribute a lot.

twom’s picture

hey guys,

Great seeing that you can drive the mobile tools future! I will be hanging out in #drupal-contribute too (twom) in case you want to circle back your ideas.

To start I think that splitting out functionality in submodules is a great idea for performance + maintenance reasons.

minoroffense’s picture

Sounds good!

I'm not in there terribly often but I can make a point to be. How about we touch base in IRC at least once a week to stay on top of things. I have 4PM EST on Wednesdays booked for Drupal.org work. I can guarantee I'll be in the chat at that time.

I've committed the changes to the 2.x-dev branch and I've created an unstable release of the module prior to the changes. I also started moving code into the sub modules. I think I have the context module working with Context and CTools (quick copy/paste and some tweaks from main module).

Once we have all the code split up, I'll start on the test cases for each module. And also figure out how to get automated tests running with patch submissions...

We can use this thread to keep the rest of the world up to date on what's up.

mcrittenden’s picture

Hey guys, since #drupal-contrib gets a little crazy, you want to agree to hang out in #drupal-mobile as much as possible? It's a lot calmer in there. Also, are either of you guys free tomorrow to set up a time to meet up in IRC and coordinate a little bit? I can do pretty much anytime except 12pm - 2pm EST.

twom’s picture

Sounds great, I'll be in the #drupal-mobile room as much as possible these days.

minoroffense’s picture

Same here

minoroffense’s picture

Update on where we stand:

I've almost got a working version of mobile tools using PURL to handle the url based switching PURL supports (by default) path, path pair, subdomain, domain, querystring and user agent triggers. You can also define other "processors" to trigger it. I believe this is where WURFL and/or Browscap would move their integration to. Similar to how the user agent switch in PURL works.

Once I update the blocks and create a means to allow users to exit the "mobile mode" I'll commit a new dev release for people to test.

This along with a new mobile tools context module thanks to mcrittenden we've got an excellent start to getting mobile tools to D7.

I've also fixed up some of the core code in mobile tools. Removed some old D6 ways of doing things, eliminated hook_init all together in favour of using Spaces to initialize changes. There are a few things in hook_boot that I think will have to remain, but I also pulled some code out of there as well. I added more checks for drupal in cli mode (namely in hook_custom_theme). I've borrowed some ideas from ThemeKey to do the theme switching as best as possible. We can look into using Themekey if we want to eliminate all our theme switching but that will have to wait for now. Don't want too many moving parts.

After the PURL integration is set, I'll move onto using Spaces to define device groups along with any settings and variable overrides for each group. This has the added benefit of allowing for exportable configurations for mobile device groups.

Thanks all!

minoroffense’s picture

I've updated the README file in the new version of mobile tools. I tried to explain as best I could how the module has changed and the new options available.

It's not complete yet but I think it's worth posting here for people to read and understand what's going on with the module.

minoroffense’s picture

README.txt
==========
The purpose of this module is to provide de Drupal developer with some tools that assist in making sites for defined "device groups".

INSTALLATION
============

This module has the following dependencies:

- [PURL](http://drupal.org/project/purl)
- [Spaces](http://drupal.org/project/spaces)
- [ThemeKey](http://drupal.org/project/themekey)

It can also take advantage of the following modules if available:

- [Session API](http://drupal.org/project/session_api)
- [BrowsCap](http://drupal.org/project/browscap)
- [WURFL](http://drupal.org/project/wurfl)
- [Modernizr](http://drupal.org/project/modernizr)

To install the module and all dependencies from the module administration panel.

Then you can begin configuration by going to admin/config/system/mobile-tools

You can enable any of the defined configuration presets, modify them or create your own.

USAGE
=====

Mobile Tools works with the concept of "device groups". A device group is any grouping of conditions or requirements for a given type of device or set of devices. Each defined device group can cause Drupal to display a different theme, override site variables, display different views displays among other things.

For example, you can define a set of device groups as follows:

- desktop
- tablet
- phone

Each can be triggered in various ways. The most common way is by a custom URL pattern. You could trigger each device group's settings by using the following URL structure in your configuration:

- example.com
- touch.example.com
- m.example.com

Subdomains aren't your only options. URL handling in Mobile Tools is powered by the [PURL](http://drupal.org/project/purl) module. This means you can active a device group using a different domain, path, path pair and more. You can even define your own PURL processor if you so choose. For more information on creating PURL processors, see the README.txt in the [PURL](http://drupal.org/project/purl) module.

Advanced Usage
==============

Automatic Redirection
---------------------
If you want to direct your users to the appropriate site automatically based on their detected device group, you have two modes you can use

1. First visit redirect
2. Automatica redirect

The first will redirect the user as their session is initiated. The device group is determined and then a one-time redirection will occur to send the user to the appropriate URL. If the user then decides to explicitly choose which device group site to visit, then the redirection won't interfere.

The second forces the user into their device group regardless of their choice. There is no means of overriding the automatic redirection.

Device/Capability Detection
---------------------------

Another way of triggering a device group is by using device detection. There are a few ways of detecting the type of device the user is using. You can go by the user-agent headers in the request object and use [Browscap](http://drupal.org/project/browscap) to determine the type of device. You could have a set of device groups as follows:

- iOS
- Android
- Gecko

Or you can use the [WURFL](http://drupal.org/project/wurfl) to determine the capabilities of the device and assign the device to an appropriate group

Example device groups based on browser quality:

- enhanced
- normal
- basic

Finally, along the same lines as WURFL, you can use [Modernizr](http://drupal.org/project/modernizr) to run its capabilities check on the device and report the results back to Drupal. This is the most accurate way of determining the capabilities of the device in use. If you get no return from the device, you'll have to assume that javascript doesn't work and assign the device to an appropriate device group. But if a return value is set, you can parse the test results and group your device accordingly. The results of that test are saved using the [Session API](http://drupal.org/project/session_api) module. This allows both anonymous and authenticated user device settings to persist.

@TODO describe the usage with modernizr

Device Group Contexts
---------------------

TODO

SETTINGS AND OPTIONS
====================

Each device group has two key functions:

1. Allow a theme override
2. Allow a site configuration override

The first is handled using the [ThemeKey](http://drupal.org/project/themekey) module. Each device group can trigger a defined rule in ThemeKey to switch the theme for the incoming request.

The second is handled using the [Spaces](http://drupal.org/project/spaces) module. Spaces allows you to override Drupal objects giving custom configurations for each Space. Each device group is it's own Space and therefore will load configuration options in the following order

1. custom
2. preset
3. sitewide

For example, when variable_get('site_name'); is called in a Space, it will first look at the spaces_overrides table to see if there is a value set for 'site_name'. Next, it will check any defined values in the Space preset for this value. Finally, it will load the normal value from the default Drupal table. For more information, see the README.txt in the [Spaces](http://drupal.org/project/spaces) module.

To configure each device group's Space settings, go to admin/structure/spaces.

CACHING
=======

@TODO rewrite any required caching mechanisms

AUTHOR/MAINTAINER
======================
Tom Deryckere
http://twitter.com/twom
http://www.mobiledrupal.com

CO-MAINTAINER
=============
Mathew Winstone (minorOffense)
http://twitter.com/mathewwinstone
http://coldfrontlabs.ca

CO-MAINTAINER
===========
mcrittenden (http://drupal.org/user/420631)

Status: Active » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

minoroffense’s picture

There hasn't been much movement on the 7.x-2.x branch in the last two months. Unfortunately other client work has taken precedent. However we have a new project starting today which will require a full version of Mobile Tools for D7 so the module should have a full release in the next two months.

We'll also be looking more at the D6 version once 7.x-2.0 is released. Backport features, bug fixes, all that.

Thanks for your patience!

Jeff Burnz’s picture

minorOffense - thanks for the updates, I'm running into problems left right and center (7.x-2.x-dev), do you want me to post issues or shut up for a while, I can wait ;)

minoroffense’s picture

Oh it's all sorts of broken.

I've been stuck on getting the Themekey code working. If you can figure out how to use their API so we can generate rules for Themekey that would save a lot of time.

Plus it's a component with very little work done so you're pretty much good to go on your own for it.

Otherwise, feel free to post as many issues as you like. The more we document, the more we can create a solid roadmap for completion.