Package: django-mobile-platform
django-mobileprovides a simple way to detect mobile browsers and gives
you tools at your hand to render some different templates to deliver a mobile
version of your site to the user.The idea is to keep your views exactly the same but to transparently
interchange the templates used to render a response. This is done in two
steps:A middleware determines the client’s preference to view your site. E.g. if
he wants to use the mobile flavour or the full desktop flavour.The template loader takes then care of choosing the correct templates based
on the flavour detected in the middleware.InstallationPre-Requirements:django_mobiledepends on django’s session framework. So
before you try to usedjango_mobilemake sure that the sessions framework
is enabled and working.Installdjango_mobilewith your favourite python tool, e.g. witheasy_install django_mobileorpip install django_mobile.Adddjango_mobileto yourINSTALLED_APPSsetting in thesettings.py.Adddjango_mobile.middleware.MobileDetectionMiddlewareto yourMIDDLEWARE_CLASSESsetting.Adddjango_mobile.middleware.SetFlavourMiddlewareto yourMIDDLEWARE_CLASSESsetting. Make sure it’s listedafterMobileDetectionMiddlewareand also afterSessionMiddleware.Adddjango_mobile.loader.Loaderas first item to yourTEMPLATE_LOADERSlist insettings.py.Adddjango_mobile.context_processors.flavourto yourTEMPLATE_CONTEXT_PROCESSORSsetting.Now you should be able to usedjango-mobilein its glory. Read below of how
things work and which settings can be tweaked to modifydjango-mobile’s
behaviour.UsageThe concept ofdjango-mobileis build around the ideas of differentflavoursfor your site. For example themobileversion is described as
one possibleflavour, the desktop version as another.This makes it possible to provide many possible designs instead of just
differentiating between a full desktop experience and one mobile version.  You
can make multiple mobile flavours available e.g. one for mobile safari on the
iPhone and Android as well as one for Opera and an extra one for the internet
tablets like the iPad.Note:By defaultdjango-mobileonly distinguishes betweenfullandmobileflavour.After the correct flavour is somehow chosen by the middlewares, it’s
assigned to therequest.flavourattribute. You can use this in your views
to provide separate logic.This flavour is then use to transparently choose custom templates for this
special flavour. The selected template will have the current flavour prefixed
to the template name you actually want to render. This means whenrender_to_response('index.html',...)is called with themobileflavour
being active will actually return a response rendered with themobile/index.htmltemplate. However if this flavoured template is not
available it will gracefully fallback to the defaultindex.htmltemplate.In some cases its not the desired way to have a completely separate templates
for each flavour. You can also use the{{ flavour }}template variable to
only change small aspects of a single template. A short example:<html>
<head>
    <title>My site {% if flavour == "mobile" %}(mobile version){% endif %}</title>
</head>
<body>
    ...
</body>
</html>This will add(mobile version)to the title of your site if viewed with
the mobile flavour enabled.Note:Theflavourtemplate variable is only available if you have set up thedjango_mobile.context_processors.flavourcontext processor and used
django’sRequestContextas context instance to render the template.Changing the current flavourThe basic use case ofdjango-mobileis obviously to serve a mobile version
of your site to users. The selection of the correct flavour is usually already
done in the middlewares when your own views are called. In some cases you want
to change the currently used flavour in your view or somewhere else. You can
do this by simply callingdjango_mobile.set_flavour(flavour[, permanent=True]). The first argument is self explaining. But keep in mind
that you only can pass in a flavour that you is also in yourFLAVOURSsetting. Otherwiseset_flavourwill raise aValueError. The optionalpermanentparameters defines if the change of the flavour is remember for
future requests of the same client.Your users can set their desired flavour them self. They just need to specify
theflavourGET parameter on a request to your site. This will permanently
choose this flavour as their preference to view the site.You can use this GET parameter to let the user select from your available
flavours:<ul>
    <li><a href="?flavour=full">Get the full experience</a>
    <li><a href="?flavour=mobile">View our mobile version</a>
    <li><a href="?flavour=ipad">View our iPad version</a>
</ul>Notes on cachingDjango is shipping with some convenience methods to easily cache your views.
One of them isdjango.views.decorators.cache.cache_page. The problem with
caching a whole page in conjunction withdjango-mobileis, that django’s
caching system is not aware of flavours. This means that if the first request
to a page is served with a mobile flavour, the second request might also
get a page rendered with the mobile flavour from the cache – even if the
second one was requested by a desktop browser.django-mobileis shipping with it’s own implementation ofcache_pageto resolve this issue. Please usedjango_mobile.cache.cache_pageinstead
of django’s owncache_pagedecorator.You can also use django’s caching middlewaresdjango.middleware.cache.UpdateCacheMiddlewareandFetchFromCacheMiddlewarelike you already do. But to make them aware of
flavours, you need to adddjango_mobile.cache.middleware.CacheFlavourMiddlewareas second last item
in theMIDDLEWARE_CLASSESsettings, right beforeFetchFromCacheMiddleware.Referencedjango_mobile.get_flavour([request,][default])Get the currently active flavour. If no flavour can be determined it will
returndefault. This can happen ifset_flavourwas not called before
in the current request-response cycle.defaultdefaults to the first
item in theFLAVOURSsetting.django_mobile.set_flavour(flavour, [request,] [permanent])Set theflavourto be used forrequest. This will raiseValueErrorifflavouris not in theFLAVOURSsetting. You can try to set the
flavour permanently forrequestby passingpermanent=True. This may
fail if you are out of a request-response cycle.requestdefaults to the
currently active request.django_mobile.context_processors.flavourContext processor that adds the current flavour asflavourto the
context.django_mobile.context_processors.is_mobileThis context processor will add ais_mobilevariable to the context
which isTrueif the current flavour equals theDEFAULT_MOBILE_FLAVOURsetting.django_mobile.middleware.SetFlavourMiddlewareTakes care of loading the stored flavour from the user’s session if set.
Also sets the current request to a thread-local variable. This is needed
to provideget_flavour()functionality without having access to the
request object.django_mobile.middleware.MobileDetectionMiddlewareDetects if a mobile browser tries to access the site and sets the flavour
toDEFAULT_MOBILE_FLAVOURsettings value in case.django_mobile.cache.cache_pageSame as django’scache_pagedecorator but appliesvary_on_flavourbefore the view is decorated withdjango.views.decorators.cache.cache_page.django_mobile.cache.vary_on_flavourA decorator created from theCacheFlavourMiddlewaremiddleware.django_mobile.cache.middleware.CacheFlavourMiddlewareAddsX-Flavourheader torequest.METAinprocess_requestand
adds this header toresponse['Vary']inprocess_response.CustomizationThere are some points available that let you customize the behaviour ofdjango-mobile. Here are some possibilities listed:MobileDetectionMiddlewareThe built-in middleware to detect if the user is using a mobile browser served
well in production but is far from perfect and also implemented in a very
simplistic way. You can safely remove this middleware from your settings and
add your own version instead. Just make sure that it callsdjango_mobile.set_flavourat some point to set the correct flavour for
you.SettingsHere is a list of settings that are used bydjango-mobileand can be
changed in your ownsettings.py:FLAVOURSA list of available flavours for your site.Default:('full', 'mobile')DEFAULT_MOBILE_FLAVOURThe flavour which is chosen if the built-inMobileDetectionMiddlewaredetects a mobile browser.Default:mobileFLAVOURS_TEMPLATE_PREFIXThis string will be prefixed to the template names when searching for
flavoured templates. This is useful if you have many flavours and want to
store them in a common subdirectory. Example:from django.template.loader import render_to_string
from django_mobile import set_flavour

set_flavour('mobile')
render_to_string('index.html') # will render 'mobile/index.html'

# now add this to settings.py
FLAVOURS_TEMPLATE_PREFIX = 'flavours/'

# and try again

set_flavour('mobile')
render_to_string('index.html') # will render 'flavours/mobile/index.html'Default:''(empty string)FLAVOURS_TEMPLATE_LOADERSdjango-mobile’s template loader can load templates prefixed with the
current flavour. Specify with this setting which loaders are used to load
flavoured templates.Default:same asTEMPLATE_LOADERSsetting but without'django_mobile.loader.Loader'.FLAVOURS_GET_PARAMETERUsers can change the flavour they want to look at with a HTTP GET parameter.
This determines the name of this parameter.  Set it toNoneto disable.Default:'flavour'FLAVOURS_SESSION_KEYThe user’s preference set with the GET parameter is stored in the user’s
session. This setting determines which session key is used to hold this
information.Default:'flavour'Changlog0.2.3STATIC_URL_MOBILE variable is added to context0.2.2FIX: Opera Mobile on Android was categorized as mobile browser. Thanks to
dgerzo for the report.Sniffing for iPad so that it doesn’t get recognized as small mobile device.
Thanks to Ryan Showalter for the patch.0.2.1Fixed packing issues that didn’t include the django_mobile.cache package.
Thanks toScott Turnbullfor the report.0.2.0Restructured project layout to remove settings.py and manage.py from
top-level directory. This resolves module-name conflicts when installing
with pip’s -e option. Thanks tobendavis78for the report.Added acache_pagedecorator that emulates django’scache_pagebut
takes flavours into account. The caching system would otherwise cache the
flavour that is currently active when a cache miss occurs. Thanks toitmustbejjfor the report.Added aCacheFlavourMiddlewarethat makes django’s caching middlewares
aware of flavours. We use interally theVaryresponse header and theX-Flavourrequest header.0.1.4Fixed issue in template loader that only implementedload_template_sourcebut noload_template. Thanks to tylanpince,
rwilcox and Frédéric Roland for the report.0.1.3Fixed issue withrunservercommand that didn’t handled all request
independed from each other. Thanks to bclermont and Frédéric Roland for the
report.0.1.2Fixed unreferenced variable error inSetFlavourMiddleware.0.1.1Fixedis_usableattribute fordjango_mobile.loader.Loader. Thanks Michela Ledwidge for the report.0.1.0Initial release.