Ubiquitous Blogging. CS8803 AIA Team 5 Abbas Attarwala
Ubiquitous Blogging.
CS8803 AIA Team 5
Abbas Attarwala
Ruchi Goswami
Dhawal Shah
Arun Kutty
Contents
1 Introduction and Motivation.
We had six major motivations that inspired and motivated us to build Ubiquitous Blogging application on the Android mobile framework. The purpose and scope of this report is to highlight these six motivations and explain and present to the reader the architecture (backend) and the functionalities/feature set (front end) that revolves around these motivations in a clear and concise fashion.
1.0Publishing Blogging data on Google Blogger Website. Imagine a scenario that a person is at Mac
Expo Event or a Tech seminar where latest technology products are being released. The user just has an
Android cell phone and wishes to blog about the latest events unfolding at the event, so that his followers and readers on Blogger website are abreast with the latest developments. It is difficult to blog from a cell phone relative to a computer, because the user is required to arrange images and text accordingly before publishing it on a website.
1.1 Blogs that need to expire after a certain time interval. There is free pizza and food in Klaus.
Obviously this entry needs to live only for 30mins from the point of entry. The purpose, meaning and value of this blog entry degrades rapidly after a certain time limit. Wouldn't it be nice if the user can click on a point of interest on the map, that opens up an elegant sophisticated UI allowing the user to create such a blog entry and putting in a time expiration.
1.2Blog on Restaurants fetched from YELP. All of us love eating and trying out new restaurants. We now allow the user to instantly start blogging on the restaurant with his friends by allowing the user to select a region on the map that aids in discovering restaurants from YELP for that region and then enter thoughts and blogs for that place. This is in real time so friends on his contact list, can share their thoughts and reply back.
1.3Random/Instant micro (blog+thoughts) 140 character limit.
Many times, all of us have some instant thoughts which are completely random but we like to share it with our friends. These micro thoughts can be posted instantaneously by clicking on some point on the map and then entering the micro thought for that location. Again these thoughts are instantly shared with friends on the contact list allowing friends to comment on them and start a thread of micro blogs for that event.
1.4Passive Blogging. Until now, all the above motivations are active blogging. Active Blogging is something where the user is constantly engaged and active in blogging. The user selects text and image and starts blogging. In 1.4, we introduce a new concept, 'Passive Blogging'. As the term suggest,
Passive Blogging is opposite to Active Blogging. We allow the user to select a geographic region on the map in addition to a time component. For the location and time the user enters some text and starts
running the application. Now using the GPS technology from the Android cell phone, we match the location and the time component, when these conditions are true the user's blog entry is posted for that location.
1.5 Introducing Mr.Bot. All the motivations have one thing in common. They require the presence and availability of an Android cell phone in order to make use of the service we provide. This is a limitation to the project, because very few people own an Android phone. In order to make these services available to as many people as possible, we were able to port a subset of these services to non Android users by developing an Mr.Bot that runs directly on the Google Chat window on the user's Gmail account. The user can query the bot to view and add blogs.
2 System Architecture:
From a very top level, the project is divided into two parts. The Frontend (Android Client /Mr Bot) and
Backend (Amazon EC2 Cloud).
The Front end for Android Client utilizes the Android 1.1 SDK framework. This framework is used exclusively to load the Google map and develop all the UI widgets. In total we had 17 classes developed for the Android Client. The front end also fired the YELP query using coordinates from the region drawn by the user on the map to find restaurants. Each class was well encapsulated with a single responsibility. This allows our classes to have low coupling and low dependencies between other classes and at the same time maintain high cohesiveness. This software development design paradigm allowed our code to be scalable because code duplication was minimum and debug time was shortened.
For Mr.Bot we used the XMPP protocol to transmit messages between the client and the server and
Google's libjingle library for the processing.
The frontend communicated with our backend servlets on Amazon EC2 cloud in SOAP and XML. The frontend passed all its queries as HTTP Post or HTTP GET to the servlets and received an XML response. This XML response was parsed on the Android device to extract the data and perform the required actions.
The backend was completely hosted on Ubuntu 8.04 image running on Amazon EC2 cloud.
We deployed the Apache Tomcat 5.5 application server on the cloud that hosted our J2EE servlets. The
J2EE servlets which are Java programs unpackaged the HTTP POST and HTTP GET requests extracted the tokens and performed the required actions as necessary. Some of the important actions performed
by our servlets are 1) Insert geographic rectangular region with time component on Google Calender. 2)
Receive image in base64 encoding and perform decoding to reconstruct the image. 3) Assign each image a unique URL so image names dont clash/conflict. 4) Allow user's blog to be dumped onto
Google Blogger Website. 5) Load JDBC drivers for SQL querying and insertion. 6) Perform SQL querying based on rectangular coordinates and server ID received from Android device. 7) Assign a unique ID to each YELP content received from the Android device.
Figure 1: System Architecture of Ubiquitous Blogging
2.1
Issues on Amazon EC2 Cloud: The biggest challenge was to address the issue of redirecting the URL of the cloud from port 80 to port 8080. The DNS entry of the cloud provided by Rightscale points to port
80, but the Apache Tomcat server that we deployed on the cloud runs on port 8080. We could not just make the URL from http://ec2-174-129-134-63.compute-1.amazonaws.com/ to http://ec2-174-129-134-
63.compute-1.amazonaws.com:8080 as it simply did not work. So what we did is to use IP tables. Iptables
is a Linux command used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. This allowed us to forward all request coming to port 80 to port 8080. This clever way, allowed us to use the original DNS URL provided by Rightscale, which now points to port 8080, which hosts our Apache
Tomcat server.
3 Publishing Blogging data on Google Blogger Website.
As mentioned in the introduction it is imperative and important for users to quickly publish blogs that contain text and images onto their website so that their friends and family are kept uptodate with the events the user is blogging about.
Client
In this use case suppose a person has his friends and family following him on blogger.com. The person clicks the images and uploads the images from the gallery (Implemented using the ‘ImageSwitcher’ and the Gallery widget of android) in his phone, inserts text and sets the background color . The user also has the option of selecting 1 out of the 4 templates for blogging. If an image has to be uploaded along with the blog to Bolgger.com. Further, we allow the user to choose from predefined templates so that it becomes easy to insert photo and text in any combination or order.
Figure 2: All the fields selected along with the images are sent to the server via HTTP Post. The selected image is converted to bitmap which in turn is compressed using base64 and then converted to string before sending to server.
Server
We used Blogger API and have implemented all of its features like adding a post, deleting a post, adding comments, deleting comments, updating post.
The server receives a HTTP POST request from client (Android). Base64 encoding is used for MIME content transfer. The server decodes the Base64 encoded image. The decoded image is then placed in an appropriate location on cloud and unique name for the image is created using the random number generator. The URL for the image is created and the contents are generated according to the template selected by the client. If the client has selected customized background color and foreground color, contents are generated accordingly. If the request is to add a post on Blogger.com, appropriate method is called and the post is posted on Blogger.com. The request is also inserted in to SQL server on cloud.
The various entries stored in the SQL server on cloud are:
• latitude and longitude of the location
• Text Contents of the Post to Blogger.com
• URL of the image on cloud, this is the unique URL created by the server
• Owner of the Blog, who has written this blog
• Date and Time of creation of Blog
• Post ID the unique ID which identifies the Post
• Tag and Title of the Blog
• Expiration Date and Time of the Blog, this is in case you don’t want the blog to be visible after the expiration date and time.
• Server ID, this is generated by the server to keep track of conversations. Unique server ID is generated by the server for each new conversation. If the request from the client is reply to the previous post same server ID is stored back in the SQL server.
The response from Blogger.com is parsed and an XML is created to send the response to the client.
After uploading the updates to blogger.com a new blog would be created in Blogger.com with the uploaded picture, text, background color etc.(Fig 3)
Figure 3: The Http response returns an XML which is parsed and as a result shown as a blogger .com thumbnail on the map
Figure 4: The user can see with the Google Blogger icon, the location from where the contents was published onto
Blogger.com
4 Blogs that need to expire after a certain time interval
There is free pizza and food in Klaus. Obviously this entry needs to live only for 30mins from the point of entry. The purpose, meaning and value of this blog entry degrade rapidly after a certain time limit.
Wouldn't it be nice if the user can click on a point of interest on the map that opens up an elegant sophisticated UI allowing the user to create such a blog entry and inserting time expiration.
Client:
Here the main part is the “Time Expiration”. After a certain period of time which the user sets the blog would not be valid i.e it would expire after that specified time period. The UI would be the same as above.
As shown in figure below the user sets the expiration time and posts the blog. On the map it will be displayed until it is expired and automatically deleted.
Figure 5.0 The user can enter the time expiration for blogs that need to expire.
Server:
When server receives any fetch request from the client like fetch by location or fetch by tag, server queries the SQL for all the entries that fall in that category, server sorts the results according to the date they were added in the database, this is to make sure the user can read the conversations in the order they had occurred. It checks if the expiration date of the response was before the current date, then the server suppresses that response and does not send that entry to the client. If the expiration date is same as current date and expiration time was before the current time, the server again suppresses that entry.
Basically the server ensures entries in the SQL which have expired are not visible to the client and does not send them to the client.
XML is generated dynamically from the entries obtained from the SQL and is sent to the client.
XML generated by the server is such that, all the entries which are related to same server id, i.e. which is regarding the same conversation are embedded in the same balloon tag.
SAMPLE XML created by the server: Each of the balloon tag is the dialog box that opens when the
user clicks on the icon on the map. Each balloon tag contains the latitude/longitude that allows the maker to be correctly drawn on the map. Further the balloon tag has its children, the content tag that is populated with the blogs and image links that people have blogged until that point.
<options>
−
<response>
−
<balloon>
<ServerID>1214</ServerID>
<latitude>33.780105 </latitude>
<longitude>-84.395815 </longitude>
<tag>Seattle Coffee </tag>
−
<title> http://tbn0.google.com/images?q=tbn:M51M6R1qLgxNEM:http://www.sourcedesign.com/images/seatt les_best.jpg
</title>
<time>null </time>
<ExpDate>null </ExpDate>
<PostBy>Y </PostBy>
−
<content>
<text>i am sitting in SC drinking coffee </text>
<videoFileName>null </videoFileName>
−
<imageFileName> http://ec2-174-129-134-63.compute-1.amazonaws.com/BloggerMain/19312picaia.jpg
</imageFileName>
<owner>abbas</owner>
<dateAdded>2009-04-01 </dateAdded>
</content>
−
<content>
<text>Coffee is overpriced </text>
<videoFileName>null </videoFileName>
<imageFileName>null </imageFileName>
<owner>arun</owner>
<dateAdded>2009-04-01 </dateAdded>
</content>
</balloon>
5 Blogging on Restaurants.
We like to thank Dr Ling Liu for suggesting this very nice use case to us during our proposal meeting.
There are two major components to this use case. The user initially draws the rectangular region on the map. Based on the upper left coordinates (latitude/longitude) and the bottom right coordinates
(latitude/longitude) we fire the YELP web service. From YELP we receive a bunch of restaurants. Each of these restaurants has a unique YELP ID assigned to it.
The Android client device then extracts these YELP IDS and passes it as a HTTP GET request to our servlets on Amazon EC2 cloud to fire the SQL database if there are any blogs associated with that
YELP ID. If there are any such blogs, the servlets return back an XML response with the contents, if not then the servlets return a NULL stream object. Based on the response, the Android client widget knows to populate the UI widget with just YELP data or in conjunction with the extra blog data received from the servlets.
The above design/algorithm works without any major flaws. The reason being, we query our internal
SQL database before drawing the YELP entries allowing the widgets to populate the UI accordingly. If the servlets return NULL, then the user can initiate a new discussion for that YELP entry and become the owner for the blog. Any subsequent querying by other users will now always receive some contents from the servlets as the owner has been established for that YELP entry.
Figure 6 : Draw a region and show the restaurants icons.
Figure 7: Click on an entry and show a blogging in progress.
6 Micro blogging on Random Thoughts/Ideas.
Instead of blogging on a particular YELP entry, we also allow the user to click on any point on the map and start micro blogging. This could be any point, it could for instance be Klaus, home, student center or gymnasium. A simple and elegant UI opens up allowing the user to fill in the micro thoughts with an image and start micro blogging. For each such new instance, the servlets running on Amazon EC2 cloud assign a unique new server ID to a microblog. All subsequent discussion on this micro blogs by friends and family of the user share common attributes. Some of these attributes are 1) server ID 2) Geographic locations 3) owner. With these attributes, the querying of data from SQL server is minimal with efficient queries and the response generated by the server in XML form is clean and elegant.
Figure 8: The user sharing random ideas and thoughts as micro blogs from our application.
Figure 9 : A new icon is shown on the map symbolizing that it is micro thoughts.
7 Passive Blogging:
The concept behind Passive Blogging derives from the lecture on Spatial Alarms in our AIA class.
We took the idea of Spatial Alarms added a 'smart' time component to it and remarshalled it so that it works seamlessly and flawlessly on an Android cell phone device. In addition, this feature required a simple, elegant UI that allows the user to quickly draw a rectangle over the map
(Geographic Location) and add a time component for the region drawn. We call it 'smart' time because we allow the user to create a recurrence of the time entered. This means, that the user can make the time for the location occur daily, or weekly, or monthly or yearly or simply create an all day event. How were we able to pull this off?
The data for the region selected and the time component is completely stored on Google Calendar through the servlets running on our Amazon EC2 cloud. Using the API provided by Google Calendar we allow the user from the Android device to create 'smart time'. The data for time and location is
packaged together and sent to the servlets as a GET request. The servlets unpackage the HTTP request and filters out the geographic location from the time component and then repackages them in an RFC
2445 compliant syntax before dumping it on Google Calendar. Our application only polls the backend once, unlike other applications that constantly need to poll the backend to match the user's current location with that of the region residing on the server. We poll it only once, because at any given time the Android client device is interested in knowing the current day's entries on Google Calendar. So by polling it once, it gets the current day events (which also includes the geographic location). Now begins another set of internal polling within the Android device which does not consume any bandwidth as it does not go over the network. This 2 nd
polling compares the content within memory from the current location whether any event needs to be raised or not.
Figure 10: The user selecting a region on the map (Geographic Location)
Figure 11 : The user selecting the time for the geographic location selected in figure 6
Figure 12: When the user is in Piedmont Park, a new icon appears on the map.
Figure 13: Clicking on the icon, the same text as entered in figure is shown.
8 Mr Bot.
As presented in the introduction, the purpose of developing the bot is to allow non Android users avail the services that are available for Android clients. The requirements for the bot were that it should be simple, non intrusive and have simple query engine for adding and viewing blogs. The blogs presented should also have the additional Google static MAP URL so that the user can click on it and view the blogs presented on a static JPG rendered from Google MAPS.With these requirements, we decided to build the bot using XMPP protocol and Google's libjingle library. At the very basic, the BOT has three functionalities.
1)Add Blog
2)View Blogs
3)HELP command.
The HELP command is like the man command available on the Linux Shell terminal. The user types in
HELP, and the BOT replies back with the acceptable syntax for Adding and Viewing Blogs.
Figure 14: The Bot Help Screen.
Figure 15: The View Blogs on the Bot chat window.
Figure 16: The Google MAP link created by the Bot for the user to see the blogs location.
9 Future Scope
1) For micro blogging, Twitter could be incorporated.
2) For now, only images can be added to posts. This could be expanded to include video as well as audio. Typing on a mobile device can be cumbersome. So extending this to include audio/video would encourage more people to participate. Also adding human voice/video will give users more freedom of expression than is allowed in a traditional text only blog.
3) Clients can be expanded to include other handsets like Windows Mobile, iPhone etc
10 References
4) Google Android SDK. http://code.google.com/android/
5) Professional Android Development by Reto Meir
6) The Busy Coder Guide to Android Development by Mark Murphy
7) RightScale Tutorial on Deploying applications and server products on the Amazon EC2 cloud. http://wiki.rightscale.com/2._References/01-RightScale/03-
RightScale_API/RightScale_API_Tutorial
8) Special thanks to Dr Ling Liu for her valuable inputs and suggestion during the course of the
development
