Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Web sites for mobile devices, how's it done?

Options
  • 02-02-2010 12:15pm
    #1
    ICT2007
    Closed Accounts Posts: 2 ✭


    Hi all,
    Does any know how web sites/servers know when they get visits from mobile devices? You may have experienced when surfing from a mobile device iphone, mobiles etc some sites redirect you to a cut down site. How's it done?

    I've viewed the code for a couple of sites and nothing is obvious. Any ideas?

    Cheers :)


Comments

  • Options
    #2
    bobbytables
    Registered Users Posts: 498 ✭✭bobbytables


    Look at the User Agent HTTP Request header. You can manage it through code or use .htaccess rules on Apache to handle redirects, etc.


  • Options
    #3
    Sparks
    Registered Users Posts: 40,038 ✭✭✭✭Sparks


    Some are using DeviceAtlas from dotMobi, which looks at the User Agent HTTP Request header and a few dozen other headers in the HTTP request from the browser and determines what browser on what phone it is. But you wouldn't see it running because it runs on the server as an apache module (there's an applet version as well). Others use other approaches - there's WURFL which is a lot like an open source version of DeviceAtlas, there are very basic handrolled versions that look at just one or two headers and then chop straight out to a very basic site (whereas more complex versions let you have several different levels of webpage design for different browsers on different platforms). There's also at least one approach (and while I can remember lots of debate on it, I can't remember the name of the product!) where a bit of software on the phone itself told the webserver what the browser and platform were so that the server could serve an appropriate page. That last one had a major disadvantage in that you had to install something on the phone; and a major advantage in that transcoding didn't affect it. All the other approaches were adversely affected to one degree or another by transcoding web proxies that silently took in requests from phones on one side and then changed the headers before passing on the requests to the servers; then they'd change the responses on the way back. Sounded great in theory; in practice they weren't terribly good at it so the webpages often looked bad and the webpage authors couldn't do anything to change that.


    (Full disclosure, I helped write one of the first versions of DeviceAtlas a few years back).


Advertisement