A stint at building a mobile web application

http://deostroll.appspot.com/pnr

Spent a whole weekend trying to build a simple mobile web application using Google's AppEngine as my web server. Took this initiative to simply know what its like building a mobile web applications, how is it different from doing traditional web applications. I did spend time googling and learned about a couple of things:

a) How ajax was made more convenient for web developers?

There are several libraries which abstract the usage of the XMLHttpRequest object. On different os platforms we have different ways of instantiating this object. But most libraries abstract this leaving you to only concentrate on what service you call, what data you send, and what to do once you get a response back. There are many libraries, like jQuery, Prototype, and YUI libraries which hide complex details enabling the developer to make high-end ajax invocations by supplying classes.

$.get( 'sample.jsp', ResponseHandler);

But most of these libraries are bulky. They are designed for popular browsers like Firefox, Safari, Internet Explorer, etc. Do you think you can use these libraries for your mobile web page? Do you need such heavy libraries again?


b) How does the mobile platform differ?

Mobiles phones possess limited computing power. The processors inside phones are designed to make optimum usage of memory and other resources. A simple operation like adding might take more cycles than a normal desktop computer CPU would. More the number of cycles means more energy is consumed. Hence programs written for mobile phones must be written/used in such a way that they utilize less power.

c) Designing your web applications so that your phones take less power

This essentially means making your mobile phone processors do minimum work to the core. But developers don't freak about and measure cpu cycles to know if their web application is running fine! Instead they simply serve more html. For e.g. if its some kind of report you have to serve to a mobile browser; html-ize it. If there is some “work” that has to be done at the client end for this report – minimize it.


d) AJAX does help those who support it.

There are some mobile phone browsers that don't have AJAX capability. Web applications for such phones have to be designed to utilize a postback model of serving requests. Almost every request is an HTTP POST; hence the browser has to refresh the screen, and then load new contents, etc. This obviously consumes more power. Such levels of consumption can be drastically brought down if those requests were served in an ajax-ed manner.

e) Do remember all those poor GPRS networks...

This contradicts with point c. Although its ideal to serve as much as html, one has to realize the time it would take to for that data to reach the browser. Most GPRS networks have very limited bandwidth, and hence sending a lot of data for the page to load isn't all that a good idea. So in this light we must send minimum amount of data to the browser. In fact JSON could do a great deal in this sphere. But then its up to the developers fair judgment to find the right balance. And once you learn it, it won't be all that difficult.

Conclusion:

As far as points c & e are concerned I just feel that the first law of thermodynamics can be neatly taken note of...

Happy programming :)

AJAX and social networking

I just remembered this blog is also about things on the internet that I find fascinating.  And if you are a total computer dummy, ajax might sound like a xenophobic term to you already. In the web space ajax is a buzz word. To make a long story short, ajax is just a simple technique by which your web page can be made to look more interactive. The expansion of AJAX is (brace yourself) Asychronous Javascript And XML. In my opinion it is a bundle of many technologies. You probably might even hear the word JavaScript frequently. But something you don't hear, but somehow involved in the whole internet fabric is the W3C. I am cutting short all the history; it isn't difficult to google and find out however. The main focus of this post however is how ajax has influenced social networking and proxy browsing. And if any of you people decide to build social networking sites here are some points that you might want to implement in the beginning stages.

Do you remember the first social networking site that got popular? At least in this part of the world I feel it was orkut. There are other sites more advanced and user friendly than orkut, yet orkut remains to be a classic example of a social networking site. I still love the idea behind leaving a scrap. So simple. Less noisy. Beatific. But orkut has been privy to many cultural & privacy problems. It was blocked in Iran because the Islamic community there had strong views about dating, etc. After the Iranian government blocked the site, there have been a lot of proxy sites which allowed you to access orkut. Proxy sites allowed for anonymous browsing of orkut pages. During those times orkut pages were fairly simple I guess. Later google disallowed anonymous browsing over its secured http page. Actually google did a lot of things. The most prominent thing you might always miss is the Loading... part.

This is what google did to render proxy browsing useless. So here is a little about how orkut page gets loaded. After you provide your username and password to log-in to the site, you are taken to the main page (Home.aspx#Main). From a web designers perspective this is nothing but an empty page with place holders (like your friend list, upcoming birthdays, friend updates, etc) where data & images are supposed to sit. These place holders are not marked to be visible to the user. Hence the net effect is a nearly blank page except for the background color and all. (You are welcome the view page source of the orkut main page to testify this fact).

I am guessing that even the "loading..." part is also invisible; it is made visible via means of scripts which execute once this basic data viz mentioned above is loaded. Of course there are some complex google javascripting involved here. Now as the "loading..." placeholder is visible, it initiates a series of call (simultaneously may be) to many google web services (in this case orkut application programming interfaces aka orkut apis) to fetch social data. This data can be suitable formatted in JSON or XML which is then again processed by the javascript on the page, and routed to the appropriate place holders. The net effect of this is visible content.

It is not difficult locating where the javascript on the page is...the scripts are not indented to be readable by humans readily. There is a particular way of writing your javascript, wherein you minimize the unnecessary spaces between two statements, and between the expressions. This process is called minification. It serves 3 purposes. One, it compresses the page size. Two, is your browsers are able to parse the javascript better and faster, as there are no spaces, and three, well, the obvious, to make it 'not easily readable'.

So you might be wondering how does ajax figure in all of this? Ajax is the technology via which the orkut main page makes simultaneous calls to the orkut apis to fetch social data.

So how does security actually figure in this? How does it incapacitate proxy/anonymous browsing? This is where you need to understand how proxy browsing works and how a normal browser works. And brace yourselves, this might sound too technical.

Usually when a web page is requested by a browser, its source code (html markup) is downloaded. The browser reads the content and renders it accordingly to the user. Internally in the application's memory space there is a data structure which represents the source code of the web page. Why the data structure? That too in the computer's memory? Suppose if there were scripts (like javascript) for e.g. on the web page, and it did some modifications, like say, change the font of a paragraph of text, the browser will "walk" this structure, find out where in the whole data structure this change has to be affected, applies the new formatting rules (in this case changes the font to a different one), re-renders how the page should look. So what the user sees is an unobtrusive change. AJAX works like how normal javascript should, except it is able to change the above mentioned data structure with data it has fetched asynchronously via the internet. But what happens to the initial source code which was downloaded by the browser? It doesn't change.

Proxy browsing involves a browser program which runs on the web server. Since its a web application it has no user interface to be exact. It doesn't need one. All it does is that it downloads data (ie the markup) from a different web server, and relays that content back to the person who is trying to anonymously browse. There is no execution of javascript here. Hence what is initially downloaded is simply relayed. There are more complex programs which scan the contents, parse the hyperlinks, etc, so when you click on a link on the proxied web page the navigation request is routed via the proxy server it self, and not to the actual server. The advantage to proxy browsing is that you are not compromising on your location to the target web site. The disadvantage it none can be trusted. Proxy browsing is not safe. You are compromising your account credentials to a different server.

I won't say proxy browsing can be obviated completely. It is still very possible. But its a hell lotta work. Sometimes it better people simply enjoy the site rather than hacking it.

ubuntu: starting your favourite word program from the run dialog

This can in fact be done on most linux distros. Most machines will come with a default office suite called Open Office. But starting up this word processor program isn't as simple as it is on windows where you can simply type in a command in the run dialog to start the program!!!

But fortunately, this is something a little shell scripting, and symbolic linking can fix.

I simply create a shell script (writer.sh) to do the necessary starting up of my word processor program. The command to startup Open Office's Word Processor program we've to simply type:

ooffice -writer

You could append the above command with a word document you already have on your file system; so it will open the document as the application loads.

Below is how the script looks like:


#writer.sh
if [ $1 ]; then
ooffice -writer $1
else
ooffice -writer
fi


You should probably save this file in your /usr/bin path. Now give necessary execute permissions for the above script file.

chmod +x writer.sh

Now if you type writer.sh in shell, your application should show up. Now simply create a symbolic link to it and store it in the same path above.

ln -s writer.sh writer

Now if you simply type writer in shell or in the run dialog your word processor program should startup.

Happy ubuntuing...

Note: most of the above command should be run as root