Jump to content

Module: Mobile Detect

justb3a

By justb3a,
in Modules/Plugins

 Share

Recommended Posts

justb3a Sr. Member

justb3a

Posted
Posted

Overview

Mobile Detect uses a lightweight PHP class Mobile_Detect for detecting mobile devices (including tablets).

Installation

1a. Clone the module and place MobileDetect in your site/modules/ directory. [OR]
1b. Download it.

git clone https://github.com/justonestep/processwire-mobiledetect.git your/path/site/modules/MobileDetect

2. Login to ProcessWire admin and click Modules.
3. Click "Check for new modules".
4. Click "install" next to the new SimpleContactForm module.

Usage

This Module extends $config and sets the following parameters:

$config->mobileDetect = array(  
  'deviceType' => 'deviceType (phone, tablet or desktop)',  
  'browser' => 'mobile browser',  
  'operatingsystem' => 'mobile operatingsystem',  
  'device' => 'mobile device'
);

You can access them where ever you want.
See the example below:
 

<body class="devicetype--<?php echo $config->mobileDetect->deviceType?>">  <body class="devicetype--{{config.mobileDetect.deviceType}}"> // twig

Results in:
 

<body class="devicetype--phone"> OR<body class="devicetype--tablet"> OR<body class="devicetype--desktop">
  • Like 19
Link to comment
Share on other sites
mr-fan Hero Member

mr-fan

Posted
Posted

could this used for chang the whole output, too not only just the CSS class - or is this operation not recommended?

like this one in a template file:

$devicecheck = $config->mobileDetect->deviceType;

if ($devicecheck = "desktop") {
  //output desktop
} else {
  //output mobile
}

//if needed a additional check for a get param to switch if users change manually?

regards mr-fan

(have some experience with a other script that detects via PHP -> https://code.google.com/p/mobileesp/source/browse/#svn%2FPHP)

Link to comment
Share on other sites
justb3a Sr. Member

justb3a

Posted
  • Author
Posted

you can use this module to change the whole output. 

If this operation is recommended - there are different opinions on that. I guess it depends on your own needs.

Ask two peoples and you get three answers. I use it to change the output (html structure) for a special slider, apart from this just for css assignments (responsive design, the content remains the same).

  • Like 2
Link to comment
Share on other sites
mr-fan Hero Member

mr-fan

Posted
Posted

Yes thats a valide point.

As far as i can see - the use for such a switch is for two usecases.

Change some HTML/CSS things to make responsive "work better" and may get better usability with less documentsize to download (slider, images...) OR change the whole output to serve different things.

On real big sites there is very often a special mobile content for such devices (like a storefinder or something else) but this is like justb3a wrote a kinda of religious question with no right or wrong answer.......

so thanks for your module!! ;)

Link to comment
Share on other sites
Martijn Geerts Hero Member

Martijn Geerts

Posted
Posted

Problem with different output (generated by PHP ) is that the default ProcessWire cache solutions (template cache & ProCache ) can't cache 2 versions for the same URL. When you want to support caching you need to create a workaround for this. (Could be done with AJAX and enabling urlsegments) Or you go for the other cache solutions ProcessWire has. For example MarkupCache. Keep in mind generating different output with PHP can be done easily without the need of caching, what is perfectly fine for smaller websites. If you need to build for a high traffic site then you need to make a good cache strategy.

When you want to deliver different output purely in the browser, Javascript can easily detect the state and respond to this. Then there's no need for different source code. For example: Javascript could destroy a slider when moving from iPad to iphone, and rebuild the slider when moving back.

  • Like 2
Link to comment
Share on other sites
justb3a Sr. Member

justb3a

Posted
  • Author
Posted

You can destroy a slider with Javascript for a mobile version. But - you have to load all images (at least the first one) for the slider. And this is not that good in view of performance. (In my case, I do not remove the slider, I just need a modified html structure to use a special slider for mobile devices).

Caching is another point to keep in mind, thanks for pointing that out.

Link to comment
Share on other sites
Martijn Geerts Hero Member

Martijn Geerts

Posted
Posted

Javascript performance is very good when you keep one thing in mind. Don't trigger repaints when you can avoids those. I can imagine all the needed data you send to the browser is in JSON. Then build the whole needed HTML structure with Javascript before attaching it to the DOM. After inserting the HTML structure fire the plug-in.

When you change the viewport size (with orientation change for example) You now can Destroy what you've build with Javascript, and use the original JSON data to build the other structure. The JSON data can easily hold the data for multiple sizes of images or what ever you wish. 

  • Like 2
Link to comment
Share on other sites
horst Hero Member

horst

Posted
Posted

You should know I'm not very familiar with CSS / JS. I run into an issue when I have developed a responsive site that should show different designs for phones, tablets and desktops. Also the site uses infinite scrolling, loading image thumbs. The number of loaded images at once and the dimensions of the requested images needs to be very different regarding to the device type a visitor uses. (for phones it should load 2 thumbs at once, for tablets 12 and for desktops 36)
 
I have used a serverside UA-Sniffer (PHP) and have set a class in the body tag to represent the found devicetype "<body class='tablet' ..", This way all the CSS for the different device types could be derived from there.
 
After the site was nearly finished, one of the last things to implement was ProCache. This was planned from the beginning, but I haven't used it before. After installing and configuring ProCache, the first device-type entering an URL was written into the cached page-version. Uhh! :huh:
 
It is very important to build the caching strategy at an early point. :) (Now I know this too)
 
I came around my issue with the caching with changing from the serverside UA-Sniffer to a JS-UA-Sniffer and adding a JS snippet right after the body tag that adds the relevant device-type-class to the body.

var md = new MobileDetect(window.navigator.userAgent);
if(md.phone()) {
	document.body.className += (' phone');
}
if(md.tablet()) {
	document.body.className += (' tablet');
}

The code is called directly after the opening body-tag. Also the small JS-lib does not depend on jQuery, it is the only one that needs to be called in the head. All other JS files can be called after the body content.
 

I used this PHP UA-Sniffer: https://github.com/serbanghita/Mobile-Detect
and this JS-Port of the above: http://hgoebl.github.io/mobile-detect.js/

  • Like 2
Link to comment
Share on other sites
gurkendoktor Full Member

gurkendoktor

Posted
Posted

To add some background: the thought behind this is called Responsive Web Design + Server Side Components (http://www.ress.io)

The big advantage over "just responsive" is that you don't only have a responsive site, but instead cater to the various environments. For example, you could assume that users with mobile devices almost always operate on a smaller bandwidth with a bigger latency. You might want to deliver only the JavaScript that's needed for the mobile version, not necessarily all the bytes for the full fledged desktop version. Or, to turn it around, auto-load videos on the not-mobile versions, and just have images on the mobile version… you name it. Horst in #12 also has a good use case. This is especially necessary, when you have the – nowadays somewhat old-fashioned – opinion, that web sites should also work without JavaScript. At least the basic functionality.

It is a bigger effort though and has some pitfalls, one of which is caching. We don't have issues with that, but you could easily run into trouble. As mentioned before, TemplateCache can only cache whole sites. You could use MarkupCache instead, which is more work again, but should give you the control you need. With ProCache i haven't been working yet, but I assume from what I've read that it's a TemplateCache on steroids. 

We are currently working on a caching solution somewhat similar to ProCache, which also respects the user's environment and the version they get delivered – for which this module comes in handy again ;) This is yet one of the harder issues.

  • Like 3
Link to comment
Share on other sites
arjen Hero Member

arjen

Posted
Posted

I ran into this too. What happens is that the "lib" directory is empty when you install the module through ProcessWire. I guess this has something to do with the lib directory being a submodule in git. You can easily fix this by manually download your module or the class used in your module.

Link to comment
Share on other sites
justb3a Sr. Member

justb3a

Posted
  • Author
Posted

I've already thought about that. The php library is included as a git submodule. So I can easily update.

Just run 

git submodule init
git submodule update
and everything should work :)

I will include it in the module description / readme.

Link to comment
Share on other sites
Mackski Sr. Member

Mackski

Posted
Posted

Nice little wrapper library for adaptive design requirements, although I did change references from array to object, so it's more inline with PW config conventions.

eg;

public function mobileDetection(HookEvent $event) {
    $this->detect = new Mobile_Detect;
    $config = $this->wire('config');

    $mobileDetect = (object) array(
      'deviceType' => $this->getDeviceType()
    );

    foreach($this->detect->getRules() as $name => $regex) {
      if ($this->detect->{'is'.$name}() === true) {

        if (in_array($regex, $this->detect->getBrowsers())) {
          $mobileDetect->browser = strtolower($name);
        } elseif (in_array($regex, $this->detect->getOperatingSystems())) {
          $mobileDetect->operatingsystem = strtolower($name);
        } elseif (in_array($regex, $this->detect->getPhoneDevices()) || in_array($regex, $this->detect->getTabletDevices())) {
          $mobileDetect->device = strtolower($name);
        }

      }
    }

    $config->mobileDetect = $mobileDetect;
  }

So calling is simply: $config->mobileDetect->deviceType etc.

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
  • 3 months later...
justb3a Sr. Member

justb3a

Posted
  • Author
Posted

I didn't noticed the following topic: Fallen at the first hurdle...

cstevensjr commented

Reference:

https://processwire.com/talk/topic/9352-fallen-at-the-first-hurdle/page-2#entry90179

Normally, ProcessWire modules are installed in one of three ways:

(1) Create a directory in the /site/modules directory with the name of your module (using CamelCase format). Then copy the files in the directory. Go to the Modules Tab and click Refresh.
(2) Use the third-party ModulesManager by Soma to install the module.
(3) Go to Modules Tab on the Admin Menu, go to Install and click +Add New. Then you have a choice of Add Module From Directory, Add Module From URL or ADD Module From Upload.

This module cannot be installed these ways, due to the fact that there is a mandatory requirement to run the git init and update commands on a submodule.

How any module operates or installs is totally up to the module author. I only ask that you make it very clear and explicit that knowledge of git, to include how to run git commands is a prerequisite for the use of this module. I believe this will not be readily apparent to anyone who is not familiar or knowledgeable about Git.

I do commend you because you have already made changes to explain about the error that someone will receive if those git commands are not run.

Finally, It would be even better if this module installed using the normal methods.

I can definitely unterstand your point. Now you should be able to install the module the normal way. I removed the submodule and included the mobiledetect library via composer. Therefore the including path for the library changed but this doesn't matter for you. There is a new release version 0.0.4. 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...