Synchronizing Twitter data using Sun's GlassFish Mobility Platform

2009-03-18T11:47:00.000-07:00

ITDistributors is a Sun Microsystems Principal Partner specializing in the development of synchronized applications utilizing Sun's Glassfish Mobility Platform. The Sun Glassfish Mobility Platform is the only open platform to deliver a complete solution for data synchronization to any smartphone. Smartphones have become an increasingly popular extension to PC-based applications, both for consumers and business users.

As a senior software architect at ITDistributors, I built a proof of concept of how the Sun GlassFish Mobility Platform can synchronize data from a cloud computing service, ITDistributors developed a mobile Twitter client by using the LWUIT api's and where all data transmissions are provided by the Sun GlassFish Mobility Platform. It's important to note that although there are other network centric Twitter mobile clients available, you'll find their functionality limited since they are not using a synchronized technology. Example, any personal preferences such as changing your e-mail address or location is not done on other Twitter clients. Although it's not terribly important that these personal Twitter settings be changed on the mobile device, the point of this demo is to to emphasize that regardless what changes are made either from an Internet browser or your mobile smartphone, both environments are alway synchronized with the same data. We believe synchronized functionality becomes increasingly important and valuable when more complex cloud computing services come into play.

The main objective in choosing Twitter is to prove that SGMP connector can call RESTful Web Services.
The connector architecture is show in the following figure:

The connector uses the Twitter SaaS operations, obtained using Netbeans IDE-Web Service Manager, to call the Twitter functionality exposed via API that confirms to the REST architecture.

Connector calls the following Twitter APIs:

Authentication: http://twitter.com/account/verify_credentials.format
Friends Tweets: http://twitter.com/statuses/friends_timeline.format
Status Update: http://twitter.com/statuses/update.format
Profile Update: http://twitter.com/account/update_profile.format
Delivery Device Update: http://twitter.com/account/update_delivery_device.format
End Session: http://twitter.com/account/end_session.format

There is a one-to-one correspondence between api and methods used by connector. The following method’s code snippets show getting and posting the data from and to the Twitter account

public static RestResponse verifyCredentials(String format, String credentials) throws IOException {

String[][] pathParams = new String[][]{{"{format}", format}};

String[][] queryParams = new String[][]{};

RestConnection conn = new RestConnection("http://twitter.com/account/verify_credentials.{format}", pathParams, queryParams);

sleep(1000);

String[][] httpHeaders = new String[][]{{"authorization", credentials}};

return conn.get(httpHeaders);

}

o public static RestResponse updateStatus(String status, String inReplyToStatusId, String format, String credentials) throws IOException {

String[][] pathParams = new String[][]{{"{format}", format}};

String[][] queryParams = new String[][]{{"status", status}, {"in_reply_to_status_id", inReplyToStatusId}};

RestConnection conn = new RestConnection("http://twitter.com/statuses/update.{format}", pathParams, null);

sleep(1000);

String[][] httpHeaders = new String[][]{{"authorization", credentials}};

return conn.post(httpHeaders, queryParams);

}

All the above Twitter API methods require authentication; connector uses HTTP Basic Authentication. When authenticating via Basic Auth, user’s registered username/email address and password are used. All responses are relative to the context of the authenticating user. Hence, each method that calls twitter api sends encoded user/password as part of basic authentication.

String credentials = BasicAuth.encode(loginName, password);

Connector is developed and deployed using MEP Connector Archetype (RAR) template. It basically uses 5 template classes comprising business logic and few helper classes.
Business Object uses the following attributes that correspond to the Twitter’s personal account information.

private String userName; //login name or screen name

private String encodedUsrPswd; // BasicAuth.encode(loginName, password)

private String location;

private String deviceDeliveryType;

private String statusMsg;

private String operationType; //determines the method to be invoked

private String realName; //name

private String email;

private String url;

private String description;

private String message;

private String time;

private String userId;

private String profileImage;

The functionality has been divided under two categories: one for getting the data from twitter and other for posting the data to the twitter.

Getting data: verifyCredentials and getFriendsTimeline methods accomplish this task.

BusinessObjectProvider’s initialize() method calls verifyCredentials method. The sample code snippet as follows:

SessionContext sessionContext = getSessionContext();

String credentials = sessionContext.getPassword();

//basically password is formed at the client by calling //BasicAuth.encode(loginName, password);

verifyCredentials("xml", credentials);

BusinessObjectProvider’s getBusinessObjects() method calls getFriendsTimeline method.

Posting data: updateStatus, updateProfile, updateDeliveryDevice and endSession methods accomplish this task. InsertCommand’s execute method calls these methods based on the operation selected by the user at the client. For example updateProfile method is called in the following way:

updateProfile(

realName, email, url, location, description, format, encodedUsrPswd);

Twitter application allows multiple users to login to their personal Twitter accounts using client. As part of this requirement, file names are made unique by having the user’s login name as part of the file name.

CLIENT

Twitter Client has the following functionalities:

Login form: This has username, password and server url fields. During sync operation, client saves the username, password, url and encoded userpswd in the record store. It syncs with the server by using encoded userpswd, which would be sufficient to authenticate with twitter apis, in the setCredentials method. As soon as the user opens the app, user sees this form for the initial login.

Tweets form: This displays the latest tweets. During sync operation, client calls BusinessObjectStorage’s listBusinessObjectNames() method to get the filenames of tweets objects comprising tweets information such as friend’s real profile image, screen name, message and time.

Settings form: This displays user’s personal information such as real name, email, url, description, location and device delivery type. Settings object is part of Tweets objects, which are formed at the server during sync operation. User can change the personal information and sync with twitter account. During sync operation, client creates a new BusinessObject comprising the changed information along with setting operation info and writes the object by calling BusinessObjectStorage’s writeBusinessObject method.

Update form: This has “what are you doing?” field. User can add the text and sync with twitter account. During sync operation, client creates a new BusinessObject comprising the added information along with update operation info and writes the object by calling BusinessObjectStorage’s writeBusinessObject method.
Logout option: User can opt to logout if user decides to login to a different twitter account. Client deletes the cached business object files and record store containing credential information. During sync operation, client creates a new BusinessObject comprising the logout operation info and writes the object by calling BusinessObjectStorage’s writeBusinessObject method.

Sun GlassFish Mobility Platform Development

Synchronizing Twitter data using Sun's GlassFish Mobility Platform