Build a Mobile and Desktop-Friendly Application in Django in 15 Minutes

Be careful with this line:

ua = request.META['HTTP_USER_AGENT'].lower()[0:4]

Browsers can be set to not send the User-Agent Header and this line will throw an exception! Safer like this:

ua = request.META.get('HTTP_USER_AGENT', '').lower()[0:4]

John

You can use djangobile (http://code.google.com/p/djangobile/). Djangobile support client detection according to User Agent (using WURFL) and allows only one logic and N templates and other interesting features ;-P
I would like DeviceAtlas formed part of procces of device detection, although the ideal would be to implement the interface proposed by the W3C (http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/).

Regards.

I rather like the idea of using the context processor, rather than hardcoding the switched templates to the view.

(Especially if you are using default views and can't so easily change the template as you do above.)

So here's an approach that seems to work quite well.

First create the context processor. Somewhere (say in views.py) :

def mobile_context(request):
  host=request.META['HTTP_HOST']
  if host.endswith('.mobi'):
    return {
      "mobile":True,
      "page_template":"page.mobile.html"
    }
  return {
    "mobile":False,
    "page_template":"page.desktop.html"
  }

Then in settings.py make sure this processor is called:

TEMPLATE_CONTEXT_PROCESSORS = (
  "django.core.context_processors.auth",
  "django.core.context_processors.debug",
  "django.core.context_processors.i18n",
  "django.core.context_processors.media",
  "views.mobile_context"
)

Then, create two base templates, page.desktop.html and page.mobile.html. These are the outer page structures for the two types of page (and should include the appropriate XML declaration, html, head, CSS etc for the two types of browser)

Then have a single base page template (called, say page.html) that merely provides a dynamically-decided extension of one of these two templates:

{% extends page_template %}

(It's very helpful that 'extends' can take a variable argument. Note this variable has been set by our context processor.)

And now all your app's pages can extend page.html, and the switching kicks in magically, without changes required to any of your app's existing view code.

If you do need to toggle on or off parts of the UI down within your templates (say extraneous panels that clutter up a small mobile UI), you can use the 'mobile' variable (also set by the context processor) to turn them on or off.

Endless extension of this idea possible of course... more complex inheritance, more variables available (screen width, anyone?) and more theme variations for broad varieties of device.

You could hook DeviceAtlas in to the context processor too - to fill out some of this capability richness and make it available to a theme author.

In fact, I've been taking this further, and attempting to blend the switcher technique into Django.

The catch with using context processors alone is that if you decide that you want to invoke a redirect of any sort (say, the user has come to one domain when they've previously expressed an preference for the other), you're not really in the right place to create an HttpResponse.

The most Djangonic (?) way to implement a solid switcher seems to be to have a middleware class intercepting the request in process_request() and determining the outcome there, as per the algorithm. Any redirects or interstitials can be presented before any 'normal' view processing has begun.

Then, on the way back out of the middleware, in process_response(), you can set any preference cookies.

I added items to the request.META dictionary in order to communicate between the two sides of the middleware. This data can also be read by the context processor, though, so if you want, you can get the middleware to decide the template (whilst it's at it) and the information needed for the intra-site links - and then have the context processor pick those up just prior to the views, in order to populate some helpful variables for your template.

Does that make any sense? I suppose I should figure out how to package this to share ;-)

Like as James Pearce pointed above, I agree about using a middleware and a context_processor. The djangobile project works in that way.
Setting a new context processor in your project settings.py

TEMPLATE_CONTEXT_PROCESSORS = (
    # This context processor is required to djangobile works properly.
    'djangobile.context_processors.mobile',
)

In a summary, the context_processor is

def mobile(request):
    user_agent = request.META.get('HTTP_USER_AGENT', 'default_user_agent')
    if hasattr(request, 'device'):
        device = request.device
        if (getattr(settings, 'DEBUG', False) and
            getattr(device, 'user_agent', False) != user_agent):
            device = get_device(user_agent)
            request.session['device_id'] = device.id
        return {'device': device}
    if request.session.test_cookie_worked():
        request.session.delete_test_cookie()
        device_id = request.session.get('device_id', False)
        if not device_id:
            device = get_device(user_agent)
            request.session['device_id'] = device.id
        else:
            device = get_device(device_id=device_id)
    else:
        device = get_device(user_agent)
        request.session['device_id'] = device.id
    request.session.set_test_cookie()
    return {'device': device}

Besides, the middelware is only a call to the context_processor function.

class DjangoMobileMiddleware(object):
    def process_request(self, request):
        if not hasattr(request, 'device'):
            device = mobile(request)['device']
            setattr(request, 'device', device)
        return None

The key function get_device gets a Device object from to WURFL and the render_to_response function (and associated functions) in djangobile selects the right template according to device capabilities or custom families definitions.

The templatetags extends and include can be overriden in order to delegate device detection to them, avoiding changes in the logic layer.

The templates directory could be

templates
|- application
|--|- form.html
|- iphone
|--|- base.html
|--|- application
|--|--|- form.html
|- base.html

Versae (& James),

I completely agree that doing this in a middleware class is a better and more "Djangonic" way to do it. Versae, per James' comments, watch this space for updates. We will try to do a follow up article on this at some point.

Hi Ronan Cremin,
Can you point source for code or make your walk through simpler for novice?

My website is hosted with Word Press using plaintxtblog theme of Scott Wallick.

Regards,
Ashok Koparday