Archive

Archive for March, 2010

GPS tracking fleet project (part. 1)

March 21st, 2010 Ivan Villareal No comments

About a year ago I was talking to a friend that was working for a company that offered a fleet tracking service, he described the process and I just got curious about how could I implement the entire system easily, I did some research and there wasn’t a lot of information about the entire picture, there were bits here and there but nothing concrete.

After a couple of days of researching I came up with a Plan to write a platform in one month in my spare time, the intention was to create a fully functional backend and front end pieces, with the ability to track any number of units.

It was a bit challenging because :

  1. The short time span I wanted to have this ready.
  2. I didn’t have any hardware to test  (GPS receivers, GPRS modems, or even a dedicated server to put the backend), and I didn’t want to spent any money buying any of this.
  3. I didn’t had a lot of experience with Google maps API.

The first thing I did was a diagram of how the system should work:

gps-platform-diagram

I’m not good with drawings so bear with me, let me explain the diagram:

There will be a tracking device in every truck that will be sending periodic updates about its  location, speed, and other events trough a GPRS link, provided by a conventional GSM network, the device must be programmed to send this updates to a certain ip address (Application server), at specified periods of time.

The application server (background process) will have a daemon running on a specific port waiting for requests from tracking devices, if the tracking device is authorized it will accept the stream and save the info received from the device to a db.

The requirements for the backend application were:

  • It should be able to run on Linux.
  • The process should be able to handle a large number of requests.
  • It needed to be run as a daemon, interfacing with a system to logger.
  • It must be able to decode NMEA sentences and save them in a MySQL Db.

The front end application, requirements were:

  • Handle user authentication.
  • Present the gathered data in real time.
  • Generate reports.

Technology selection:

With basic requirements on hand, the next thing was to look the technologies I should be using and this were my choices:

For the backend:

  • Gentoo Linux
  • Java 1.6
  • Mysql 5.0

For the frontend:

  • Gentoo Linux
  • PHP 5.2
  • Jquery 1.3
  • Mysql 5.0

In my next post I will describe the approach I took on the back end process and how I started building it.

Categories: Articles, Development Tags:

PHP cross domain ajax Proxy

March 19th, 2010 Ivan Villareal 1 comment

I received a javascript application, that made cross domain calls to a webservice using the flensed library, this was pretty neat, but filling the dropdown boxes was very slow. Not to mention unnecessary, because I was going to embed the dropdown values into this modal window.

What I did was to refactor the javascript app, into php code to fill the values, and left the important webservice requests alone, I didn’t want to use the flXHR library, because the widget was so simple, so what I did was a php json-rpc proxy client, winch its work would be to post the data received from the client to a remote webservice.

I’m using Zend_Json to encode/decode json, because the php version on production is 5.1, and the php json extensions are not available.

First I create an object that will hold the data to be sent.

01
$re = new stdClass();
02
$re->brand_id  = $_POST['brand_id'];
03
$names         = $_POST['domains'];
04
 
05
$domains = explode(",", $names);
06
$filteredDomains = array();
07
foreach ($domains as $domain) {
08
 $domainParts = parse_url($domain);
09
 if (isset($domainParts['host']) && $domainParts['host'] != '') {
10
 $filteredDomains[] = $domainParts['host'];
11
 }
12
}
13
$re->domains   = $filteredDomains;

That was simple, I didn’t have to worry about filtering the user input, because the webservice will take care of that, the only thing I do, is  create an array of domains, with has only the host part.

after I have my Object ready I encode it as a json string, open a socket and make the request, here is how I did it:

01
$request = Zend_Json::encode($re);
02
$opts = array ('http' => array (
03
    'method'  => 'POST',
04
    'header'  => 'Content-type: application/json',
05
    'content' => $request
06
    ));
07
$context  = stream_context_create($opts);
08
$conection = $fp = fopen($url, 'r', false, $context);
09
if ($conection) {
10
 $reply = '';
11
 while($row = fgets($fp)) {
12
 $reply.= trim($row)."\n";
13
}
14
$reply = Zend_Json::decode($reply);

Pretty simple no?