Showing posts with label google chrome. Show all posts
Showing posts with label google chrome. Show all posts

Sunday, July 14, 2013

Announcing Social Photos v2!

I have been working on this side project for quite a while now and I am happy to announce that it is launch ready now!

Visit http://socialphotos.net to manage all your digital photos across Social Networks in one roof using a simple intuitive user interface.

Features Include:

  • Transfer Photos
  • Transfer Albums
  • Download selective albums as a zip file
  • View Slideshow of your albums
  • Monitor progress in a simple pane
  • And much more!

Please do feel free to give feedbacks/suggestions. Use it and Share it!


-Vignesh

Saturday, May 7, 2011

Orkut Deja Vu - The Technical Side!


Its been almost two months now since I first launched "Orkut Deja Vu" - A series of web applications and a chrome extension that helps you move your memories from orkut to facebook. Personally, I think the application was a good hit. In this article i will try and explain the technical side of it and the various hurdles faced on the due course of development.


Note: This article is for the technically inclined and if you don't want the technical details and just want to use the application, visit http://orkutdejavu.foamsnet.com!


Java and My server!


To begin with it, my server is a VPS running linux with a humble 700MB RAM and a shared processor. My search for an Orkut API ended with orkut os client - An official API provided by Google. This is more of a library than an API and only the java implementation of the library was very sophisticated (though there were php implementations, they weren't that good). Ever since i started learning computer science, if there was one thing i hated, it was java (now don't even get me started about perl).


So there lied the first problem in front of my eyes: Running java in my server. I didn't want to take up the pain of setting up JSP for this sake and decided to just call the java program that does the orkut calls from PHP using shell_exec. I know it isn't a safe option, but since there is no user passed data and the calls are hard-coded, i was sure that there was no injection vulnerabilities. Yet this approach isn't very efficient as it spawns a separate java vm for every exec call, but it was a compromise that i had to make for not setting up a java based server.


OAuth - The headache!


The orkut library's OAuth implementation was really messy. Fortunately, it had a method to explicitly set an OAuth access token obtained from elsewhere. That said, I used Zend OAuth library in PHP to perform the 3 legged OAuth and use that access token in the java programs. There were totally four java programs: one each to fetch the user's orkut name, albums list, photos and scraps. The java programs printed the output as JSON if it was successful or nothing if there was an exception. PHP then parses that JSON. I used JSON so that all the escaping will be taken care by the JSON libraries and thereby ensuring safety of data transmission.


Photo Album Migrator


The photo album migration was quite straight forward without much hurdles. All i had to do was integrate the following: Image gallery, Facebook API, Orkut API and write some simple javascript that made AJAX calls to transfer the photos. This was quite a cakewalk as i was already very familiar with the Facebook graph API.



Scrapbook Downloader


Again, the programming side of this was quite straight forward. But there was one major challenge involved in designing this. The java program generates a html file containing the scraps which is then converted to PDF. HTML to PDF conversion is CPU intensive and hence needs to be done with care. I could have used a resource manager like Sun Grid Engine, but i did not want to make things complex for a simple job to be done. Also, the conversion is not done programatically by a library as all the PHP PDF libraries were memory-wise very expensive (a file with ~100 scraps always exceeded PHP's memory limit of 64MB). So, I used a external command line utility (wkhtmltopdf) to accomplish this conversion. Again it was a simple shell_exec with hard-coded arguments.




Testimonials Migrator


This was the really challenging part. There was no Orkut API that gave access to users' testimonials. But i didn't want to give up. I really wanted to pull off a tool that can migrate testimonials to facebook. So I thought of attacking this problem from the heart of orkut - the orkut website. Obviously, the first thing that came to my mind was a Google Chrome extension. The extension will inject a javascript into orkut.com website and add a "Post to Facebook" button beneath eacch of your testimonials.


The first hurdle in accomplishing this was that there were two versions of orkut (old and new) with different page structures. I didn't want to write two different scripts to handle the versions. Instead i wrote another script that detects the version and if it is new, it prompted the user to redirect to the older version in order to use the extension. The next job was to understand orkut's DOM so that I can place the buttons. This ended up being quite an easy job too.


Another glitch in chrome extensions is that we cannot specify images directly in CSS for content scripts(for e.g.: background: url(a.jpg); is not possible), as the CSS will run in the scope of the website. So, it has to be either done programatically using javascript or encode the image in base64 and hard code it in the CSS. I chose the first option. From this point, it was fairly straight forward. When the user clicks on the post button, store the corresponding testimonial using HTML5's local storage and create a new tab where the user can choose the posting options. Again, the facebook authentication and API usage here were simple as i had enough exposure already.


Epilogue


Though it seems like a simple app, huge amount of thoughts are put into every single aspect in design of the application and the entire development process was a fun journey with a great learning curve. This application has made me feel my web presence. Web is really a great platform for amateur developers like me. I have got around 20 new followers in twitter and a person from brazil appreciating me for this application. I have really been motivated a lot by this and hope to continue the same stride in creating usable applications as this one!


This post will not be complete without a heartfelt thanks to all those who supported me on due course of development and all those who used and shared this with your friends!


-Vignesh

Thursday, December 2, 2010

A flaw/feature in Google Chrome Extension design!

I am recently into customizing my road in the web with simple google chrome extensions to get and share content in the web the way i want. After having spent a good amount of time with the Google Chrome Extension Framework and their javascript API, i feel there is a flaw in the design of it. I still am not sure if this is a flaw or an intended feature.

Before describing the exact flaw, let me give a brief overview of things whose understanding is required to understand the flaw.

Browser Actions
Browser Actions are those using which your extension can do things along with the browser. Every browser can include a pop up page (yes the one which pops up when you click on the extension's icon on the top right corner). As of now, the only way to open up the pop up page is by clicking the icon. This point is important. Let me come back to it in a while.

Context Menus
Extensions can add custom context menus (the one that appears when you right click on something within the browser).

The flaw/feature
Now, as of writing this, there is no programmatic way of invoking the pop up page (other than clicking the icon manually as mentioned earlier). This makes sense because if a non-manual initiation of the pop up was allowed then it would be an irritation for users to see the pop up page annoyingly appear just when they install an extension.

Whereas, the restriction now enforced is a bit too strict. The restriction should look something like this, "The pop up page can be initiated only by a manual action", whereas the restriction that chrome enforces now looks like this, "The pop up page can be initiated only by clicking the pop up icon". This restriction is too much because, there are other manual actions than clicking the pop up icon, that might require an user interactive window for processing. For example, consider the case of a context menu. When a context menu is clicked, it completely makes sense for the extension to initiate the pop up with the context based content and enforce user interaction. This is simply *NOT* possible now.

Other options
Though the clean solution is not possible, there are one or two workarounds that i have found out to overcome this problem.

  • If the user-interaction required is really simple, then merely use the javascript prompt('') function from the background page.

  • You can always create a tab and make the user interaction

  • Use a floating div or a jquery modal window to enforce the user interaction (this can be done using the executeScript API function).



-Vignesh