Advertisment

5 Steps to a G-Talk Interface For Your Web Application!

author-image
PCQ Bureau
New Update


Advertisment

What can a chat interface do for my web applications? Well, interactivity and all that follows. If you provide a chat address for your web application and you have someone available to chat live with visitors to your website during working hours (e.g. for live web-based technical support), you can set up chat bots in your application, which, upon receiving a customer's IM on behalf of your application, can send instant automated replies such as “We are closed for the day”,”We are currently experiencing unplanned downtime”,etc.

Advertisment





This is similar to how you would interact with an IVRS using the telephone. When you set up a well-defined chain of such automated responses in your web application, not only will your actual support calls reduce but also users will be freed from the frustration to look up FAQs and other such documentation. Owing to quick context-sensitive replies, their user experience will be better and they will not need to wait for you (or your website's chat person) to return to office the next working day. They won't go away giving up their patience. Probably the best part is, they are interacting with your application using a program (an instant messenger in this case) that they are so comfortable using.



If registered users/members of your website have provided you their chat address, you, using your own application, can detect whether they are online, without requiring them to visit your website, thanks to the chat notification features. With the user's consent, you can contact them when they are online to conduct instant polls and other such tasks (such as obtaining follow-up information required to progress in a technical support case or to ask quick questions about the products that they are interested in or for feedback, etc). Potential opportunities are many more.



The following instructions apply to Java developers. However, the functionality can be achieved with Python or Go too, both of which are supported (with Go in an experimental state) on Google App Engine.

Advertisment



1. Call the XMPP(Extensible Messaging and Presence Protocol) service API



In order to make use of the XMPP service API, you will need to import the required classes from the com.google.appengine.api.xmpp package.



2. Identify the receiver by defining a JID for the same

Advertisment



A JID represents an XMPP address for the recipient. You define a JID by invoking the JID constructor as:



JID mycustomer = new JID(“abc@example.com”);



3. Construct the message

Advertisment



Sending structured data in the form of XML is supported. However, you can also send plaintext Java strings as the body of the message. Any of the message types defined in RFC 3921 can be sent.



You construct the message in a similar manner to how you would send a quick email, i.e. click on the `Create new message'/`Compose' button/menu item, specify a `To:' address and paste pre-defined text or type something in the body. The following lines of code respectively do the same, except for the last one which actually builds the message for internal representation purposes.



Message messageformycustomer = new

MessageBuilder()

.withRecipientJids(mycustomer)

.withBody(someTextGoesHere)

.build();





4. Call the factory method to getan instance



XMPPService myappchat = XMPPServiceFactory.getXMPPService();



5. Send the message



myappchat.sendMessage(messageformycustomer);



That's all you need to do to send messages. With a few more lines of code, you can also determine delivery status of your message and accordingly take further actions in your code.



How do I go about receiving instant messages in my application?



Depending on your requirements, you will need to make use of any/all of three inbound services:



- xmpp_message allows your application to receive chat messages from XMPP-compliant chat services.



- xmpp_subscribe allows subscriptions between users and your application for the purpose of exchanging data, such as chat messages, presence information, and status messages.



- xmpp_presence allows your application to determine a user's chat presence (available or unavailable).



As required, you will need to enable these services in the configuration file appengine-web.xml of your code's folder hierarchy.



With the XMPP service enabled, App Engine makes an HTTP POST request to the following URL path when your app receives a chat message:



/_ah/xmpp/message/chat/



To handle incoming messages, you need to create a request handler that accepts POST requests at this URL path. You might guess by looking at the URL that this path is restricted to app administrators automatically, which is true. The XMPP service connects to the app with “administrator” status for the purposes of accessing this URL path. You can configure the path to have this restriction explicitly if you like, but this is not necessary. Only the XMPP service and clients authenticated as administrators using Google Accounts can access this URL path.



Risks you need to be aware of and how will it affect your billing on Google App Engine



Currently, group chats are not supported and messages intended to be received by your app must be of either the `normal' or `chat' types. Any other type of received message will be ignored, preventing the request handler from being triggered. If you need to send the same message to multiple recipients, each message will be charged separately since it will be considered as 1 whole unit of transaction on it's own.



Also, with recent regulatory policies to restore the SMS limit per day as well as to require telemarketers to register, you might want to reassess the value proposition of using this method to reach out to your customers(or for them to reach out to you).



Every service request that you make for using XMPP in your app counts toward the XMPP API Calls quota. The total size of the API call is limited to 1 megabyte, including the total size of the recipient list and the message body. An outgoing message, whether be it a chat message or a chat invitation, is considered in the following quotas: amount of XMPP data sent, number of recipients messaged/invited, and your billable outgoing bandwidth. For incoming messsages, the no. of requests, as well as the billable incoming bandwidth are taken into consideration. Each incoming presence and subscription message counts as a normal HTTP request.



As mentioned above, you can set up request handlers for incoming XMPP messages. Any computation that is performed in these request handlers counts toward the same quotas that apply to web requests and tasks for other pages in your website.



In addition, any message, whether incoming or outgoing, cannot exceed 100 kilobytes and you cannot send more than 100,000 invitations in a day.



What if website's visitors are not comfortable with GTalk/provided some other chat address



This isn't just limited to Google Talk. It applies to any XMPP-compatible instant messaging service. Right from iChat on your MAC OS X to Mozilla Thunderbird on Windows to Pidgin on Linux to IM+ on your mobile, dozens of software clients (many of them free) implement the XMPP protocol. Given the userbase of such applications, it is delighting to imagine how many users will your application be able to contact when it makes use of XMPP.



As a user, would you like to interact with your favourite applications and websites using instant messaging? Do you consider it to be much more convenient and an indication of better user satisfaction? Let us know by writing to us at pcquest@cybermedia.co.in

Advertisment