The mobile site relies exclusively on programming in templates, CSS and javascript to provide a different experience for mobile users.

The user is not automatically redirected to a mobile site, so much as automatically presented the option to be redirected. This is done in the event that JavaScript detects a mobile user agent, and the user for some reason would prefer to rmain on the non-mobile site (in the case of iPads and similar tablet devices, which may have mobile useragents but have enough screen real-estate).

Relevant files
conf/        - set_mobile, leave_mobile

media/js/mobile.js   - mobile-specific javascript

media/css/main.css   - mobile banner rules
media/css/mobile.css - mobile specific CSS

templates/smaoahpa_main.html - mobile detect javascript function and banner html



Templates use separate if statements to control specific content that is displayedi n the mobile site. This is done with testing whether request.session.is_mobile is set:

{% if request.session.is_mobile %}
    {{ ... mobile content ... }}
{% else %}
    {{ ... nonmobile content ... }}
{% endif %}

Mobile variable setting

Setting the mobile variable is carried out in the following manner:

  1. Javascript detects whether the user agent contains iphone, android, or mobile
  2. Javascript displays a banner at the top of the front page
  3. The user clicks the link (which directs them to /aarjel/mobile/) and then sends them back to the newly created front-page
  4. The session variable is set in conf.views.set_mobile (and alternatively conf.views.leave_mobile) if the user decides to leave

Additional features

  • Game settings are hidden unless the user chooses to display them (more room for game form)
  • Form fields, when entered, display shortcuts to enter special keys (ï, etc.). Most mobile phones have Norwegian and Swedish layouts that allow easily typing æ, ø, ä, etc., but ï is not present on these layouts. Strangely enough, the default English layout in both iOS and Android is more fully functional in this regard.

Misc notes

Testing the mobile version through Django's built in http server seems to give separate results, and often you need to restart the http server in order to actually see it (after clicking the link, of course). This doesn't happen in Apache, which is why it works, but it could be that switching away from mod_python to mod_wsgi will result in similar difficulties.

Also, Android devices have an SSH client that allows for port forwarding, thus it is possible to test changes without deploying them. The way I managed to do this if unable to connect directly to my test machine on the local network was establishing a reverse tunnel (e.g. ssh user@host -R 8888:localhost:8888) from my machine to an external server, and then tunneling from the android device (ssh user@host -L 8888:localhost:8888). Then navigating to http://localhost:8888/ on the android device worked.

Testing for iOS is much easier if you have XCode 4.2 installed on mac, as an iPhone and iPad emulator may be found in:


Additional testing complications on mobile devices can be that one must constantly clear the browser cache, as the devices assume they should load from cache first.