Archive for the ‘development’ Category

« Older Entries

Extending the “twitterinfo” service

Friday, May 8th, 2009

The Original Question

I have a friend in Real Life (who is also on Twitter as @practicalkatie) who tweeted me a perfectly reasonable question the other day:

hey – where do you find out the date you joined twitter? everyone is twittering about their anniversary dates, but I can’t even find mine!

and I realized I really wasn’t sure myself. So I went pawing around at the Twitter API Documentation site, and I came up with the RESTful method users/show, which uses a GET with a userID or screen name as data payload and returns extended information in JSON or XML form. So of course I tried it out in curl:

curl http://twitter.com/users/show/practicalkatie.xml

and lo and behold, there was an element returned called "created_at" to read. So I sent her the curl command-line. Then I thought about it some more, and I realized that was kind of a dumb thing for me to have sent her: how do I know she has curl installed? So I made up a little piece of code to provide that user-lookup service: twitterinfo twitterinfo Webapp screen snapshot

Let Nothing Serve But One Purpose

As long as I was writing a Web-based user interface to a user info lookup sevice anyway, I figured I might as well use the opportunity to distribute the work (no API key or such to hide in the middleware) and let the client talk directly to Twitter. And hey, why not make it so it can "already be there" on a handheld device when it is needed? Why not move towards making it a WebApp? Let them load it once from the RIT server, and thereafter get it locally.

This, of course, is a security problem. Unless you are willing to be a little twisted in your code.

The Same-Origin Policy

Like the Applet security model, the JavaScript security model says it is only allowed to open sockets and make requests (and thus send data) back to where it originated. And this stuff was not going to be originating on the Twitter server, it was going to be originating at RIT.

And so I had an excuse to play with another idea: JSONP

jQuery Makes It Easy

JSONP works by injecting a callback function into the JavaScript acting on the DOM, after the page thinks it is done loading and coming from the remote server. Weird, huh? I really didn’t want to write that code right now, I just wanted to use that capability and refine it later by writing it myself. jQuery has some already-defined functionality to do just this, and I am basically lazy. So I used jQuery’s $.getJSON function. jQuery makes it easy to do this stuff; you simply pass the fully-made-up URI for the GET and a function prototype.

  $.getJSON( fullUri,
    function( data ) {
      processJsonResults( data );
  });

The fullUri parameter contains the request we saw in curl, with a minor twist to deal with naming the callback, and the data variable in the anonymous function used for the callback ends up containing the response. The only real problem is that there is squat for error-handling. Anything other than a successful request-response cycle is unthinkable to this little bugger… There are always trade-offs for initial laziness, and this is one of them: I’ll accept this first version being stoopid about users typing in non-existent user-names to look up, for the sake of not having to write this particular code myself.

The Data Display

I figured a simple list would do, there wasn’t much in the way of depth to the "extended" user data returned and simple displays are easy for user to understand quickly. I also figured the avatar-picture should actually show in the list, and that "Web Home" field should be clickable.

Mobile? Did I Hear Someone Say Mobile?

I figure it should be made to work on mobile devices as well, I mean I do run this little Center for the Handheld Web and it would be a bit embarrassing to not make it work okay on "reasonably smart" mobile devices . And by "reasonably smart", I mean handhelds with browsers supporting the basic Holy Trinity of XHTML, CSS, and JavaScript. So I made sure it worked small, I added a bit of meta-tag magic like this:

<meta name='viewport' content='width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;' />

and I added a little iPhone-specific JavaScript magic to make the address-bar roll up out of sight like this:


  document.getElementById("toolbar").style.visibility = "visible";
  window.scrollTo( 0, 1 ); // pan to the bottom, hides the location bar

and it was ready to go.

The structural markup was simple and should work on a small screen using gestures, the browser had been told not to mess with the fonts and such and to hide the address-bar, the sneaky JavaScript request/response code-injection was working, & the response-data node injection stuff was dealt with.

So What Next?

Simple things that do one thing nicely make me happy, but I can sometimes make things just a teenie bit "too simple". So I asked folks on Twitter what they would like to see as extended features for my little app. I figured there was no harm in asking, and the only responses I got involved seeing who someone was following and seeing who was following them. Followers and following, that is what folks wanted. And so that got me to thinking too, how about letting them "follow a trail"?

Wandering Through the Webs

Any list of followers or following users appears flat, but each entry in it is actually a node in a set of "interpenetrating webs of social affiliation" (as I have put it in other writing). Each person who follows me has in turn people who follow them and people who they follow. To each of us, we are at the root of a couple of webs. Looking at the larger picture, we are each embedded in interpenetrating webs (plural). If I get a list of the users following so-and-so, each of those entries should in turn be clickable so I can follow a path wanderting through the webs embodied in Twitter's persistence store.

Back to the API Docs

Of course, this meant I had to go back and look at the API documentation at Twitter. Was there any way for my WebApp to ask for user info on all the friends of someone with one call to the Twitter API? I wanted to be nice… sure enough, the REST API comes to the rescue with the method statuses/friends. So I tried that out in curl with

curl http://twitter.com/statuses/friends/jeffsonstein.xml

And it seems to work just fine. Perhaps I can add that functionality to the client and still not bang on the Twitter machines with too many API calls.

So That is Where We Are, Now

I have another week of classes, then exams to give and grade (ugh). Then I get to play with this some more. What do you think of it so far? Do you think I am going in the right direction with the follow-the-webs extension I am planning? Will it still be simple enough and work okay on a handheld device? Comments are very welcome.

Posted in Design, Logical Design, Mobile Devices, Web Apps, development, social networking, webs | No Comments »

REST Service Implementation using HTTP – Cross Domain Request

Sunday, March 29th, 2009

By Phavanhna Douangboupha, 03/29/09

The three main basic ideas of a REST process are to process a client request, to response to the request, and return a result/data in XML format according to the request.

Two techniques that can be used are getting parameters from client through a URL query string and the use of HTTP methods. The first technique is easier to implement compared to the second technique. The main disadvantages of the first technique include the size of the URL string, the maximum length of the URL string consisting of query parameters, and a possible negative side effect. The first limitation, the size of URL string, can be overcome by using POST method instead of GET method for a client request. However, POST and GET methods should be applied according to a specific task (see the blog on Creating REST Web Service for more detail). Consequently, the HTTP methods are a better solution for REST service.

I have already talked about how to implement a REST client using a URL query string from my previous post, now I will talk about how I implement a REST service for the cross server client request using HTTP methods.

For this exercise, a database server, a web host server and a web client server are assigned in different machines and hosted by different domains. The database server is hosted at STREAMER. The web host server is hosted by CHW domain and finally the demonstrated web client request comes from GIBSON domain (Figure 1 shows system architect for the REST cross domain service). STREAMER is a house to MySQL database which is hosted in a different domain from the web server.

System architect for REST cross domain service
System architect for REST cross domain service

Figure 1: System architect for REST cross domain service

GIBSON is used as a demonstration client to request data from another domain (CHW). The four main files implemented here are a normal HTML file (index.html), a JavaScript file (client_local.js), and two php using cURL libraries files (getclient_chw.php and postclient_chw.php). The Javascript file is used to implement Ajax to send a request and to receive responded data sent back by a server asynchronously. The data is displayed on the HTML file. The JavaScript file uses HTTP request object to send a request to either getclient_chw.php (”How Many Users?” in the database) or postclient_chw.php (”Add New User” to the database). getclient_chw.php and postclient_chw.php use cURL libraries to set up a HTTP request where getclient_chw.php uses the GET method to request to get data from a server and postclient_chw.php uses the POST method to request to post data to a server (please see table 1 for the correspondent HTTP methods to the database query). Both of the files make a request to process data with the web server on CHW. The client side has no relation to the database server on STREAMER and it only sends a HTTP request which will later be checked by the web server.

Use Gibson to act as a client to make REST request​ (Figure 2) - http://people.rit.edu/~pxd8840/restclient/index.html . As you click one of the two buttons – “How Many Users?” (HTTP GET) and “Add New User” (HTTP POST), you will see that the displayed results are updated asynchronously. These are done via Ajax using REST service to perform a cross-domain request instead of the <script> tag hack solution as mentioned from my previous post.

index.html, client requests on GIBSON

index.html, client requests on GIBSON

Figure 2: index.html, client requests on GIBSON

On the web host server (CHW), there are two main files – rest_database.php and ConnectDB.php. ConnectDB.php is an Object Oriented PHP class that contains methods to connect to the database and the required methods to process or retrieve data from STREAMER database server. The rest_database.php file also contains all the logic check method that received from a client. The rest_database.php file is used to check what kind of request being made if it is a HTTP GET request or a HTTP POST request. According to the request, it retrieves data from the database. Then it creates XML responses to the client.

Table 1: HTTP method, REST action, and SQL command for a client request

HTTP Request Method REST Action SQL database command Description
GET GET SELECT Search/Request for
data (getdata)
POST POST INSERT Add/Insert new data
(postdata)

List of files

Client Side

  • index.html
  • client_local.js
  • postclient_chw.php
  • getclient_chw.php

Server Side

  • rest_database_php
  • ConnectDB.php class code on the server side contains database connection and database process methods

References:

Links to other blogs in this project

Tags: , , , , , ,
Posted in Best Practices, Design, Mobile Devices, Physical Design, Web Apps, development | No Comments »

REST Client simple Implementation and Test

Sunday, March 8th, 2009

by Phavanhna Douangboupha

There are many ways to implement a REST web service client request which includes PHP, JavaScript XMLHttpRequest, C# system web HTTP web request, Java HttpClient, the command line:curl, Python, and Ruby. I am going to talk about PHP and JavaScript XMLHttpRequest techniques in this blog.

The purpose of using REST web service in this example is to enable cross domain database access and to take advantage of REST as mentioned in my previous blog about REST. Wikipedia has a good explaination about the technology.

There are three main portions in my small test system. First, it is a database server (data tier). The data tier is the MySQL database created on a server. Second, it is a logic tier that contains logical decision and evaluation functions between a client and the database server. At this logic tier, there are two separate files – a client side file and a server side file. The client side consists of an implementation method for a request made to the server. On the other hand, the server side contains implementation of logical decisions and evaluations. It handles all logic checks, retrieving data from the database and sending back response to a client (Figure 1 shows the flowchart for the server side logic tier). In this case, “getdata” type represents the retrieval request and the “putdata” represents the insert data operation request from a client.

The client side requests are created for both on the same domain with the server and a client request from a cross domain.

Finally, it is a very simple presentation layer to display results of the request.

Logic flow for the server side logic tier (rest_database.php)
Logic flow for the server side logic tier (rest_database.php)

Figure 1: Flowchart for the server side logic tier

A request response in this test is in the form of XML format. Two main responses are the error notification response and the data or status response. While, the error XML response is used to indicate that there is something wrong with the request or the request is not allowed. The data or status response either contains requested data to send back or status message of the request operation performed by the server.

JavaScript:XMLHttpRequest

In this test XMLHttpRequest is used to make a request for data from the database and to insert new data to the database from a client. The client is located on the same domain with the server. First a method is set up to initiate either retrieval data request or insert data request. The rest is simply a standard XMLHttpRequest with the requested parameter passing.

client_js

Figure 2: same domain JavaScript XMLHttpRequest technique

JavaScript XMLHttpRequest is widely used and it has many advantages. One includes the idea of Ajax. However, this method only works if the client and the server are both located on the same domain. How about if a client request is made from a cross domain, then this technique will not work. A well known solution to this problem is to use a cross-domain request called <script> tag hack. In brief, the way this technique works is that the data is encoded as JavaScript objects in the file instead of being located inside a function. The file is seen as a JavaScript file from a domain instead of a data request. This way, the objects will be parsed and immediately executed. I am not going to implement the method in this test; since, there is another easier and cleaner way to do it; that is the use of PHP cURL extension.

PHP cURL extension

One of the PHP methods to make a REST request is using cURL extension. I use this technique to make a data request for cross domain web service for my database; Prof. Jeffrey Sonstein has a more complete picture of RESTful API example and I use his example as a reference for my solution.

It is pretty simple to implement cURL for a cross domain request. To implement this technique, it requires cURL extension library which can be downloaded from http://curl.haxx.se/. In addition, PHP server side is required to have cURL enable configuration. Following are the steps for implementing the PHP cURL cross domain client request. First of all, http_build_query() is used to create a query string from an array which is part of the request URI. To implement a client request using cURL, we first start by creating and initializing a cURL request by curl_init() method. Then, curl_setopt() is used to set the request. The curl_exec() method is called to make the request to a server and it returns the response from the server. Finally, curl_close() is used to close the connection of the transaction after it completes the transaction.

For this test system, to request data or to insert a new data to a database on a server located in another domain, difference query command is used – “getdata” or “putdata”. The command is checked by the server side logic tier to differentiate if the request is to retrieve data or to insert data. The logic tier handles all the operations and sends back a message after it completes executing the request.

REST client

Figure 3: A cross domain request PHP technique

Links to other blogs in this project

Tags: , , ,
Posted in Design, development | No Comments »

Location Tracking Techniques

Saturday, January 31st, 2009

by Phavanhna Douangboupha

This blog contains information about some of the current practices in location tracking technologies. It mainly discusses the three common methodologies – GPS, Cell Towers, and Wi-Fi positioning service. The blog is a part of the ongoing investigation for the proposed capstone project on Web-based resource tracking during a disaster or crisis situation.

In general, there are four geo-location methods including triangulate, associate, geo term extraction, and data entry or geo-coding. The Global Positioning System (GPS), Cell Towers, and Wi-Fi positioning service (WPS) are the three well known triangulation techniques to identify a mobile device geo-location. GPS and Cell Towers are based on triangulation to identify an object position by using the location of known objects.

To put a location on a map, the geo-coding position technology relies on getting a location of an object via a meaningful X, Y coordinate or a latitude and longitude coordinate. In fact any available mapping tool such as Microsoft live search maps, Google maps, and Yahoo maps use the coordinate system to identify a requested location.

GPS relies on satellites that send microwave signals information back to the earth. The information is a navigation message of each satellite’s position and time. An object location is calculated by GPS receivers by the use of triangulation and the signal information provided by at least three satellites in order to determine an object’s location and four satellites for greater accuracy. The use of fourth satellite enhances the accuracy in the order of nanoseconds. GPS receivers compare the time difference between the arrival of satellite signals to tell the position. At least three satellites are needed in the calculation for an accuracy result. The first satellite provides a possible location of an object narrowed down to the surface of a sphere. The position is recorded as a radius equal to range 1. On the same token, satellite number two provides confirmation that the object is located within the first sphere (as located by the first satellite). Satellite number two provides an additional position circle of a radius range 2. The first and second satellite indicate that the object is positioned between the intersection between their two spheres – sphere one and sphere two. Finally, the third satellite shows a third sphere of radius range 3 for the positions. The object position is the intersect location of the three spheres. Finally, the fourth satellite is used to confirm the location and hence provides the time reference.

A GPS-enabled device provides geo-code location accuracy about 1 to 5 meters. Despite the fact that GPS system is widely used with many position tracking systems, it does come with some drawbacks. GPS does not work within indoor environment positioning and it requires costly power-consumption on mobile devices. In addition, not all mobile devices are GPS-enabled.

Another solution for location finding is the Cell Tower technique. Similar to GPS system, it requires at least three different cell towers within range of the device to calculate an object location for a high accuracy result. Otherwise, at least two cell towers are required. Each cell tower ,with a unique cell identifier, returns a positioning data to a requested mobile phone. Each mobile phone constantly pings a signal to nearby cell towers to get the cellular radio signal and hence some mobile phones also require costly power-consumption just like in the GPS  positioning techniuqe. Having data from all the cell towers, an algorithm can be used to calculate a final location of the mobile phone which lies in the middle. The advantage of cell tower triangulation technique is that is available for all mobile phones that have registered service providers . In addition, cell towers can be set up to send signal to mobile devices. Unlike GPS, cell towers will work in both indoor and outdoor environment. The accuracy of a position allocation depends on the density of cell towers in the area.

Wi-Fi Positioning Service (WPS) is the least accurate technique for location finding among the three techniques (GPS, Cell Towers, and WPS). IP address from a mobile device Wi-Fi connection is used to get a guessed location back from a service provider database such as Google map using API. Some of the available and well known mobile device location locator technologies are Google gear (Google map version for a mobile device), iPhone Core Location, and Navizon. Google mobile map and Navizon peer-to-peer wireless positioning tools  make the use of their massive data collection to provide a best guessed location for a device without GPS-enabled and for thoser devices that can not communicate with cell towers.

Google gear uses all three triangulation technologies to get the best accurate result. Google gear is compatible with many mobile devices including Windows Mobile, and Android. On the other hand, Core Location is another tool specifically programmed for iPhone. Apart from Google gear and iPhone Core Location, Navizon is another map locator tool. Navizon is free for a cellular enabled device, with some limitations, using cell ID positioning. However,  it is not free for a Wi-Fi or cellular enable device using cellular and Wi-Fi triangulation. Navizon database collects geo-coding data from registered users or devices with GPS-enabled. These data is collected and used as a virtual GPS. The tool uses the bank of data as a reference positioning point to locate a mobile device geo-location.

Another alternative technology is a tool so called PhoneGap that utilizes web application technology and Objective-C core features available on three mobile devices – iPhone, Android, and Blackberry.

References

  1. Bellavista, P., & Corradi, A. (2007). Mobile Middleware for Location-Dependent Services. In The Handbook of Mobile Middleware. USA: Auerbach Publications
  2. Berka, J. (2008, January 22). PhoneGa tool provides JavaScript access to iPhone features. In PhoneGap tool provides JavaScript access to iPhone features - Ars Technica [Internet Article]. Retrieved January 31, 2009, from
    http://arstechnica.com/apple/news/2008/10/
    PhoneGap-tool-provides-javascript-access-to-iphone-features.
  3. B’Far, R. (2005). Mobile Computing Principles: Designing and Developing Mobile Applications with UML and XML. United Kingdom: Cambridge University Press.
  4. Google. (2008). Services – Google Maps API – Google Code. In Google Maps API [Google Maps API Reference]. Retrieved November 9, 2008, from Google Web site: http://code.google.com/apis/maps/documentation/
    services.html#XML_Requests
  5. Google. (2009). Geolocation API. In Geolocation API – Gears API – Google Code [documentation]. Retrieved January 31, 2009, from Google Web site: http://code.google.com/apis/gears/api_geolocation.html#getCurrent
  6. Katsaros, D., Nanopoulos, A., & Manolopoulos (eds), Y. (2005). Location-Based Services. In Wireless Information Highways (section iv – location-based
    services). United States of America: Idea Group Publishing . Retrieved
    November 6, 2008
  7. Mallick, M. (2003). Mobile and Wireless Design Essentials. Indianapolis,
    Indiana, USA: Wiley Publishing. Retrieved November 8, 2008
  8. Mark, D., & LaMarche, J. (2009). Where Am I? Finding Your Way with Core
    Location. In Beginning iPhone Development: Exploring the iPhone SDK (pp. 429-439). USA: Apress
  9. Mexens. (2005-2008). How it works. In Peer-to-peer wireless positionin [product description]. Retrieved January 31, 2009, from http://www.navizon.com
  10. Olla, P. (2008). Global Navigation and Satellite Systems and Services. In
    Commerce in Space: Infrastructures, Technologies, and Applications
    (chapter v). USA: IGI Publishing. Retrieved November 8, 2008
  11. Wu, S.-L., & Tseng, Y.-C. (2007). Wireless Ad Hoc Networking-Personal-Area, Local-Area, and the Sensory-Area Networks (S.-L. Wu & Y.-C. Tseng, Eds.). USA: Auerbach Publications. Retrieved January 30, 2009

Links to other blogs in this project

Tags: , , , ,
Posted in Mobile Devices, Sahana, development | No Comments »

Sahana. User friendly interface

Monday, January 26th, 2009

Assylbek Zhumadyrov
Sahana, UI

Audience: the audience of this project is all users of Sahana system from quests and regular users to administrators.
Goals: the main goal of this project is to design the easiest and simplest interface for users of Sahana. Achieving this goal will include two main steps:
1. designing a logical model of the entire Sahana system to make addition of new modules and future growth more proper and logical;
2. designing user friendly interface for all users;
The second point is more important and will be described in details later.

Is it important?
The main idea behind this project is making disaster consequences handling easier and quicker. By designing user friendly interface navigating and action performing will be easier and faster which is vital in case of Sahana system when people’s lives are the price of the reaction time. To do so it is important to have a logical model of the entire system. There are many developers of Sahana all over the world and they have added and keep adding lots of features into that system. As a result we have the system which is full of features but has lack of logic in it.

One very important point and at the same time, the main problem, is to design user friendly interface without rebuilding entire system including database. Designing user friendly interface includes several steps:
1. designing intuitive and comfortable navigation system (menus);
2. designing all menus the way so only the links/sections that are available for that particular type of user would appear on the page (administrator, quest, volunteer etc.);

Tags:
Posted in Design, Logical Design, Sahana, Uncategorized, development | 5 Comments »

« Older Entries