Snippet List
For those interested in making a mobile site geared toward the higher end devices, and wanting a little leverage over device-specific quirks.
These are the big players in the U.S. market, but of course, add your own User-Agents to match your audience's popular browsers.
Usage:
<html class="{{ device.classes }}">
You can also leverage template logic:
{% if device.iphone %}
<p>You are browsing on
{% if device.iphone = "iphone4" %} iPhone 4
{% else %} an iPhone pre-version 4{% endif %}
</p>
{% endif %}
- mobile
- context_processors
Middleware class that checks the user agent against a known list of strings found in mobile devices, and if matched it then tries to determine the name of the template being rendered based on the convention of having every view use a keyword arg called "template". It then adds "mobile" to the template name and if the mobile template exists, it will override the "template" arg for the view with the mobile template name.
- middleware
- template
- mobile
This middleware adds a "is_mobile" (boolean) to the request object if the user's browser is a mobile browser (iPhone, Nokia, etc).
**Example of use inside a view:** `request.is_mobile`
**Example of use inside a template:** *You must activate the template processor "django.core.context_processors.request" in your settings. (see TEMPLATE_CONTEXT_PROCESSORS at djangoproject.com)* `{{ request.is_mobile }}`
- middleware
- detect
- browser
- detection
- mobile
Inserts the output of a view, using fully qualified view name (and then some
args), a or local Django URL.
{% view view_or_url arg[ arg2] k=v [k2=v2...] %}
This might be helpful if you are trying to do 'on-server' AJAX of page
panels. Most browsers can call back to the server to get panels of content
asynchonously, whilst others (such as mobiles that don't support AJAX very
well) can have a template that embeds the output of the URL synchronously
into the main page. Yay! Go the mobile web!
Follow standard templatetag instructions for installing.
**IMPORTANT**: the calling template must receive a context variable called
'request' containing the original HttpRequest. This means you should be OK
with permissions and other session state.
**ALSO NOTE**: that middleware is not invoked on this 'inner' view.
Example usage...
Using a view name (or something that evaluates to a view name):
{% view "mymodule.views.inner" "value" %}
{% view "mymodule.views.inner" keyword="value" %}
{% view "mymodule.views.inner" arg_expr %}
{% view "mymodule.views.inner" keyword=arg_expr %}
{% view view_expr "value" %}
{% view view_expr keyword="value" %}
{% view view_expr arg_expr %}
{% view view_expr keyword=arg_expr %}
Using a URL (or something that evaluates to a URL):
{% view "/inner" %}
{% view url_expr %}
(Note that every argument will be evaluated against context except for the
names of any keyword arguments. If you're warped enough to need evaluated
keyword names, then you're probably smart enough to add this yourself!)
- template
- ajax
- tag
- templatetag
- view
- httprequest
- mobile
- include
**Mobilize your Django site**
This is the code for a Django middleware class to allow you to easily mobilize your Django site. It makes use of [Wapple.net](http://wapple.net)'s Web services to provide device profiling and markup generation.
Using this middleware plugin, you can deliver your site to both mobile and web browsers using the same domain and exactly the same url structure and Python views. The WAPL markup language allows you to render sites to every single mobile device without worrying about the individual devices yourself.
**Requirements**
1. The [SUDS](https://fedorahosted.org/suds/) Python SOAP client.
2. A WAPL dev key. Sign up for one at [http://wapl.info](http://wapl.info)
3. The Django sessions framework must be enabled. See [http://docs.djangoproject.com/en/dev/topics/http/sessions/](http://docs.djangoproject.com/en/dev/topics/http/sessions/) for how to install.
**How To Use**
1. Save the code above as 'wapl_middleware.py' in the root of your project.
2. Replace 'YOUR-DEV-KEY-HERE' with your WAPL dev key.
3. In your project's 'settings'py', add the following to the bottom of your 'MIDDLEWARE_CLASSES' setting:
`'myapp.wapl_middleware.WAPLMiddleware',`
4. For each line in your 'TEMPLATE_DIRS' setting, create a new folder under that folder called 'wapl' e.g. for 'myapp/templates/', you would create the folder under 'myapp/templates/wapl/'.
5. For each template used in your application, write a WAPL version and save it in the corresponding 'wapl' directory. See [http://wapl.info/docs/chapter/Developing-with-WAPL/](the WAPL docs) for information about the WAPL markup language.
6. Django template inheritance and includes can be used as normal, so I recommend creating a 'base.html' like this one.
`<?xml version="1.0" encoding="UTF-8" ?>
<wapl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://wapl.wapple.net/wapl.xsd">
<head>
{% block wapl_head %}{% endblock %}
</head>
<layout>
{% block wapl_layout %}{% endblock %}
</layout>
</wapl>`
7. View your site from a mobile device, and you should see a nice mobile version.
**How It Works**
1. When a request is made, the middleware checks to see if a session variable is held telling us if the device is mobile or not.
2. If we don't already know, it calls the WAPL web services to check. It then stores this in the session for subsequent requests.
3. If the device is a mobile device, it appends 'wapl' to each line in your 'TEMPLATE_DIRS' setting. Your view code will work exactly the same as normal, and the 'wapl' templates will be used whenever a response is rendered.
4. When a response is about to be rendered, the middleware checks to see if the device is a mobile one.
5. If it is mobile, and the response about to be sent has a status code of 200 (OK), it sends the WAPL markup to the WAPL web service to generate the correct markup for that device.
6. Otherwise, it outputs the response unmodified.
**Tips**
1. Don't try to migrate your whole site to mobile - design for mobile and consider the user's goals on a handset.
2. If leaving sections out, don't just leave the wapl view out. Include one that says 'This page is not available on mobile'. This will make sure none of your external links are dead on the mobile version.
3. For full developer reference, information and schemas, see [http://wapl.info](WAPL.info).
- mobile
- web-services
- mobilize
**Update**:
[Django AdMob](http://github.com/johnboxall/django_admob/tree/master) pluggable app on github.
Given a Django ``request`` object and dict of admob parameters returns a Admob ad.
If no ad can be retrieved displays a one pixel Admob tracker image.
For the future:
* Make a template tag for this?
* Filter out other unneeded META parameters for the admob_post dict?
6 snippets posted so far.