Weblog
A Brief Glossary of Mobile Jargon
A few terms that seem to get bandied about in the industry. I'll probably add to this over time.
- Broadcasting
- Distributing an MT to a large number of MSISDNs, typically for promotional purposes, and perhaps without the explicit approval of the recipient.
- Keyword
- A string within an MO indicating user's intent. Examples include 'GO', 'STOP' and 'PITCH'.
- MCC
- Mobile Country Code. A unique ID number assigned to a country. See List of mobile country codes.
- MNC
- Mobile Network code. An ID number for an MNO. These are not unique, but may be used in combination with an MCC to uniquely identify an MNO. See Mobile Network Code.
- MNO
- Mobile Network Operator - e.g. T-Mobile.
- MO
- Mobile-originated. An SMS sent from a mobile handset.
- MQ
- IBM messaging software.
- MSISDN
- Mobile telephone number.
- MT
- Mobile-terminated. An SMS sent to a mobile handset.
- MVNO
- Mobile Virtual Network Operator. A mobile operator that does not own its own spectrum and usually does not have its own network infrastructure. Examples are Virgin Mobile in the UK and Disney Mobile in the US.
- OTA
- Over-the-air programming. A technology used to deliver software updates to a handset, often via SMS. Commonly used by MNOs to install new settings, for example WAP configuration details, but other uses exist.
- Portability/Porting
- The ability of a user to move between MNOs whilst retaining their MSISDN.
- Realtone
- A ringtone which is actually a fragment of the original recording, as opposed to a soundalike or a MIDI file.
- Shortcode
- A shorter, more convenient number to which an MO can be sent - such as 88888 (that's Jamster, by the way). Often, but not always, charged at a higher rate than a message sent to a standard MSISDN.
- SMSC
- SMS centre. A network element in the mobile telephone network which delivers SMS messages.
- WAP Opt-in
- Where a user signs up for a subscription by entering their MSISDN into a form on a WAP page. Also known as "on-portal" signup.
- WAP Push
- A specially encoded message which includes a link to a WAP address. Typically delivered by SMS.
- WURFL
- The Wireless Universal Resource File. An "XML configuration file which contains information about capabilities and features of several wireless devices". WURFL is open source and updated fairly frequently. See Wurfl on Sourceforge.
Managing Mobile and Non-mobile Versions of a Site Using Tera-WURFL and Zend Framework
This is a quick proof-of-concept I put together after a discussion on how to deal with running a mobile site and a 'full' web site on the same hostname in a sane way, and to transparently route user agents to the appropriate site.
Steps Involved
i) Organise the 'Web' and 'Mobile' sites as separate Modules in Zend Framework
This way, any users accessing URLs beginning /mobile (or whichever path we nominate) will automatically be routed to the controllers in the Mobile module and users accessing URLs beginning /web will be routed into the Web module.
ii) Add a 'Default' Module
Users will be routed to this if they access any other path, such as / or /ringtones
The configuration for this in the bootstrap looks a little like this:
<?php
$frontController->setControllerDirectory(array(
'default' => '../application/modules/default/controllers',
'web' => '../application/modules/web/controllers',
'mobile' => '../application/modules/mobile/controllers',
));
That tells the FrontController where to look for the right controllers.
iii) Query Tera-WURFL to identify the device
I chose to do this as a ControllerPlugin, as this will be run regardless of the user's entry URL.
<?php
require_once '/path/to/tera_wurfl/tera_wurfl.php';
class TwurflPlugin extends Zend_Controller_Plugin_Abstract {
/**
* Only ever called once at the start of dispatch
* @access public
*/
public function dispatchLoopStartup(
Zend_Controller_Request_Abstract $request)
{
$tw = new Tera_Wurfl();
$tw->getDeviceCapabilitiesFromAgent(
$request->getHeader('User-Agent'));
Zend_Registry::set('twurfl', $tw);
}
}
...and register that with the FrontController like so:
<?php
$frontController->registerPlugin(new TwurflPlugin());
A nice side effect is that the Tera_Wurfl object is pulled from the database once and once only, and is thereafter available via the Zend_Registry for the lifetime of the request.
iv) Use the IndexController of the Default module to route requests into the appropriate module
<?php
class IndexController extends Zend_Controller_Action {
/**
* Called automatically by ZF before a *Action()
* method is called
*
* @access public
*/
public function init()
{
$this->_helper->viewRenderer->setNoRender(TRUE);
}
/**
* Called by magic
*
* @access public
*/
public function __call($methodname, $args)
{
$tw = Zend_Registry::get('twurfl');
if ( $tw->browser_is_wap ) {
$this->_forward(
$this->_request->getActionName(),
$this->_request->getControllerName(),
'mobile');
//$this->_redirect('/mobile');
} else {
$this->_forward(
$this->_request->getActionName(),
$this->_request->getControllerName(),
'web');
}
}
}
Note the use of the PHP5 __call() magic method, which effectively gives us wildcarding of URLs, so we don't need to create an action method for every possible path.
Outcome
- Users can, should they wish, access each site from any device, by explicitly browsing to the relevant URL
- Users not specifying /mobile or /web will be detected and routed to the correct site
- This does not require any browser redirects - it's transparent to the end user
- URLs such as /ringtones or /sendtoafriend will work transparently allowing the appropriate controllers to handle them as they see fit
- For such time as the mobile site is not Zend Framework based, we can replace the forward() with a redirect() as per the line commented out in the previous example