Creating Device Group Filters
IMPORTANT- The Universal Editor for visually editing headless content.
- The Content Fragment Editor for form-based editing of headless content.
Create a device group filter to define a set of device capability requirements. Create as many filters as you require to target the needed groups of device capabilities.
Design your filters so that you can use combinations of them to define the groups of capabilities. Typically, there is overlap of the capabilities of different device groups. Therefore, you might use some filters with multiple device group definitions.
After you create a filter, you can use it in the group configuration.
The Filter Java™ Class
A device group filter is an OSGi component that implements the com.day.cq.wcm.mobile.api.device.DeviceGroupFilter interface. When deployed, the implementation class provides a filter service that is available to device group configurations.
The solution described in this article uses the Apache Felix Maven SCR Plugin to facilitate the development of the component and service. Therefore, the example Java™ class uses the @Componentand @Service annotations. The class has the following structure:
package com.adobe.example.myapp;
import java.util.Map;
import com.day.cq.wcm.mobile.api.device.DeviceGroup;
import com.day.cq.wcm.mobile.api.device.DeviceGroupFilter;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
@Component(metatype = false)
@Service
public class myDeviceGroupFilter implements DeviceGroupFilter {
public String getDescription() {
return null;
}
public String getTitle() {
return null;
}
public boolean matches(DeviceGroup arg0, String arg1, Map arg2) {
return false;
}
}
Provide code for the following methods:
getDescription: Returns the filter description. The description appears in the Device Group configuration dialog.getTitle: Returns the name of the filter. The name appears when selecting filters for the device group.matches: Determines whether the device has the required capabilities.
Providing the Filter Name and Description
The getTitle and getDescription methods return the filter name and description, respectively. The following code illustrates the simplest implementation:
public String getDescription() {
return "An example device group filter";
}
public String getTitle() {
return "myFilter";
}
Hard-coding the name and description text is sufficient for uni-lingual authoring environments. Consider externalizing the strings for multi-lingual use, or for enabling the changing of strings without recompiling the source code.
Evaluating Against Filter Criteria
The matches function returns true if the device capabilities satisfy all the filter criteria. Evaluate the information provided in method arguments to determine if the device belongs to the group. The following values are provided as arguments:
- A DeviceGroup object
- The name of the user agent
- A Map object that contains the device capabilities. The Map keys are the WURFL™ capability names and the values are the corresponding values from the WURFL™ database.
The com.day.cq.wcm.mobile.api.devicespecs.DeviceSpecsConstants interface contains a subset of the WURFL™ capability names in static fields. Use these field constants as keys when retrieving values from the Map of device capabilities.
For example, the following code example determines whether the device supports CSS:
boolean cssSupport = true;
cssSupport = NumberUtils.toInt(capabilities.get(DeviceSpecsConstants.DSPEC_XHTML_SUPPORT_LEVEL)) > 1;
The org.apache.commons.lang.math package provides the NumberUtils class.
NOTEExample Filter For Screen Size
The example DeviceGroupFilter implementation that follows determines whether the physical size of the device meets minimum requirements. This filter is meant to add granularity to the touch device group. The size of buttons in the application UI should be the same regardless of physical screen size. The size of other items, such as text, can vary. The filter enables the dynamic selection of a particular CSS that controls the size of the UI elements.
This filter applies size criteria to the physical_screen_height and physical_screen_width WURFL™ property names.
package com.adobe.example.myapp;
import java.util.Map;
import com.day.cq.wcm.mobile.api.device.DeviceGroup;
import com.day.cq.wcm.mobile.api.device.DeviceGroupFilter;
import org.apache.commons.lang.math.NumberUtils;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
@Component(metatype = false)
@Service
@SuppressWarnings("unused")
public class ScreenSizeLarge implements DeviceGroupFilter {
private int len=400;
private int wid=200;
public String getDescription() {
return "Requires the physical size of the screen to have minimum dimensions " + len + "x" + wid+".";
}
public String getTitle() {
return "Screen Size Large ("+len + "x" + wid+")";
}
public boolean matches(DeviceGroup deviceGroup, String userAgent,
Map<String, String> deviceCapabilities) {
boolean longEnough=true;
boolean wideEnough=false;
int dimension1=NumberUtils.toInt(deviceCapabilities.get("physical_screen_height"));
int dimension2=NumberUtils.toInt(deviceCapabilities.get("physical_screen_width"));
if(dimension1>dimension2){
longEnough=dimension1>=len;
wideEnough=dimension2>=wid;
}else{
longEnough=dimension2>=len;
wideEnough=dimension1>=wid;
}
return longEnough && wideEnough;
}
}
The String value that the getTitle method returns appears in the drop-down list of the device group properties.
The String values that the getTitle and getDescription methods return are included at the bottom of the device group summary page.
