Do it yourself Android

PhoneGap – migrating iOS applications to Android (Part 1)

admin — Fri, 06 Apr 2012 21:18:09 +0000

In this post, I’ll be discussing the steps required to created an Android application using the PhoneGap framework. For those of you who don’t know, PhoneGap is an HTML5 app platform that allows you to author native applications with web technologies. So although we are generating a native Android application (APK file) that can be put on Google Play, the actual views of our application will be made up by web pages, embedded in your native app in a WebView.

PhoneGap promotes the idea of a single code-base (the part containing the html / javascript / stylesheets) where you use the PhoneGap platform to generate native packages for different mobile platforms like iOS, Android, …… There will always be a mobile platform specific part associated with a PhoneGap project, the native part, required to generate the mobile platform specific artifact (Android APK file, iOS IPA file,….)

The applications

Writing a fully featured cross platform app is beyond the scope of this particular blog post. Depending on the complexity of the app, and the target platforms that need to be supported, developing such an application can be very complex. In this blog post I will pick 2 very simple mobile webapps that were packaged using PhoneGap as native iOS applications. I’ll try to get a feel on the effort required to port them to the Android platform.

The idea behind this approach is to see how easy it is to have a truly cross-platform application with PhoneGap. After all, PhoneGap uses standard and common web technologies like html5 / css3 / jquery so it shouldn’t be that hard right ?

The holy grail of development, where you “write once” and “run anywhere”.

Unfortunately things aren’t always as simple as that. From my own personal experience, it has been always been more along the lines of “write once”, “try to run anywhere”, “tweak your writings to get it to run anywhere”.

I’ll be using 2 PhoneGap applications that were originally targetting iOS, and see what it takes to convert them to Android.

Room112 is a sample application created by Jesse Freeman, outlined in his excellent blog post entitled “Room112 – PhoneGap Exploration”. The full source code of the sample app created in his blog post can be found on github. Jesse created his application for iOS specifically, so we’ll now start porting it to Android.
The second sample is an Employee Directory application using using the PhoneGap Database API. It is created by Christophe Coenraets. Please checkout his blog for a lot of interesting posts on app development using web techniques.

The source for this sample is still a work in progress, but you can already grab a copy on the PhoneGapAndroidConversion GitHub repository.

The development environment

I’m going to be using Eclipse as my IDE. There are no PhoneGap specific plugins to install, but we obviously require the Android SDK and the ADT plugin to be installed to facilitate Android development.

I’m adding all the steps that are required to setup a new PhoneGap Android Project. You can also clone my skeleton project for PhoneGap Android if you don’t wan to perform the manual steps below. It sets up a basic PhoneGap skeleton project for Android with a simple webview.

We’ll start by creating a standard Android Project.

We’ll be targeting the Android 4.0 platform (API level 14). This will allow us to configure hardwareAcceleration on the platforms that support it.

Hardware acceleration

In order to ensure that our application runs as smoothly as possible on Android, we’ll need to enable hardware acceleration where supported. The way hardware acceleration is enabled depends on the Android version you are running.

In Android 3.0 (Honeycomb API level 11) developers can choose to opt-in to the new hardware accelerated pipeline. It’s not enabled by default.
In Android 4.0 (API level 14), hardware acceleration is enabled by default for all applications

For applications running on lower API levels, you can turn it on by adding android:hardwareAccelerated=”true” to the tag in your AndroidManifest.xml.




    
	

    
....

As we want to target as many devices as possible (including pre-Honeycomb devices) while still make use of the new hardwareAcceleration option, we’re going to set the targetSDK to level 14, and a minSdkVersion to 7 (Android 2.1).

The PhoneGap activity

We’ll let the Android Project wizard generate a default activity, so we already have that in place.

PhoneGap has an excellent Getting Started Guide where the different steps for the different mobile platforms are outlined. In case of Android, the following simple steps need to be executed.

Download PhoneGap from the PhoneGap website (direct link)
Extract the PhoneGap zip file somewhere on your filesystem.
Create an /assets/www folder in your Android project
Create a /libs in your Android project
Copy cordova-1.x.x.js from your android directory of your PhoneGap download earlier to /assets/www
Copy cordova-1.x.x.jar from your android directory of your PhoneGap download earlier to /libs
Copy xml folder from your PhoneGap download earlier to /res

For those that like to script this, just fill in the correct location of your eclipse project and phonegap download and execute the commands below :

export ECLIPSE_PROJECT=/Users/ddewaele/Projects/workspace/Room12PhoneGapAndroid
export PHONEGAP_DOWNLOAD=/Users/ddewaele/Projects/PhoneGap/phonegap-phonegap-de1960d
mkdir $ECLIPSE_PROJECT/assets/www
mkdir $ECLIPSE_PROJECT/libs
cp  $PHONEGAP_DOWNLOAD/lib/android/cordova-1.5.0.js $ECLIPSE_PROJECT/assets/www/
cp  $PHONEGAP_DOWNLOAD/lib/android/cordova-1.5.0.jar $ECLIPSE_PROJECT/libs/
cp -r $PHONEGAP_DOWNLOAD/lib/android/xml $ECLIPSE_PROJECT/res/

We’ll need to add the cordova-1.5.0.jar file to the build path of our Android project.

With that into place, our app looks like this :

Attaching the sources

If you want to get serious with PhoneGap development, having the PhoneGap sources attached to your project can help speed up debugging issues. The PhoneGap source code is made available through Apache.

This sample is available in Github with all the libraries and sources properly setup. If you’re using the sample from the git repository there is no need to execute the steps below. I’ve just added them here for informational purposes.

We start by cloning the git repository containing the PhoneGap source code :

git clone https://git-wip-us.apache.org/repos/asf/incubator-cordova-android.git

Cloning into incubator-cordova-android...
remote: Counting objects: 10357, done.
remote: Compressing objects: 100% (3032/3032), done.
remote: Total 10357 (delta 5819), reused 9451 (delta 5299)
Receiving objects: 100% (10357/10357), 19.32 MiB | 243 KiB/s, done.
Resolving deltas: 100% (5819/5819), done.
Davys-MacBook-Air:PhoneGap ddewaele$ ls -ltr
total 0

We then continue to switch to the current production tag, 1.5.0 :


cd incubator-cordova-android
git checkout tags/1.5.0
Note: checking out 'tags/1.5.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 8923e52... Adding support for legacy plugins

Now that we’ve checked out the code, we can zip up the PhoneGap sources (located in framework/src) in a file called cordova-src.zip

cd /Users/ddewaele/Projects/PhoneGap/incubator-cordova-android/framework/src
zip cordova-1.5.0-src.jar -r *

We’ll now attach this source file into our Eclipse project :

Starting the Room112 migration

We’ll start by checking out the original sources of the Room112 application. The sources are located in Github and can be checked out from the command line like this:

git clone https://github.com/jessefreeman/Room112

If you have XCode installed, you can click on the xcodeproj file and open the project in XCode. After launching it on the iPhone simulator, you should see something like this :

The bulk of this git repository contains XCode specific files, files we’re not interested in. We’re only interested in the web files, located in the www folder. There are however a couple of things we need to take into account :

The Room112 iOS sample uses PhoneGap v1.3.0, while we are going to use the latest version available at the time of writing, v1.5.0.
We’ve stumbled upon our first issue that prevents us from making this example truly cross-platform. The Room112 iOS code contains an iOS specific phonegap-1.3.0.js file that cannot be used on Android.
The Android specific phonegap javascript file (called cordova-1.5.0.js) is located in the PhoneGap distribution we downloaded earlier. It is also available in my skeleton Github repo.

The JSON bug

When we attempt to start the application for the first time on an Android 2.3.3 device, we are presented with the following screen :

Besides the fact that the background image is not correctly aligned, the major issue here is that our app crashes, failing to show the hotel card.

When we look at the Webconsole logs we see this :

04-02 22:11:15.066: E/Web Console(13752): Uncaught illegal access at file:///android_asset/www/js/lawnchair-0.6.1.min.js:8

The Room12 application uses a framework called Lawnchair as a replacement for html5 local storage. It promotes itself as being a lightweight, adaptive, simple and elegant persistence solution.

Unfortunately on our Android device, this is causing some problems. It’s not a problem with the framework as such, but rather related to a bug in the V8 JavaScript engine of the browser (WebView). The bug described in the Android issue tracker..

Certain Android devices are having issues when a JSON.parse(null) call is executed. Instead of returning null, as most devices do, we are confronted with an uncaught illegal access in the JSON object.

We can workaround this issue by putting the following code on top of our javascript :

JSON.originalParse = JSON.parse;

JSON.parse = function(text){
	if (text) {
		return JSON.originalParse(text);
	} else {
		// no longer crashing on null value but just returning null
		return null;
	}
}

Viewport properties

On my Android 4.0.4 device, I noticed the following errors in the Web Console when launching the app. It seems that hte preferred way of seperating viewport arguments is a “comma”. More information on this can be found in the CSS Device Adaptation.

04-03 00:30:51.265: E/Web Console(21509): Viewport argument value "device-width;" for key "width" not recognized. Content ignored. at file:///android_asset/www/index.html:5
04-03 00:30:51.265: V/Web Console(21509): Viewport argument value "1.0;" for key "initial-scale" was truncated to its numeric prefix. at file:///android_asset/www/index.html:5
04-03 00:30:51.265: V/Web Console(21509): Viewport argument value "0;" for key "user-scalable" was truncated to its numeric prefix. at file:///android_asset/www/index.html:5

Android Room112 screenshots

The Room112 application was specifically designed for the iPhone and the nature of the app makes it ao that it doesn’t render well on different screen resolutions.

By providing additional image resources we could optimizing the application for larger type screens. (although we won’t be covering that here.)

Samsung Galaxy S running Gingerbread 2.3.3

Samsung Galaxy Nexus running ICS 4.0.4

Samsung Galaxy Mini running Gingerbread 2.3.4

Asus TF101 Transformer running ICS 4.0.3

Starting the Employee Directory migration

The original Employee Directory source code is available here. The zip file only contains the www folder so you’ll need to create a new PhoneGap project in XCode, build it, setup the www folder, and replace the content of that www folder with the content found in the Employee Directory download. When launching it in the iPhone simulator, you should see something like this :

QueryString errors

In the Employee Directory sample, query strings are used to pass the ID of the selected employee to the detail page. This causes a problem on Android version 3.0 and up. The following error is being shown when we load up a page containing a query string.
The problem is described in this Android issue. The issue is fixed but marked for a “Future version”. We can only hope that it becomes available in the next Android point release (4.0.5) so that we can all benefit from fixes like that.

Using local storage as a workaround

As a quick workaround, we can try to use HTML5 local storage to pass data around instead of using query strings.

My initial workaround involved something like this when clicking on an employee :

function loadEmployeeDetail(id) {
	localStorage.setItem( "employeeId", id );
	location.href="employeedetails.html";
}

Unfortunately this doesn’t work, as it generated JSCallback errors on Android, again due to an Android issue.

04-04 22:20:53.379: I/Web Console(1523): JSCallback Error: Request failed. at :1194134965

In an effort to fix the error above, and as indicated by PhoneGap, a fix involved using the navigator.app object to load a URL (instead of using the location.href) :

function loadEmployeeDetail(id) {
	localStorage.setItem( "employeeId", id );
	//location.href="employeedetails.html"; // this doesn't work on Android (see )
	navigator.app.loadUrl("file:///android_asset/www/employeedirectory/employeedetails.html");
}

Although this fixed my problem on Android, it broke the iOS implementation.

Phonegap exposes a “device” object that we can use to detect the platform that we’re running on. In an ideal cross-platform-one-codebase world we wouldn’t be needing this, but in reality, you’ll need it whenever you want to do something specific for a particular platform.

A more robust way of handling the query string issue would be to use a different approach altogether, using a REST-style URL approach where employee details are fetched using employeedetails/1 instead of employeedetails.html?id=1. However, this would have a more fundamental impact on the original application and those changes are out of scope for this article. It just goes to show that what seems trivial at first (passing parameters from one page to another) can cause a lof of headaches when moving to different platforms.

Android Employee Directory screenshots

The Employee Directory renders correctly on all Android devices. Obviously, it is not optimized for tablet usage (lots of white space) as is the case with most of the mobile apps I’ve seen using web technologies.

Creating tablet optimized versions obviously requires additional work, as it involves developing different screens for different sizes. This is however also the case for native applications. Although it would be interesting to see how this should be tackled for a mobile app created with web technologies, it would require a dedicate article on its own.

Samsung Galaxy Nexus running ICS 4.0.4

Samsung Galaxy S running Gingerbread 2.3.3

Samsung Galaxy Mini running Gingerbread 2.3.4

Asus TF101 Transformer running ICS 4.0.3

Android point upgrades

A couple of weeks ago, while my phone was still running Android ICS 4.0.2, I posted on G+ that 2 featured cross-platform apps (Diary Mobile created using PhoneGap and GetoGrapher created using Sencha Touch) looked like stretched out iPhone apps.

Much to my surprise I noticed that after Android ICS 4.0.4 was rolled out to my phone, these apps started to look “normal” again, as can be screen in the screenshots below (granted, they still look like iPhone apps) :

This just goes to show that there can be a major impact on how your app looks and behaves, even between these maintenance point releases.

Hardware acceleration

I already talked a bit about hardware acceleration on Android, and how it can speed up animations. The Room 112 application uses an animation to slide the hotel room card onto the screen. With hardware acceleration disabled, the animation is horribly slow. Especially on ICS. Even Gingerbread (that has no hardware acceleration enabled) was faster than ICS. It wasn’t as smooth as on the iPhone, but acceptable. Only when we enabled hardware acceleration on ICS did we get the same level of performance as on the iPhone.

As we’ve already seen, hardware acceleration can be enabled/disabled on the application level (application tag in the manifest xml), as well as on the activity level. This is a good thing, as it allows you to tweak the settings right to the activity detail.

The Employee Directory uses an iScroll library in the employee list screen for enhanced scrolling on iOS. It seems that the iScroll library performs a lot slower when hardware acceleration enabled. In order to get a smooth result we had to run that screen without hardware acceleration. In that respect it’s nice to be able to disable hardware acceleration on the activity that is hosting that particular screen.

Conclusions

These trivial sample apps show that it is not that straightforward to create a cross-platform app using a single codebase. Each platform (and different versions of the same platform) behave differently and often require their own dedicated tweaks and fixes. Although the scope of this first part was just to get a very basic version of these apps up and running on Android, we already stumbled upon several issues like :

Webview javascript engine issues – JSON.parse(null)
QueryString handling not working
Hardware acceleration tweaks

Keep in mind that this was a very limited exercise using relatively simple applications, where we didn’t take into account platform look and feel and proper CSS styling for multiple screen resolutions

It seems to be very difficult to find real-world examples of such multi-platform apps that follow good design, are feature-rich and are truly multi-platform. Out of the 7 featured apps on PhoneGap, only 2 run on both Android and iOS. The rest is targeting a single platform. The ones that are truly multi platform don’t run all that great. The ones that do work are usually very simple apps that could have just as well been mobile websites.

After spending some time looking and using those multi-platform frameworks, I’m not convinced yet. If you really want to deliver a high quality experience on multiple platforms, the effort required to get it right using web technologies cannot be under-estimated.

We are already seeing companies moving away from this approach and rewriting their apps in a native way.

On the other hand, one cannot argue the fact that web technologies like html5 / css3 are becoming increasingly important and they cannot be overlooked. They do provide several advantages over doing things natively and maintaining different code-bases. If your application is relatively simple, and you don’t care about platform look and feel affinity, they are definitely an option. For those type of applications it will be cheaper / easier to develop something using these technologies.

In a follow-up post, I’ll try to tackle the following topics :

the various CSS related issues that you need to take into account when working with multiple screen resolutions
how to organize your SCM for cross platform projects
use some of the PhoneGap APIs to access the device capabilities, and see how they translate in a multi-platform setup

References

Inspiration for this article

Sources

Hardware acceleration

Tools

Misc libraries / frameworks used in the samples

Android issues

30 minute guide to integrating Foursquare in your Android application

ddewaele — Mon, 05 Sep 2011 22:36:35 +0000

In this article, I’m going to show you how you can use Foursquare in your Android application using OAuth 2.0.

We’ll be using

the foursquare-api-java to do the actual Foursquare calls.
the Google APIs Client Library for Java to help us out with the OAuth 2.0 flow

I’ve decided to use the foursquare-api-java, a project hosted at Google Code, as it offers a rich interface to interact with Foursquare. The same API calls are possible through the Google API client for Java, but it would require you to write your own model classes to do the JSON to Java translation.
I will post some sample code here on how this can be done with the Google APIs client library for java.

In the sample application hosted at Github, we’re going to display a map where the user can select a location. Upon selecting a location, we’ll load up a list of Foursquare venues that the user can select.
Upon selecting a venue, we’ll return to our map, put a marker on the map representing the venue, and allow the user to perform a checkin.

The sample application

All dependencies are included in the lib folder of the project, so after doing a checkout of Github, you should have no problem

checking out everything from Git
importing the project in Eclipse and run it from there.
change your Oauth2 properties
run the project on your emulator or phone

This is by no means a complete production ready sample. The goal of the sample is to show you how to do the OAuth2 flow, retrieve an access token, and make some API calls.
The Oauth2 properties are defined in the OAuth2ClientCredentials class,
You’ll need to register a new OAuth2 consumer on the Foursquare website (Foursquare Application Registration), where you need to provide

an application name (ex: AndroidFSSample)
an application website (ex: http://localhost:8888)
a callback URL (ex: http://localhost:8888)

After registration, you should see something like this:

Our main Foursquare activity

Our main activity will allow the user to authorize against foursquare. It shows 2 buttons allowing to user to start the authorization process, and another button to clear the access tokens received from Foursquare.

/**
 * Launch the OAuth flow to get an access token required to do authorized API calls.
 * When the OAuth flow finishes, we redirect to this Activity to perform the API call.
 */
Button launchOauth = (Button) findViewById(R.id.btn_launch_oauth);
launchOauth.setOnClickListener(new View.OnClickListener() {
	public void onClick(View v) {
		startActivity(new Intent().setClass(v.getContext(),OAuthAccessTokenActivity.class));
	}
});

/**
 * Clearing the credentials and performing an API call to see the unauthorized message.
 */
Button clearCredentials = (Button) findViewById(R.id.btn_clear_credentials);
clearCredentials.setOnClickListener(new View.OnClickListener() {
	public void onClick(View v) {
		clearCredentials();
		new PerformApiCallTask().execute();
	}

});

The OAuth2 flow

The project will use the Google API Java client to do the Foursquare OAuth2.0 flow. We’ll start by defining the activity that will allows us to retrieve an OAuth 2.0 access token. It’s a simple activity that is dedicated for this task.

This activity doesn’t come with its own layout file, but rather embeds a WebView component programmatically. We’ll be using the WebView component to launch the Foursquare authorization URL, where we’ll need to login, and authorize the application access to our Foursquare data.
We enable javascript on the webview component, set it to visible (more on that later), and set it to the ContentView.

	@Override
	protected void onResume() {
		super.onResume();
		WebView webview = new WebView(this);
        webview.getSettings().setJavaScriptEnabled(true);
        webview.setVisibility(View.VISIBLE);
        setContentView(webview);

You’ll notice that there a lot of code between the snippet above and the code that actually launches the authorization URL, but more on that later.
In order to retrieve an access token, we need to redirect the user to the Foursquare authorization URL (More info can be found on https://developer.foursquare.com/docs/oauth.html).
We build up an AuthorizationRequestUrl object (part of Google APIs client library for Java), pass on the Client ID and the Redirection URI (=callback) as defined when registering our consumer, and we launch the URL.

AuthorizationRequestUrl authorizationRequestUrl = new AuthorizationRequestUrl(OAuth2ClientCredentials.AUTHORIZATION_URL);
authorizationRequestUrl.clientId = OAuth2ClientCredentials.CLIENT_ID;
authorizationRequestUrl.redirectUri = OAuth2ClientCredentials.REDIRECT_URI;
webview.loadUrl(authorizationRequestUrl.build());

The snippet above will pop the following screen:
When pressing the login button, you can login with your Foursquare credentials

And after that, you should see the following screen (the fact that you now see a map instead of the error message means you’ve authenticated successfully to Foursquare. :

For those of you that looked at Oauth 2.0 flow in Android article, you might recall we used the following code to build up an authorization URL for the Latitude API

String authorizationUrl = new GoogleAuthorizationRequestUrl(OAuth2ClientCredentials.CLIENT_ID, OAuth2ClientCredentials.OAUTH_CALLBACK_URL, OAuth2ClientCredentials.SCOPE).build();

The Google APIs client library for Java offers ready made Google specific OAuth2 classes. Obviously, it doesn’t offer those for APIs such as Twitter,Foursquare,Gowalla or Facebook, but it does offer the base classes (AuthorizationRequestUrl) that you can use to construct the same authorization URL.

The code that’s sitting in between the 2 snippets is what will allow us to intercept the access token that is provided by Foursquare once you hit the authorize button in the embedded
browser. The OAuth2.0 flow used here is a web based flow that does the following:

redirects the user to Foursquare
allows the user to login using the Foursquare login page (meaning no password is captured by the browser)
allows foursquare to check your credentials and present you with an auhorization screen.
On this screen, you can allow this application access to your Foursquare data, or deny access.
If you decide to grant access, foursquare redirects to another page referred to as a callback URL, containing a token that allows this application to access your data.

We need to be able to intercept this redirect, capture the token, and store it on the phone so we can begin interacting with Foursquare.

Retrieving the access token is illustrated by the following code. Using the WebView component, we intercept the redirect, check if there is a token in the URL,
and if so, continue our processing.

@Override
public void onPageFinished(WebView view, String url)  {
	if (url.startsWith(OAuth2ClientCredentials.REDIRECT_URI)) {
	            		try {
	            			if (url.indexOf("code=")!=-1) {
		            			String code = extractCodeFromUrl(url);

Once we’ve retrieved the code from the Foursquare server, we can exchange it for an access token. This is done using the following code:

AuthorizationCodeGrant request = new AuthorizationCodeGrant(new NetHttpTransport(),
        new JacksonFactory(),
        OAuth2ClientCredentials.ACCESS_TOKEN_URL,
        OAuth2ClientCredentials.CLIENT_ID,
        OAuth2ClientCredentials.CLIENT_SECRET,
        code,
        OAuth2ClientCredentials.REDIRECT_URI);
AccessTokenResponse accessTokenResponse = request.execute();

CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
credentialStore.write(accessTokenResponse );

For those who looked at my Oauth 2.0 flow in Android article, you’ll notice that the only difference when dealing with non Google APIs is that we use the AuthorizationCodeGrant class instead of the Google specific GoogleAuthorizationCodeGrant. Other than that, the code is pretty much identical. I’ve put the Google specific code here for reference:

  AccessTokenResponse accessTokenResponse = new GoogleAuthorizationCodeGrant(new NetHttpTransport(),
			      new JacksonFactory(),
			      OAuth2ClientCredentials.CLIENT_ID,
			      OAuth2ClientCredentials.CLIENT_SECRET,
			      code,
			      OAuth2ClientCredentials.REDIRECT_URI).execute();

  CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
  credentialStore.write(accessTokenResponse);

We store the access token in a credential store (the shared preferences of our application).
Now that the app has an access token, we can launch our main activity and start interacting with Foursquare.

When our main activity is launched initially, and the user has properly authorized our app to use its Foursquare data using the flow above, the user will be presented with a map.
When the user clicks on the map, he’ll be presented with a list of places that we fetched from Foursquare.

The clickable map

For those of you who want more info on howto setup an Android project with the MapView component, I suggest you have a look at Using Google Maps in your Android Application.

We’re using the following overlay to allow the user to tap on the map :

private class HelloItemizedOverlay extends ItemizedOverlay
{

	/**
	 * Calling populate here to avoid a nullpointerexception.
	 *
	 * @param defaultMarker
	 */
	public HelloItemizedOverlay(Drawable defaultMarker) {
		  super(boundCenterBottom(defaultMarker));
		  populate();
	}

	public void addOverlay(OverlayItem overlay) {
	    mOverlays.add(overlay);
	    populate();
	}

	@Override
	protected OverlayItem createItem(int i) {
	  return mOverlays.get(i);
	}

	@Override
	public int size() {
	  return mOverlays.size();
	}

	/**
	 *
	 * Triggered when the user clicks on the map.
	 *
	 */
	@Override
	public boolean onTap(GeoPoint p, MapView mapView) {
		HelloItemizedOverlay itemizedoverlay = (HelloItemizedOverlay) mapView.getOverlays().get(0);
        OverlayItem overlayitem = new OverlayItem(p, "Location at " + "title","snippet");
        itemizedoverlay.addOverlay(overlayitem);
        mapView.invalidate();
		popFoursquareVenueList(p.getLatitudeE6()/1E6,p.getLongitudeE6()/1E6);
		return true;
	}

}

As you can see, when tapping on the map, we put a marker on the map through the HelloItemizedOverlay, and pop the FoursquareVenueList Activity.
We launch the venues list screen by passing on the coordinates of the map that the user clicked on.

private void popFoursquareVenueList(double lat,double lng) {
	Intent intent = new Intent(getApplicationContext(),FourSquarePlacesList.class);
	intent.putExtra(Constants.PLACE_LAT_FIELD, lat);
	intent.putExtra(Constants.PLACE_LNG_FIELD,lng);
	startActivity(intent);
}

The FoursquareVenuesList activaty shows the Foursquare venues in a list like this

The FoursquareVenueList

Our FoursquareVenueList Activity extends ListActivity, as we are going to show the venues in a ListView. The ListActivity provides us with the basic infrastructure
to setup the list, and handle the item selection in the list.

The layout looks like this:

We retrieve the latitude/longitude that was passed on from the previous screen.

	if (getIntent().getExtras() != null) {
		lat = getIntent().getExtras().getDouble(Constants.PLACE_LAT_FIELD);
		lng = getIntent().getExtras().getDouble(Constants.PLACE_LNG_FIELD);
	}

We’re using the following asynctask to fetch the places and populate the list.

private class PlacesListRefresher extends AsyncTask {

	@Override
	protected Void doInBackground(Uri... params) {

		try {
			Log.i(Constants.TAG, "Retrieving places at " + lat + "," + lng);
			Result venues = getFoursquareApi().venuesSearch(
					lat + "," + lng, null, null, null, null, null, null,
					null, null, null, null);
			CompactVenue[] compactVenues = venues.getResult().getVenues();
			Log.i(Constants.TAG, "found " + compactVenues.length
					+ " places");
			for (CompactVenue compactVenue : compactVenues) {
				veneusMap.add(compactVenue);
			}
		} catch (Exception ex) {
			Log.e(Constants.TAG, "Error retrieving venues", ex);
		}
		return null;
	}

	@Override
	protected void onPostExecute(Void result) {
		setListAdapter(new FoursquareTableAdapter(veneusMap));
	}

}

Accessing the foursquare API

As you can see, we fire up the Foursquare API and do a venuesSearch, by passing on the latitude and longitude we retrieved in the previous step.
We loop over the venues array and store it in a map. All of this is happening in a background thread. When the background thread finished, we setup our listAdapter in order to display the results in the ListView.

The getFoursquareApi() method is implemented like this:

public FoursquareApi getFoursquareApi() {
	if (this.foursquareApi==null) {
		this.prefs = PreferenceManager.getDefaultSharedPreferences(getApplicationContext());
		CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);

		AccessTokenResponse accessTokenResponse = credentialStore.read();
		this.foursquareApi = new FoursquareApi(OAuth2ClientCredentials.CLIENT_ID,
				OAuth2ClientCredentials.CLIENT_SECRET,
				OAuth2ClientCredentials.REDIRECT_URI,
				accessTokenResponse.accessToken, new DefaultIOHandler());
	}
	return this.foursquareApi;

}

It fetches the accessToken from our CredentialStore, and initialized the FoursquareApi object that we use to fetch the venues.

Using Google APIs client for Java for the Foursquare API calls

You may have noticed that for making the actual API calls, we’re not using the Google APIs client libraries for Java, but instead are relying on a third-party client library. That’s one model of working, and an appropriate one if a rich third party client library like Foursquare API for Java is available. It integrates very nicely with Google APIs client for Java as we pass on the access token we retrieved from Google APIs client for Java to the Foursquare API for Java. As Google APIs client for Java is really good at handling the OAuth2 stuff, and the Foursquare API for Java is really good at doing the Foursquare stuff, this is a model that works.

This does not mean that we can’t use the Google APIs client libraries for Java to access the Foursquare REST endpoints. In the sample project, I’ve created a method called performFoursquareApiCallUsingGoogleApiJavaClient that shows 2 ways of using the Google APIs client libraries for Java to access the Foursquare REST endpoints. Let’s go over them.

Fetching the response as a String, and transforming it into JSON

One way of interacting with the Foursquare endpoint is to interpret the response as a String (parseAsString()), and convert it into some standard JSON structures. That way, you can get a hold of the data in a generic way.

	public void performFoursquareApiCallUsingGoogleApiJavaClient() throws Exception {
		AccessTokenResponse accessTokenResponse = credentialStore.read();
		HttpTransport transport = new NetHttpTransport();
		GenericUrl genericUrl = new GenericUrl(FOURSQUARE_API_ENDPOINT);
		genericUrl.put("ll",lat + "," + lng);
		HttpRequest httpRequest = createApiRequestFactory(transport, accessTokenResponse.accessToken).buildGetRequest(
				genericUrl);
		HttpResponse httpResponse = httpRequest.execute();
		JSONObject object = new JSONObject(httpResponse.parseAsString());
		JSONObject fourSquareResponse = (JSONObject) object.get("response");
		JSONArray groups = (JSONArray) fourSquareResponse.get("groups");
		JSONObject group = (JSONObject)groups.get(0);
		JSONArray items = (JSONArray)group.get("items");
		Log.i(Constants.TAG, "Found venues " + items);

The example above shows you how to traverse the JSON structure using standard JSONArray and JSONObject objects.

Have Google APIs client library for Java transform the response into a java model.

Another approach is to create your own model classes, and let the Google APIs client for Java to the transformation of the JSON string into your Java model. The example below illustrates just that. Note how we don’t parse the response as a String, but rather parse the response into a FoursquareResponse.class.

		httpRequest = createApiRequestFactory(transport, accessTokenResponse.accessToken).buildGetRequest(
				genericUrl);
		JsonHttpParser parser = new JsonHttpParser();
	    parser.jsonFactory = new JacksonFactory();
	    httpRequest.addParser(parser);
		httpResponse = httpRequest.execute();
		FoursquareResponse foursquareResponse2 = httpResponse.parseAs(FoursquareResponse.class);
		Venue[] venues = foursquareResponse2.response.groups[0].items;
		Log.i(Constants.TAG, "Found venues " + venues);

	}

The FoursquareResponse.class looks like this


public class FoursquareResponse implements Serializable {
	private static final long serialVersionUID = -383365244692781213L;

	@Key
	public Response response;
}

The Response class like this:

public class Response  implements Serializable {
	private static final long serialVersionUID = -8744243204974447941L;

	@Key
	public Group[] groups;
}

You get the picture….. This way, you get to work with a much richer interface. Instead of working with low level generic JSON objects, you now have a rich java based data model that you can use in your app. You no longer need to know the internal JSON structure, you just need to read the java model to get the data you want.

I opted for the third party library because there was one available for Foursquare in Java. If no API was available, I would have gone for this approach.

We’ve created a FoursquareTableAdapter that acts as a data adapter for the ListView component.

class FoursquareTableAdapter extends ArrayAdapter {
	FoursquareTableAdapter(List list) {
		super(FoursquareVenueList.this, R.layout.places_list_row, list);
	}

	public View getView(int position, View convertView, ViewGroup parent) {
		ViewHolder holder = null;
		if (convertView == null) {
			convertView = getLayoutInflater().inflate(R.layout.places_list_row, parent, false);
			holder = new ViewHolder();
			holder.txtPlaceName = (TextView) convertView.findViewById(R.id.row_placename);
			holder.txtPlaceAddress = (TextView) convertView.findViewById(R.id.row_placeaddress);
			holder.layout = (RelativeLayout) convertView.findViewById(R.id.row_layout);
			convertView.setTag(holder);
		} else {
			holder = (ViewHolder) convertView.getTag();
		}

		CompactVenue venue = getVenueMapFromAdapter(position);

		try {
			holder.txtPlaceName.setText(venue.getName());
			if (venue.getLocation().getAddress() != null && venue.getLocation().getAddress().length() > 0) {
				holder.txtPlaceAddress.setText(venue.getLocation().getAddress());
			} else {
				holder.txtPlaceAddress.setText(R.string.no_address_info_found);
			}
		} catch (Exception ex) {
			ex.printStackTrace();
		}

		return (convertView);
	}
}

The FoursquareTableAdapter is an ArrayAdapter that needs to be inialized with a list of CompactVenue objects. The getView method is responsible for filling up each row in the ListView component.
We use the ViewHolder pattern to optimize performance and memory management. The ViewHolder pattern avoids calling findViewById() when it is not necessary.

We also setup a AdapterView.OnItemClickListener on the ListView that is triggered when the user selects an item form the list.
As you can see here, we retrieve a ference to the current selected venue, wrap up the data in an intent, and startup our previous activity again, only this time
passing on the additional data related to the venue.

getListView().setOnItemClickListener(
	new AdapterView.OnItemClickListener() {

		@Override
		public void onItemClick(AdapterView parent, View view,
				int position, long id) {

			CompactVenue venue = veneusMap.get((int) id);
			Intent intent = new Intent(getApplicationContext(),FoursquareApiSample.class);
			intent.putExtra(Constants.PLACE_ID_FIELD, venue.getId());
			intent.putExtra(Constants.PLACE_LAT_FIELD, venue.getLocation().getLat());
			intent.putExtra(Constants.PLACE_LNG_FIELD, venue.getLocation().getLng());
			intent.putExtra(Constants.PLACE_NAME_FIELD, venue.getName());
			intent.putExtra(Constants.PLACE_ADDRESS_FIELD, venue.getLocation().getAddress());
			startActivity(intent);
		}

	}
);

The initial activity showing the map will pick up the venue data, put a marker on the map where the venue is located, and allow the user to checkin to that venu.

if (getIntent().getExtras()!=null) {
	Double lat = getIntent().getExtras().getDouble(Constants.PLACE_LAT_FIELD);
	Double lng = getIntent().getExtras().getDouble(Constants.PLACE_LNG_FIELD);
	venueAddress = getIntent().getExtras().getString(Constants.PLACE_ADDRESS_FIELD);
	venueName = getIntent().getExtras().getString(Constants.PLACE_NAME_FIELD);
	venueId = getIntent().getExtras().getString(Constants.PLACE_ID_FIELD);
	GeoPoint p = new GeoPoint((int) (lat * 1E6), (int) (lng * 1E6));
	HelloItemizedOverlay venueOverlay = (HelloItemizedOverlay) mapView.getOverlays().get(0);
    OverlayItem overlayitem = new OverlayItem(p, venueName, venueAddress);
    venueOverlay.addOverlay(overlayitem);
    mc.animateTo(p);
    mc.setCenter(p);
    mc.setZoom(16);
    showCheckinSection = true;
    this.checkinSection.setVisibility(View.VISIBLE);
}

You should see the following screen :

The actual checkin is done using again an AsyncTask, making sure that the actual checkin logic occurs in the background (as it involves performing a REST call to Foursquare,
potentially blocking the UI untill Foursquare comes back with a response).

private class CheckinTask extends AsyncTask {

	private String apiStatusMsg;

	@Override
	protected Void doInBackground(Uri...params) {
		try {
			CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
			AccessTokenResponse accessTokenResponse = credentialStore.read();
		    FoursquareApi foursquareApi = new FoursquareApi(OAuth2ClientCredentials.CLIENT_ID, OAuth2ClientCredentials.CLIENT_SECRET, OAuth2ClientCredentials.REDIRECT_URI,accessTokenResponse.accessToken,new DefaultIOHandler());
			Result result = foursquareApi.checkinsAdd(venueId, null, getString(R.string.checkin_msg), null, null,null,null,null);
			if (result.getMeta().getCode()==200) {
				apiStatusMsg = "Checked in to " + venueName;
			} else {
				apiStatusMsg = result.getMeta().getErrorDetail();
			}
		} catch (FoursquareApiException e) {
			e.printStackTrace();
		}
        return null;
	}

	@Override
	protected void onPreExecute() {
	}

	@Override
	protected void onPostExecute(Void result) {
		Toast.makeText(FoursquareApiSample.this, apiStatusMsg, Toast.LENGTH_LONG).show();
	}

}

When the checkin succeeds, you should see a Toast message indicating that the checkin was successful.

You can double-check your Foursquare history to see that the checkin did in fact take place:

Conclusion

As I already showed in my Improved Twitter OAuth for Android post, the Google API client library for Java is well suited to interact with non Google APIs. Where the Twitter post showed you how to use the library with an OAuth 1.0a enabled service provider, this post shows that the Google API client library for Java can also be used to interact with non-Google APIs using Oauth 2.0. It’s strong collection of base OAuth2 objects make it very easy to interact with any OAuth2 enabled service provider. The library is available for a large number of languages (PHP,Python,Objective-C,..).
You can use parts of the API as you see fit. For example here I decided to use the OAuth 2.0 part, but not use the JSON to Java Model mapping as there was already a good Foursquare library available. For REST APIs support Oauth that don’t have any java based library available, it’s well worth the effort to model the API in Java, and let Google APIs Client Library for Java do the transformation for you.
I suggest you check it out at Google APIs Client Library for Java.

References

Latify Android Video Review

admin — Mon, 29 Aug 2011 19:45:38 +0000

Not really a development post, but a video review of Latify (my app for Android). Video review was done by http://hemorrdroids.net. Enjoy….

Improved Twitter OAuth for Android

admin — Mon, 08 Aug 2011 17:16:47 +0000

A couple of months ago, I published a post entitled A 30 minute guide to integrating Twitter in your Android application.. The post presented a sample Android application to integrate Twitter. Using the signpost library, the user was able to authorize our application to send tweets on his/her behalf. It seems that everyone is migrating to Oauth 2.0, but Twitter is still stuck at OAuth 1.0. Nevertheless, I still wanted to update the sample we did a couple of months ago for 3 reasons :

I wanted to show you how to integrate non-google APIs using the Google APIs Client Library for Java.
I wanted to show you a new approach to the Oauth flow (without popping a browser)
I wanted to show you how to do OAuth 1.0 using the Google APIs Client Library for Java.

I’ll start by introducing the application (for those who read the previous article, it should look pretty familiar.

The sample app UI

Granted, the user interface looks pretty basic, but it gets the job done. We’ve got

a Launch OAuth flow button that will take the user through the OAuth flow.
a Clear credentials button, that will remove any authentication tokens stored in the app.
a Label, showing the status of a Twitter API call.

Unauthorized API access

When we start the application for the first itme, you’ll see the following error message :

What you are seeing is the outcome of the Twitter API call. Obviously, in order to perform a Tweet, the user needs to authorize our application to send tweets on his behalf. Failure to do so results in an Authentication error.

The API call is executed when this main activity is launched.

In order to succesfully send a tweet, the user needs to authorize the request.

Authorizing the application

When clicking on the Launch OAuth Flow button, we’ll start the OAuth web based flow. In the previous article, we used Signpost to handle the Oauth flow, and had a pretty complex flow, where we started an activity, launched the browser, started background tasks, and had to deal with onNewIntent calllbacks during the OAuth flow.

On top of that, launching the browser to show the Twitter authorization pages, a scenario where all of a sudden our application lost control and moved control to the browser, is a pretty unnatural flow with a lot of negative side-effects for the user. To name a couple :

The user find himself in a browser environment all of a sudden.
It’s clear he’s no longer in our application.
What if the users decides to go back, or exit the browser app ?
What if the user was browsing some site in his browser, will that page all of a sudden get replaced by our Twitter authorization page ?

In the previous sample, we launched a browser like this :

final String url = provider.retrieveRequestToken(consumer, Constants.OAUTH_CALLBACK_URL);
Log.i(TAG, "Popping a browser with the authorize URL : " + url);
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url)).setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP | Intent.FLAG_ACTIVITY_NO_HISTORY | Intent.FLAG_FROM_BACKGROUND);
context.startActivity(intent);

the Android WebView component

In this sample, we’re not going to pop a full browser, but we’re going to start a regular Android activity, and use the WebView component to launch our authorization page

@Override
protected void onResume() {
	super.onResume();
	WebView webview = new WebView(this);
        webview.getSettings().setJavaScriptEnabled(true);
        webview.setVisibility(View.VISIBLE);
        setContentView(webview);

        final OAuthHmacSigner signer = new OAuthHmacSigner();
        signer.clientSharedSecret = Constants.CONSUMER_SECRET;

	OAuthGetTemporaryToken temporaryToken = new OAuthGetTemporaryToken(Constants.REQUEST_URL);
	temporaryToken.transport = new ApacheHttpTransport();
	temporaryToken.signer = signer;
	temporaryToken.consumerKey = Constants.CONSUMER_KEY;
	temporaryToken.callback = Constants.OAUTH_CALLBACK_URL;

	OAuthCredentialsResponse tempCredentials = temporaryToken.execute();
	signer.tokenSharedSecret = tempCredentials.tokenSecret;

	OAuthAuthorizeTemporaryTokenUrl authorizeUrl = new OAuthAuthorizeTemporaryTokenUrl(Constants.AUTHORIZE_URL);
	authorizeUrl.temporaryToken = tempCredentials.token;
	String authorizationUrl = authorizeUrl.build();

	webview.loadUrl(authorizationUrl);
}

As you can see, a setup a WebView component (taking up the entire activity space), enable javascript (most authorization pages require javascript), and load up the OAuth 1.0 authorization URL in the WebView component.

Before we can start building the authorization URL, we first need to setup our OAuth signer object, request a temporary token, and use that temporary token to put in our authorization URL.

Twitter OAuth constants

All Twitter specific Oauth parameters are defined in a constants file.

	public static final String CONSUMER_KEY = "PUT YOUR TWITTER OAUTH CONSUMER KEY HERE";
	public static final String CONSUMER_SECRET= "PUT YOUR TWITTER OAUTH CONSUMER SECRET HERE";

	public static final String REQUEST_URL = "http://api.twitter.com/oauth/request_token";
	public static final String ACCESS_URL = "http://api.twitter.com/oauth/access_token";
	public static final String AUTHORIZE_URL = "http://api.twitter.com/oauth/authorize";

	public static final String	OAUTH_CALLBACK_URL		= "http://localhost";

What we need are

the OAuth consumer key and secret (can be found on the Twitter dev page for your app)
the 3 OAuth endpoints (request,authorize and access)
a callback URL.

When the authorization URL is launched in the Webview, you should see the following screen (when already logged into Twitter). When not logged in, a page will be shown allowing you to enter your Twitter credentials before moving to this page. Included on the page is some information related to your application (as you’ve defined them on the Twitter dev page), and an authorize button.

When the user hits the authorize button, Twitter will perform a redirect using our callback URL (set to http://localhost)

Intercepting the callback

And here’s where the magic happens. As Twitter redirects to the callback URL, it’s up to our app to intercept this redirect, pick up the 2 OAuth tokens from that callback URL (oauth token and oauth verifier). This authorization (and verifier) token is what we need in order to get an actual OAuth access token that is required to perform the Twitter API call.

Luckily for us, the WebView component allows us to register a WebViewClient, that has an important hook that we’ll implement, the onPageStarted method.

This method is called each time a page is loaded into the WebView. As we’re particulary interested in our callback URI, we’ll only implement our logic when the URL in the WebView matches our Callback URL. When this is the case, we extract the oauth_token en oauth_verifier.

With the oauth_token en oauth_verifier, we can contact Twitter and exchange them for an actual OAuth access token.

As you can see from the code below, we extract both tokens from the callback URL.
We construct an OAuthGetAccessToken object, set the required properties (transport, temp authorization token, verifier token, signer and consumer key) and call it’s execute method to retrieve the actual access token. The access token is embedded in the OAuthCredentialsResponse object.

String requestToken  = extractParamFromUrl(url,"oauth_token");
String verifier= extractParamFromUrl(url,"oauth_verifier");

signer.clientSharedSecret = Constants.CONSUMER_SECRET;

OAuthGetAccessToken accessToken = new OAuthGetAccessToken(Constants.ACCESS_URL);
accessToken.transport = new ApacheHttpTransport();
accessToken.temporaryToken = requestToken;
accessToken.signer = signer;
accessToken.consumerKey = Constants.CONSUMER_KEY;
accessToken.verifier = verifier;

OAuthCredentialsResponse credentials = accessToken.execute();

What we need to do now is store the OAuth access token (and secret) in the shared preferences of our app. I’ve created a simple SharedPreferencesCredentialStore that is capable of reading / writing the 2 tokens from / to the shared preferences.

CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
credentialStore.write(new String[] {credentials.token,credentials.tokenSecret});

Obviously, we don’t have anythiung running on localhost, so in order to avoid the user getting confronted with an HTTP 404 Not Found error in his WebView, we hide the WebView (by setting the visibility to gone).

view.setVisibility(View.INVISIBLE);
startActivity(new Intent(OAuthAccessTokenActivity.this,AndroidTwitterGoogleApiJavaClientActivity.class));

Executing the API

Upon returning to the main activity, with our OAuth access tokens safely stored in the shared preferences, all that’s left to do know is execute the API call. This is done through the following utlity method.

public static void sendTweet(SharedPreferences prefs,String msg) throws Exception {
		String[] tokens = new SharedPreferencesCredentialStore(prefs).read();
		AccessToken a = new AccessToken(tokens[0],tokens[1]);
		Twitter twitter = new TwitterFactory().getInstance();
		twitter.setOAuthConsumer(Constants.CONSUMER_KEY, Constants.CONSUMER_SECRET);
		twitter.setOAuthAccessToken(a);
		twitter.updateStatus(msg);
}

We retrieve the tokens from the shared preferences, use them to construct a Twitter AccessToken (Twitter4J component), and use the Twitter object to send our Tweet. Our main activity will confirm that the tweet has been sent.

To double check, you can always check your Twitter page as well :

Conclusions

I tried to show you a couple of things in this article :

A simplified way of dealing with the Oauth flow
By using a WebView component, we can have more control over the Oauth flow, as it’s kept within the Android Activity lifecycle, without starting external programs. You can opt to run it fullscreen, or embedded in an Activity, providing some additional context to the user.

Using non-Google APIs in conjuction with the google api java client
So far, we’ve only used Google APIs when using the Google APIs Client Library for Java. Here we’ve shown that the OAuth flow was completely handled by the library, right untill the point where we retrieved the access token. After that, control was given to Twitter4J, a Java library for the Twitter API compatible with Android.

References

Oauth 2.0 flow in Android

ddewaele — Sat, 06 Aug 2011 23:10:48 +0000

In this article, I’m going to show you how you can implement an OAuth 2.0 flow in Android.
We’ll be using

the Google Latitude API as a sample Google API (one that has recently received Oauth 2.0 support)
the Google APIs Client Library for Java to help us out with the OAuth 2.0 flow
the Latitude client library to interact with the Latitude API.

In the sample application, we’re going to execute 1 authorized API call to the Latitude API. The call will return the current location of the user.

The sample application

In the sample application, all dependencies are included in the lib folder, so you should be able to checkout everything from Git, import it in your Eclipse IDE, change your Oauth2 properties in the OAuth2ClientCredentials class, and run the project on your emulator or phone.

The project structure should look like this after a succesful checkout / build :

The project depends on the following libraries :

lib/commons-codec-1.3.jar
lib/commons-logging-1.1.1.jar
lib/google-api-client-1.4.1-beta.jar
lib/google-api-client-googleapis-1.4.1-beta.jar
lib/google-api-services-latitude-v1-1.1.0-beta.jar
lib/gson-1.6.jar
lib/guava-r09.jar
lib/httpclient-4.0.3.jar
lib/httpcore-4.0.1.jar
lib/jackson-core-asl-1.6.7.jar

Google API client for Java

Google APIs Client Library for Java makes it very easy to interact with various Google APIs. The library has a set of generated client libraries that hide a lot of the complexities when interacting with Google APIs.
As an example, to get the current location of the user using the Latitude API, all it takes is the following 3 lines of code.

Latitude latitude = new Latitude(transport, accessProtectedResource, jsonFactory);
latitude.apiKey=OAuth2ClientCredentials.API_KEY;
LatitudeCurrentlocationResourceJson currentLocation = latitude.currentLocation.get().execute();

What the code above does is the following

Initialize a Latitude service definition object, the main gateway to the Latitude API. The object is initiazed with an HTTP Transport, an HTTP request initializer and a JSON factory.
We specify an API key on the Latitude service defintion object, so we can track the API usage in the Google APIs console.
We execute a GET request on the currentLocation endpoint.

In order to initialize the Latitude service definition,

we specify an HTTP transport, as the Latitude API like all Google APIs is a REST based API, where all communication is done over HTTP.
we specify an HTTP request initializer, as we need to ensure that the API calls are properly authorized. (meaning that the proper authorization headers get filled in with our OAutn 2.0 token).
we specify a JSON Factory object, so that the responses coming back from the API can be serialized into a clean java based model.

So in short, as a developer, there’s no need to write plumbing code to create HTTP request objects, parse responses, making sure everything is properly signed…. all of that plumbing is handled by the Google API client for Java library, and the Latitude generate client library.

However, before we can actually start making these calls, we need to make sure we have an OAuth 2.0 access token. If we attempt to call the API in a non-secured way, we’ll get the following exception.

com.google.api.client.http.HttpResponseException: 401 Unauthorized
     at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:380)
     at com.google.api.services.latitude.Latitude$RemoteRequest.execute(Latitude.java:550)
     at com.google.api.services.latitude.Latitude$CurrentLocation$Get.executeUnparsed(Latitude.java:222)
     at com.google.api.services.latitude.Latitude$CurrentLocation$Get.execute(Latitude.java:207)
     at com.ecs.android.sample.oauth2.AndroidOauthGoogleApiJavaClient.getCurrentLocation(AndroidOauthGoogleApiJavaClient.java:107)
     at com.ecs.android.sample.oauth2.AndroidOauthGoogleApiJavaClient.performApiCall(AndroidOauthGoogleApiJavaClient.java:80)

Preparing your app for OAuth 2.0

Before you can run the application, you’ll need to get a hold of an OAuth client ID, and an API key for Google Latitude. Both things can be retrieved from the Google API console. The Google API console allows you to define one or more projects. Create a project, and make sure that for “Latitude API”, the status switch is flipped to the “ON” position.

Next, click on “API Access”. You should see the following screen :

Click on “Create an OAuth 2.0 Client ID…”. Choose a product name, and optionally load up an image and click “Next”. (the product name and image will be shown to the user when your application is requesting him to authorize access).

Make sure you select “Installed application” and click “Create client ID”.

You should see the following summary

This summary contains 2 important items

The OAuth Client ID / Secret
The API key

You need the Oauth Client ID to setup your Oauth 2.0 communication. The API key is used to track the Latitude API usage in the console when clicking on the Reports link.
Before running the application, make sure you specify the Oauth 2.0 client ID, client secret and API key in the OAuth2ClientCredentials class

The OAuth 2.0 flow in Android

The first thing we need to before we can make a call to the Latitude API is to obtain an OAuth 2.0 access token. This token is obtained through a series of HTTP interactions between the application and the service provider (Google in this case). The first step is to present the user with an authorization screen, allowing him to authorize our application to access his Latitude API.

The authorization web page

This authorizationUrl can be generated using the GoogleAuthorizationRequestUrl object, provided by the Google API client for Java.
The GoogleAuthorizationRequestUrl is a Google extension to the OAuth 2.0 (draft 10) URL builder for an authorization web page to allow the end user to authorize the application to access their protected resources.

	 String authorizationUrl = new GoogleAuthorizationRequestUrl(OAuth2ClientCredentials.CLIENT_ID, OAuth2ClientCredentials.OAUTH_CALLBACK_URL, OAuth2ClientCredentials.SCOPE).build();

What’s important to note here is that we need to provide our OAuth 2.0 client ID (that we can found in the APIs console), a callback URL (after the user has authorized the request, Google will issue a redirect to this URL), and the
autorization scope.

The Latitude API provides the following OAuth 2.0 based scopes :

https://www.googleapis.com/auth/latitude.current.city
Access to current location at city granularity.
https://www.googleapis.com/auth/latitude.current.best
Access to best-available current location.
https://www.googleapis.com/auth/latitude.all.city
Access to current location and location history at city granularity.
https://www.googleapis.com/auth/latitude.all.best
Access to best-available current and past locations.

The generated URL that looks like this:

https://accounts.google.com/o/oauth2/auth?client_id=1021221231376.apps.googleusercontent.com&redirect_uri=http://localhost&response_type=code&scope=https://www.googleapis.com/auth/latitude.all.best

The page looks like this:

Notice how the image and product name is shown on the authorization page.

In our Android sample application, we’ll load up this URL in a WebView. The reason why I’ve opted to use a WebView is because we need a hook somewhere to intercept the page when the user authorizes the request. Google OAuth 2.0 has some limitations regarding the redirect URIs. In a previous article, where I showed you how to implement the OAuth 1.0 flow in Android, we used a custom scheme in our Oauth redirect URL (xoauth://callback). With OAuth 2.0 this is no longer possible. In our case, we’re using http://localhost as a callback, and we’ll use Webview to intercept this page, so that we can retrieve the code.

There are other advantages of using a Webview. For example, the Webview doesn’t have an address bar, so the user cannot navigate away from the page. Also, the Webview doesn’t interfere with your browser app, something you will have when you pop the browser app from your Android application.

We start by creating a WebView component, and putting it as the main content of the activity.

		WebView webview = new WebView(this);
        webview.getSettings().setJavaScriptEnabled(true);
        webview.setVisibility(View.VISIBLE);
        setContentView(webview);

We create a WebViewClient, needed to have a hook when the user has authorized the request, and we need to intercept the code.
In this code, we check if the URL loaded into the webview is our redirect URL (simple startswith check). If this is the case, there can be 2 options :

The user authorized the request, meaning a code request parameter will be present in the URL. If this is the case, we retrieve the code from the URL, and create a GoogleAuthorizationCodeGrant object.
We pass on our transport, a JSON factory, our OAuth 2.0 client ID and client secret, our code and our callback URL. When we execute the GoogleAuthorizationCodeGrant, we get a AccessTokenResponse that contains our OAuth 2.0 access token and refresh token.

We store the token response in our shared preferences, hide the webview (hack to ensure the user doesn’t see the redirect URL being loaded in the webview, as we only need it to fetch the code, and not to display the URL), and start our main activity again. (In the main activity, we perform the Latitude API call, only this this time we’ll have a valid access token.

        /* WebViewClient must be set BEFORE calling loadUrl! */
        webview.setWebViewClient(new WebViewClient() {

        	@Override
            public void onPageFinished(WebView view, String url)  {

            	if (url.startsWith(OAuth2ClientCredentials.OAUTH_CALLBACK_URL)) {
            		try {

            			if (url.indexOf("code=")!=-1) {

	            			String code = extractCodeFromUrl(url);

				  		      AccessTokenResponse accessTokenResponse = new GoogleAuthorizationCodeGrant(new NetHttpTransport(),
										      new JacksonFactory(),
										      OAuth2ClientCredentials.CLIENT_ID,
										      OAuth2ClientCredentials.CLIENT_SECRET,
										      code,
										      OAuth2ClientCredentials.OAUTH_CALLBACK_URL).execute();

				  		      CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
				  		      credentialStore.write(accessTokenResponse);
				  		      view.setVisibility(View.INVISIBLE);
				  		      startActivity(new Intent(PrepareRequestTokenActivity.this,AndroidOauthGoogleApiJavaClient.class));
            			} else if (url.indexOf("error=")!=-1) {
            				new SharedPreferencesCredentialStore(prefs).clearCredentials();
            				startActivity(new Intent(PrepareRequestTokenActivity.this,AndroidOauthGoogleApiJavaClient.class));
            			}

					} catch (IOException e) {
						e.printStackTrace();
					}

            	}
                System.out.println("onPageFinished : " + url);

            }
        });

The following code simply loads up the authorizationUrl into the webview.

        String authorizationUrl = new GoogleAuthorizationRequestUrl(OAuth2ClientCredentials.CLIENT_ID, OAuth2ClientCredentials.OAUTH_CALLBACK_URL, OAuth2ClientCredentials.SCOPE).build();
        webview.loadUrl(authorizationUrl);

Access / Refresh Tokens

The sample application contains a simple SharedPreferencesCredentialStore class that we’ll use to store the Oauth 2.0 tokens, and retrieve them when we want to make an API call. Once we have the OAuth 2.0 tokens in our shared preferences, there’s no need to pop the Webview again, as the user has already authorized the request.

Executing the API call

The actual code to perform the secured API call can be found here.

	private void performApiCall() {
		try {
			JsonFactory jsonFactory = new JacksonFactory();
			HttpTransport transport = new NetHttpTransport();

			CredentialStore credentialStore = new SharedPreferencesCredentialStore(prefs);
			AccessTokenResponse accessTokenResponse = credentialStore.read();

			GoogleAccessProtectedResource accessProtectedResource = new GoogleAccessProtectedResource(accessTokenResponse.accessToken,
			        transport,
			        jsonFactory,
			        OAuth2ClientCredentials.CLIENT_ID,
			        OAuth2ClientCredentials.CLIENT_SECRET,
			        accessTokenResponse.refreshToken);

		    final Latitude latitude = new Latitude(transport, accessProtectedResource, jsonFactory);
		    latitude.apiKey=OAuth2ClientCredentials.API_KEY;

			LatitudeCurrentlocationResourceJson currentLocation = latitude.currentLocation.get().execute();
			String locationAsString = convertLocationToString(currentLocation);
			textView.setText(locationAsString);
		} catch (Exception ex) {
			ex.printStackTrace();
			textView.setText("Error occured : " + ex.getMessage());
		}
	}

We start by creating a JSON Factory and an HTTP transport.
We retrieve our accessTokenResponse from the credentialStore (were put there when the user authorized access through the WebView).
We create our Latitude service definition object
We execute a GET request on the currentLocation, to retrieve a LatitudeCurrentlocationResourceJson object.
We output the current location on the screen.

Conclusion

I was surprised to see that there was little documentation available on how to properly implement OAuth 2.0 on an Android platform. I have the feeling that the method being outlined here is currently the only way to do it properly. During the last Google I/O, there was a session that covered OAuth 2.0 integration with the Android AccountManager, meaning that you can authorize a user through the AccountManager. That should be more tightly coupled with the Android system, and you’re not forced to go through the Oauth 2.0 web based flow like we did here. Unfortunately, this didn’t seem to work for the LAtitude API. IT is possible to get it up and running with the Google Buzz and Google Tasks API, but it also doesn’t really make a great user experience. It’s also not documented at all, and unclear if Google sees this as the preferred way of using OAuth 2.0 on an Android platform. The talk also mentioned that they are not quite ready with it.
So, to conclude, we’ve implemented the Oauth 2.0 webflow on an Android platform. Thanks to the Google API client for Java, very little code was required to setup the OAuth 2.0 dance, and using the WebView, we’ve ensured that we had a decent user experience, despite the fact that we needed to load up the Google authorization page. This approach can be used for any Google API, and although the Google APIs Client Library for Java is very Google API centric, it can be used with other service providers as well.

References

Developing Android Home Screen Widgets

ddewaele — Tue, 24 May 2011 19:58:26 +0000

In this article, I’ll be showing you how to create a widget for the Android homescreen. Widgets can be useful to provide condensed information, without necessarily having to open your application. In addition to showing information, a widget can also be used to trigger certain actions related to your application. Instead of forcing the user to open up your application and navigating to a certain screen to perform an action, a widget can provide the user with a quick shortcut to that action. You can also dynamically change the layout of your widget (ex: when the user presses a button, the button can be highlighted, or a piece of text can altered). This article is accompanied by a sample android application that includes the widgets we’ll be discussing here.

Designing the widget

An Android Widget can have different sizes. As can be seen in the screenshot below, the homescreen is divided into several squares, where each widget fits graphically with other widgets and with the other elements (like application shortcuts) of the Android Home screen.

The home screen contains 16 such squares (4×4), and has a width of 320dp and a height of 400dp.

Supported Widget sizes

Depending on the screen orientation, your widget will have different dimensions. What does remain consistent is the number of squares the widget will occupy.
There are six standard widget sizes. Three sizes related to the Home screen grid of 4 x 4 (portrait), the other 3 relate to the Home screen grid of 4 x 4 (landscape) cells.
These dimensions correspond to the bounding boxes for the widget we’ll see in the next section.

portrait

4 x 1 squares, dimension 320 x 100
3 x 3 squares, dimension 240 x 300
2 x 2 squares, dimension 160 x 200

landscape

4 x 1 squares, dimension 424 x 74
3 x 3 squares, dimension 318 x 222
2 x 2 squares, dimension 212 x 148

In Android terminology, a Widget is made up of the following components

A bounding box
A frame
The widget’s graphical controls and other elements.

The bounding box

We’ll start by creating an image canvas for a 4×1 widget. This needs to be 320×100.

The bounding box is the full canvas you have at your disposal. We won’t be occupying all of that space, as we need to take into account the padding. Start by defining the frame that will form the boundaries of your image:

The frame

We need to ensure that sufficient padding (empty space) is available around the widget, as we don’t want it to take up too much space when placed alongside other widgets. As such, our Widget should be contained within a frame that we’ll define inside the bounding box, leaving some space on the top, bottom, left and right hand side of the bounding box.

The actual content of the widgets shouldn’t draw to the edge of these dimensions, but fit inside a frame withing the bounding box, as described above.

We draw a rectangle inside the frame, and contract the selection to round the edges a bit.

In order to have a consistent look & feel, you should apply the following blending options to your image:

The widget’s graphical controls and other elements.

As we’re going to add icons and text to our widget by putting Android Views on a Layout file, these shouldn’t be included in our final image. However, to get a visual idea on how the widget will look like, it might be interesting to put these controls onto your image. In Photoshop, just put them in seperate layers that you can exclude before saving the final PNG file.

Your image should look something like this:

Save your widget artwork (without the controls) using the appropriate bounding box size in PNG-24 format on a transparent background and in 8-bit color.

Your image should look something like this:

Putting the widget on the screen.

Now that we’ve got the graphics out of the way, it’s time to start coding…
A Widget is basically a broadcast receiver, capable of listening for specific intents. One intent that the Widget is particulary interested in is the android.appwidget.action.APPWIDGET_UPDATE intent.

Now that we have designed our widget, we can add it to our application. In order to do that we need to execute the following steps:

Define the widget in the manifest

We start by defining our widget like this in the application Manifest.

The definition shows us the following :

the widget is a broadcast receiver
the widget has an intent-filter, meaning it will listen for certain events
the widget that can be given a label. The label is shown in the list of widgets when the user wants to add a widget to the homescreen.
meta data is provided, providing a pointer to an XML resource, used to further define our widget.

We’ll provide a label in our strings.xml that will be used in the list of widgets.



    Hello World, AndroidWidgetSample!
    AndroidWidgetSample
    Our Widget 4x1

Appwidget proviuder xml definition

Next we need to create an appwidget provider definition. We specify a minimum height and width for the widget, as well as an update interval, and a pointer to our initial layout.

For calculating the minWidth and minHeight, we need to some math.
Because the Home screen’s layout orientation (and thus, the cell sizes) can change, as a rule of thumb, you should assume the worst-case cell size of 74 pixels for the height and width of a cell
So, for a 1×1 widget, by applying the formula (number of cells * 74) – 2, we arrive at a minWidth=72dip and minHeight=72dip.

The android:updatePeriodMillis defines the interval when the widget onUpdate method will be called. There is a minimum for this (so we cannot set this to whatever we want to have frequent updates on the widget).

It is documented somewhere but I wasn’t able to find it. In order to have more frequent updates on the Widget, you’ll need to implement an AlarmManager to send events to the Widget.

The initial layout is the actual layout file that our widget will use, leading us to the next section.

Defining the layout

The layout file is basically the same layout structure as you would use for a normal activity, however, you need to take certain space constraints into account. Android support different sizes when it comes to home screen widgets.

We’ll start with a very simple layout, that just uses our widget as a background image

Notice how we also set the width and height to 320dp x 100dp as we’re dealing with a 4×1 widget.

We’ll now add our icon and some text to the widget. Here’s the complete layout of the widget:

You can use the Eclipse Graphical Layout to determine the correct margins, and get an idea on how the widget will look like.

Also notice how we’ve applied a style for the layout. We’ll put stuff like background images, fonts into a styles.xml. The complete style definition for the widget looks like this :

The AppWidgetProvider

As with any element we define in the manifest (activities,services,broadcastreceivers), the actual implementation of the widget can be found in a java class, extending AppWidgetProvider.
For now, create the SampleWidgetProvider4_1 like this:

public class SampleWidgetProvider4_1 extends AppWidgetProvider {

	@Override
	public void onUpdate(Context context, AppWidgetManager appWidgetManager,int[] appWidgetIds) {
		super.onUpdate(context, appWidgetManager, appWidgetIds);
		// implementation will follow
	}
}

Project structure

Your project structure should look like this :

To summarize so far, the project should contain :

Widget defined in manifest (receiver element)
Widget provider xml definition in xml/widget_provider_4_1.xml
Widget layout file in layout/widget_layout_4_1.xml
Widget layout styles in values/styles.xml
Widget labels in values/strings.xml
Widget image files (backgrounds & controls) in drawable
Widget AppWidgetProvider class in your source folder

With these tasks out of the way, we’re able to display our Widget on the homescreen. Nothing else going on at the moment, so it’s time to start adding some widget behavior.
The sample application contains 2 widgets (a 4×1 widget and a 2×2 widget). This is how they look like:

As you can see, they fit nicely on the home screen alongside the other icons.

Widget Behavior

Obviously, displaying a widget is one thing, making it act upon certain actions is another thing.

Clicking on the widget

The first thing we’ll do is make our Widget aware of the fact that the user has clicked on it. What typically happens in this type of scenario is that the main application is started.

In order to do that, we need to put the following code in our Widget onUpdate method:

          // When we click the widget, we want to open our main activity.
          Intent launchActivity = new Intent(context,AndroidWidgetSample.class);
          PendingIntent pendingIntent = PendingIntent.getActivity(context,0, launchActivity, 0);
          remoteViews.setOnClickPendingIntent(R.id.widget, pendingIntent2);

          ComponentName thisWidget = new ComponentName(context, SampleWidgetProvider4_1.class);
          AppWidgetManager manager = AppWidgetManager.getInstance(context);
          manager.updateAppWidget(thisWidget, remoteViews);

As you can see, we set an OnClickPendingIntent on our widget. The Pending Intent will launch an Activity, in our case, the only activity in our sample, being the AndroidWidgetSample activity.
The setOnClickPendingIntent is targeted to our entire widget (R.id.widget), and not to a specific control. This means that if we click on an area in our widget that doesn’t cover any other clickable controls, this activity will be launched. Note also that we need to call the updateAppWidget on the AppWidgetManager in order for it to respond to the onClick.

Clicking on a specific control on the widget

An activity can also contain certain controls that the user may want to manipulate. A widget might contain a play/stop button, or another component that you would like to specifically target. In our sample, we only have an icon and a piece of text, but we’ll make sure that a specific action is being triggered when clicking on the icon.

When the icon is clicked on the widget, we broadcast an intent containing the ACTION_WIDGET_UPDATE_FROM_WIDGET action.

		  Intent intent = new Intent(context, SampleWidgetProvider4_1.class);
		  intent.setAction(Constants.ACTION_WIDGET_UPDATE_FROM_WIDGET);
		  intent.putExtra(Constants.INTENT_EXTRA_WIDGET_TEXT,"Icon clicked on Widget");

          PendingIntent actionPendingIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
          remoteViews.setOnClickPendingIntent(R.id.icon,actionPendingIntent);

Similar code to the one we saw before. Note here that the setOnClickPendingIntent is targeting the icon on our widget, so this intent will only be broadcast if we hit the icon on the widget.

In the manifest, the widget is configured with an intent filter to match this action. By doing this, we can intercept this intent in the onReceive method of the Widget (remember that the AppWidgetProvider is nothing more than a fancy BroadcastReceiver.

Note how I added some other actions as well, as this allows us to differentiate between different messages being sent to our widget.

Allowing Activities to update the Widget

In order to update the Widget from our main activity, we’ve placed a button on the main layout, that does the following:

		btnSendText = (Button) findViewById(R.id.btn_send_text);

        btnSendText.setOnClickListener(new View.OnClickListener() {
            public void onClick(View v) {
            	sendTextToWidget(AndroidWidgetSample.this);
            }
        });

    private void sendTextToWidget(Context context) {
		Intent uiIntent = new Intent(Constants.ACTION_WIDGET_UPDATE_FROM_ACTIVITY);
		SimpleDateFormat sdf = new SimpleDateFormat("hh:mm:ss");
		uiIntent.putExtra(Constants.INTENT_EXTRA_WIDGET_TEXT,"Button clicked on Activity at " + sdf.format(new Date()));
		context.sendBroadcast(uiIntent2);
    }

As you can see, the button does nothing more that broadcast an intent that will be picked up by our Widget. (same thing as with the icon click in the widget itself).

The Widget onReceive method

All these actions are processed by the Widget through its onReceive method. Here, we can get a hold of the remoteView, and in our case, update the TextView using the setTextViewText method on the Widget. Keep in mind that a Widgets layout is not accessed in the same way as an Activities layout. We cannot execute a findViewById to get a reference to TextViews or Buttons. We always need to pass by the removeView.

	@Override
	public void onReceive(Context context, Intent intent) {
		Log.i(Constants.TAG, "onReceive called with " + intent.getAction());
		RemoteViews remoteViews = new RemoteViews(context.getPackageName (), R.layout.widget_layout_4_1);
		if (intent.getAction().equals(Constants.ACTION_WIDGET_UPDATE_FROM_ACTIVITY)) {
			String widgetText = intent.getExtras().getString(Constants.INTENT_EXTRA_WIDGET_TEXT);
			remoteViews.setTextViewText(R.id.word_text, widgetText);
        } else if (intent.getAction().equals(Constants.ACTION_WIDGET_UPDATE_FROM_ALARM)) {
        	String widgetText = intent.getExtras().getString(Constants.INTENT_EXTRA_WIDGET_TEXT);
        	SimpleDateFormat sdf = new SimpleDateFormat("hh:mm:ss");
			remoteViews.setTextViewText(R.id.word_text, widgetText + " at " + sdf.format(new Date()) );
        } else if (intent.getAction().equals(Constants.ACTION_WIDGET_UPDATE_FROM_WIDGET)) {
			String widgetText = null;
			if (intent.getExtras()!= null) {
				widgetText = intent.getExtras().getString(Constants.INTENT_EXTRA_WIDGET_TEXT);
			} else {
				widgetText = "Extras was null";
			}
        	SimpleDateFormat sdf = new SimpleDateFormat("hh:mm:ss");
			remoteViews.setTextViewText(R.id.word_text, widgetText + " at " + sdf.format(new Date()) );
        } else {
        	super.onReceive(context, intent);
        }
		ComponentName cn = new ComponentName(context, SampleWidgetProvider4_1.class);
		AppWidgetManager.getInstance(context).updateAppWidget(cn, remoteViews);

	}

If we want to highlight the icon when it has been clicked for example, we use the following code

remoteViews.setImageViewResource(R.id.icon, R.drawable.icon_red);

This will simply put another drawable on the icon layout element, allowing for an image toggle effect.

Conclusions

Widgets can provide added value to your application by giving the user certain shortcuts, or giving them the opportunity to see vital information regarding your app by just looking at the home screen. When developing widgets, you do need to take into account certain constraints. You’ll need to adhere to certain size requirements, and you also need to be aware of the fact that Widgets are not the same as activities. The way you interact with them from a development perspective is different than what you’re used to when working with activities.

References

New way to create test users in Facebook

ddewaele — Sat, 07 May 2011 19:58:47 +0000

Introduction

As mentioned in the Facebook developer docs, test users can only be created using a call to the Graph API.
As described in my previous Facebook article, a dedicated webpage was available at the time to create test users, however, that page has been brought offline.

You can create a test user associated with a particular app using the Graph API with your app access token.


https://graph.facebook.com/APP_ID/accounts/test-users?

  installed=true
  &permissions=read_stream
  &method=post
  &access_token=APP_ACCESS_TOKEN

However, before we’ll be able call this API, we first need to retrieve an Access Token for our application.

Application Access Token

Before you get started, you might want to startup a text editor to copy paste some of these URLs and values (application ID, application secret, access token) as you’ll need to construct a lot of URLS that include these values.

In order to get an Access Token for our application, we need to know our Application Secret.

The first thing we’ll need is our Facebook Application ID. The Application ID is a unique identifier that you received while creating your application.
We’ can use the URL below to retrieve our Application Secret. Fill in your Application ID in the following URL to goto your Facebook App page and retrieve the Application Secret.

http://www.facebook.com/developers/editapp.php?app_id=YOUR_APP_ID

Now that we have the Application ID and the Application Secret, we can retrieve an access token for our application. In order to do that, we need to call the following URL with our Application ID and Application Secret.


https://graph.facebook.com/oauth/access_token?

	client_id=YOUR_APP_ID
	&client_secret=YOUR_APP_SECRET
	&grant_type=client_credentials

You’ll receive the following response:

access_token=109688035775165|hZe8qX8el6Qlp0xMyoAb5giYRls

Creating the test user

Now that we have our access token, we can do the task at hand, and use the Graph API to call our test-user.


https://graph.facebook.com/APP_ID/accounts/test-users?

  installed=true
  &permissions=read_stream
  &method=post
  &access_token=APP_ACCESS_TOKEN

With everything filled in, your request should look resemble something like this:

https://graph.facebook.com/109636235495125/accounts/test-users?installed=true&permissions=read_stream&method=post&access_token=109636235495125|qZe8yX8eL6zlp0xMGoAj5girRlS

If all went well, you should get a response similar to this:

{
   "id": "10000123432213",
   "access_token": "109636235495125|2.DFDGayE7X1s9ft_N7k94_E__.3600.1304802000.0-100002332671439|HhwACDVFeNhQ_UV0tQY0mUzkvLs",
   "login_url": "https://www.facebook.com/platform/test_account_login.php?user_id=10000123432213&n=R3feV4O7YrlIb0n",
   "email": "some_one\u0040tfbnw.net",
   "password": "3123123123133"
}

This basically means your test user has been created, and you can login to Facebook with this account. Use the email address (some_one@tfbnw.net) to login, and the password provided in the response.

You can change the password to a more convenient value for testing.

References

OAuth in Android using the Google APIs Client Library for Java

ddewaele — Tue, 12 Apr 2011 17:23:54 +0000

Today we’ll be looking at the Google APIs Client Library for Java. The API is provided by Google, and is a flexible, efficient, and powerful Java client library for accessing any HTTP-based API’s on the web. According to Google, it is the recommended library for accessing Google API’s based on REST or JSON-RPC. One of the nice things about this library is that it fully supports the Android environment out of the box. So we’ll focus on those features in this article.

To avoid confusion, Google offers the following APIs (the first one being the topic of this post, and compatible with the Android platform) :

Google APIs Client Library for Java (google-api-java-client)
Google Data Java Client Library (gdata-java-client)

Unfortunately, there are no samples available that perform the OAuth dance in Android using this library, so I thought I’d write one myself. The code for this article can be found in the AndroidOauthGoogleApiJavaClient repository

The first thing we need to do is download the library. You can use the link above to download the library as a JAR file.

The library supports the following authentication mechanisms

OAuth 1.0a
OAuth 2 draft 10 (JavaDoc, specification
Android AccountManager
Legacy Google methods
- ClientLogin
- AuthSub (JavaDoc, documentation)

We’ll start by looking at the buzz-json-oauth-sample project, and see if we can port it to Android. The sample is a standalone java application that uses OAuth to let the user authorize the application to show his/her Buzz posts. It follows the standard OAuth flow. As this is not a web-application, the sample needs a way to capture the OAuth tokens after the user has granted access. It does so by starting an embedded Jetty server to host a callback-URL, needed to capture the oauth access token.

In short, when we launch the application, the following happens :

Setup the JSON/HTTP transport
Authorize the user using OAuth
- The application launches a browser to initiate the OAuth dance
- After the user has authorized access, a callback is done to a local jetty
- The landing page on the local jetty allows us to capture the oauth access token
Perform authorized API calls to Google Buzz

Our Android based implementation will follow the same steps, but without the local jetty callback offcourse. With Android we can use the intent mechanism to capture the oauth access token, so there’s no need to start a local HTTP server.

Setting up the transport

The Google API Client library for Java abstracts the HTTP transport through an com.google.api.client.http.HttpTransport object. As noted in the documentation, the recommended concrete implementation HTTP transport library to use depends on what environment you are running in. As we’re writing an Android application here, we’ll be using the com.google.api.client.apache.ApacheHttpTransport.

We’ll define our Transport in a Util class

	static HttpTransport newTransport() {
		HttpTransport result = new ApacheHttpTransport();
		GoogleUtils.useMethodOverride(result);
		GoogleHeaders headers = new GoogleHeaders();
		headers.setApplicationName("Google-BuzzSample/1.0");
		result.defaultHeaders = headers;
		return result;
	}

Next, we need to add an HTTP response content parser to the transport, so that we can parse the response coming the transport.

	private static void setUpTransport() {
		JsonCParser parser = new JsonCParser();
		parser.jsonFactory = JSON_FACTORY;
		TRANSPORT.addParser(parser);
	}

Signing requests

OAuth is all about retrieving tokens using signed requests. By obtaining an OAuth access token at the final step of the OAuth flow, the application can do authorized API calls on behalf of the user. As the OAuth specification mandates that all requests are properly signed, the signing process is very important in OAuth.

The OAuthHmacSigner object is the object responsible for signing requests, and as such is very important in the OAuth flow, as it is required to sign all requests so that they can pass as authorized requests.
The OAuthHmacSigner is initialized like this :

			signer = new OAuthHmacSigner();
			signer.clientSharedSecret = Constants.CONSUMER_SECRET;

At the start of the OAuth flow, when the user hasn’t authorized access yet, the signer object contains

Key	Value
clientsharedsecret	`anonymous`
tokensharedsecret	`EMPTY`

Notice how the tokensharedsecret is not available in the start of the OAuth dance. This value will be filed in after we’ve fetched the Request Token.

Request Token

Our Android activity uses the following code to launch the OAuth flow :

		// Launch the OAuth flow to get an access token required to do authorized API calls.
		// When the OAuth flow finishes, we redirect to this Activity to perform the API call.
		launchOauth.setOnClickListener(new View.OnClickListener() {
			public void onClick(View v) {
				startActivity(new Intent().setClass(v.getContext(),
						PrepareRequestTokenActivity.class));
			}
		});

As you can see, a seperate activity (PrepareRequestTokenActivity) is used to fetch the actual request token. This activity does nothing more then initializing our Signer object, and starting an asyncTask called OAuthRequestTokenTask.

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
    	try {
			signer = new OAuthHmacSigner();
			signer.clientSharedSecret = Constants.CONSUMER_SECRET;
    	} catch (Exception e) {
    		Log.e(TAG, "Error creating consumer / provider",e);
		}
        Log.i(TAG, "Starting task to retrieve request token.");
		new OAuthRequestTokenTask(this,signer).execute();
	}

We start the OAuth dance by fetching a Request Token. This is done in the OAuthRequestTokenTask by creating a GoogleOAuthGetTemporaryToken. This object will allow us to fetch our initial token, the Request Token.

The GoogleOAuthGetTemporaryToken represents a generic Google OAuth 1.0a URL to request a temporary credentials token (also known as the “request token”) from the Google Authorization server.

			GoogleOAuthGetTemporaryToken temporaryToken = new GoogleOAuthGetTemporaryToken();
			temporaryToken.transport = Util.AUTH_TRANSPORT;

			temporaryToken.signer = signer;
			temporaryToken.consumerKey = Constants.CONSUMER_KEY;
			temporaryToken.scope = Constants.SCOPE;
			temporaryToken.displayName = Util.APP_DESCRIPTION;
			temporaryToken.callback = Constants.OAUTH_CALLBACK_URL;
			OAuthCredentialsResponse tempCredentials = temporaryToken.execute();

The GoogleOAuthGetTemporaryToken object contains

Object	Value
Our signer object	`com.google.api.client.auth.oauth.OAuthHmacSigner`
Consumer Key	`anonymous`
Scope	`https://www.googleapis.com/auth/buzz`
Displayname	`Buzz API Java Client Sample`
Callback URL	`x-oauthflow://callback`

The GoogleOAuthGetTemporaryToken toString() method looks like this :

https://www.google.com/accounts/OAuthGetRequestToken?scope=https://www.googleapis.com/auth/buzz&xoauth_displayname=Buzz%20API%20Java%20Client%20Sample

In order to retrieve a request token, we call the GoogleOAuthGetTemporaryToken execute() method, like this :

OAuthCredentialsResponse tempCredentials = temporaryToken.execute();

By calling the execute() method, Google verifies that the requesting application has been registered with Google or is using an approved signature (in the case of installed applications). The temporary token acquired with this request is found in OAuthCredentialsResponse This temporary token is used in GoogleOAuthAuthorizeTemporaryTokenUrl to direct the end user to a Google Accounts web page to allow the end user to authorize the temporary token (see next step – Authorize Token).

The exeucte() method returns a com.google.api.client.auth.oauth.OAuthCredentialsResponse, containing our request token, and token secret.

Key	Value
token	`4/hFOwXawX4WNVVcfPgYSWlidypOAL`
tokensecret	`skaOU3r8uhovUSuTyFhsscLV`

These 2 values are very important. We’ll to asign :

the tokenSecret (shared-secret for use with “HMAC-SHA1″ signature algorithm) onto the signer object we defined earlier.
the token to our OAuthAuthorizeTemporaryTokenUrl object that we’ll create now.

So after having retrieved the request token, we can assign the tokenSecret to our signer object. Our signer object now contains this :

Key	Value
clientsharedsecret	`anonymous`
tokensharedsecret	`skaOU3r8uhovUSuTyFhsscLV`

Authorize Token

Next step in the OAuth dance is to retrieve the authorize token. In order to do that, we create a OAuthAuthorizeTemporaryTokenUrl. This object is an OAuth 1.0a URL builder for an authorization web page to allow the end user to authorize the temporary token.

This object contains the following properties.

			OAuthAuthorizeTemporaryTokenUrl authorizeUrl = new OAuthAuthorizeTemporaryTokenUrl(Constants.AUTHORIZE_URL);
			authorizeUrl.set("scope", temporaryToken.scope);
			authorizeUrl.set("domain", Constants.CONSUMER_KEY);

			authorizeUrl.set("xoauth_displayname", Util.APP_DESCRIPTION);
			authorizeUrl.temporaryToken = tempToken = tempCredentials.token;

The scope and the domain are mandatory fields we need to set on the OAuthAuthorizeTemporaryTokenUrl object. API specific values need to be set on this object. For example, the Google Latitude API supports the location=”all” and granulariy=”best” fields on the authorization endpoint. As such, the can be set like this:

authorizeUrl.put("location", "all");
authorizeUrl.put("granularity", "best");

But as we’re using the Google Buzz API here, you can see, we set the following properties :

Object	Value
Domain	`anonymous`
Scope	`https://www.googleapis.com/auth/buzz`
xoauth_displayname	`Buzz API Java Client Sample`
temporaryToken	`4/hFOwXawX4WNVVcfPgYSWlidypOAL`

The OAuthAuthorizeTemporaryTokenUrl toString looks like this :


https://www.google.com/buzz/api/auth/OAuthAuthorizeToken?scope=https://www.googleapis.com/auth/buzz&domain=anonymous&xoauth_displayname=Buzz%20API%20Java%20Client%20Sample

To retrieve the actual Authorization URL, we call the authorizeUrl.build() method. This gives us the actual Authorization URL we’ll need to show the user in a browser.


https://www.google.com/buzz/api/auth/OAuthAuthorizeToken?oauth_token=4/hFOwXawX4WNVVcfPgYSWlidypOAL&scope=https://www.googleapis.com/auth/buzz&domain=anonymous&xoauth_displayname=Buzz%20API%20Java%20Client%20Sample

In our Android application, we’ll use this URL to pop a browser, as at this point user interaction is required in order for him/her to authorize the request.
This is done using the following code :

			Log.i(TAG, "Popping a browser with the authorize URL : " + url);
			Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url)).setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP | Intent.FLAG_ACTIVITY_NO_HISTORY | Intent.FLAG_FROM_BACKGROUND);
			context.startActivity(intent);

After the user has granted access, he has authorized our temporary token. After this authorization, we can capturing the following 2 important fields

oauth_verifier
oauth_token

These parameters are embedded in the URL after the user has granted access. In Android, capturing these parameters is done via the callback URL we specified in the beginning. This callback URL is the URL that is shown in the browser after the user has authorized the request. In our Android application, we have defined an activity with an intent-filter, listening for that callback URL.

This means that when our callback URL (x-oauthflow://callback) is shown in the browser, our Activity kicks in, and its onNewIntent method is called. In this method, we capture the oauth_token and oauth_verifier like his :

	/**
	 * Called when the OAuthRequestTokenTask finishes (user has authorized the request token).
	 * The callback URL will be intercepted here so we can fetch the token and token secret.
	 */
	@Override
	public void onNewIntent(Intent intent) {
		super.onNewIntent(intent);
		SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(this);
		final Uri uri = intent.getData();
		if (uri != null && uri.getScheme().equals(Constants.OAUTH_CALLBACK_SCHEME)) {
			Log.i(TAG, "Callback received : " + uri);
			new RetrieveAccessTokenTask(this,signer,prefs).execute(uri);
			finish();
		}
	}

As you can see, we capture the URL, and pass it on to our RetrieveAccessTokenTask, where we can actually fetch our access token.

Access token

Capturing the 2 fields (oauth_verifier and oauth_token) is done in the RetrieveAccessTokenTask. We retrieve the 2 parameters from the URL

[sourcode language="java"]
String requestToken = uri.getQueryParameter(“oauth_token”);
String verifier = uri.getQueryParameter(“oauth_verifier”);
[/sourcecode]

In order to retrieve the actual access token that we’ll need to perform the authorized API calls, we need an GoogleOAuthGetAccessToken object that contains both the oauth_token and oauth_verifier.

		GoogleOAuthGetAccessToken accessToken = new GoogleOAuthGetAccessToken();
		accessToken.transport = Util.AUTH_TRANSPORT;
		accessToken.temporaryToken = requestToken;
		accessToken.signer = signer;
		accessToken.consumerKey = Constants.CONSUMER_KEY;
		accessToken.verifier = verifier;

The GoogleOAuthGetAccessToken object contains

Object	Value
temporaryToken	`4/hFOwXawX4WNVVcfPgYSWlidypOAL`
Our signer object	`com.google.api.client.auth.oauth.OAuthHmacSigner`
Consumer Key	`anonymous`
Verifier	`jAsUb68lGmDO8P1sivfgGLz6`

In order to get the actual access token (token and tokenSecret), we execute the following call to retrieve a OAuthCredentialsResponse object :

credentials = accessToken.execute();

The OAuthCredentialsResponse returned here contains

Key	Value
token	`1/PeJEgwmhgAbQyNTB3knWg5k1ABPBgT7DGC6ZNvkcvMQ`
tokensharedsecret	`/m+kCfGms8xI/Zm88oy5OGMC`

We store the credentials in our Android Shared Preferences, so that we don’t need to force the user to authorize the request again.

		 final Editor edit = prefs.edit();
		 edit.putString(Constants.PREF_KEY_OAUTH_TOKEN, credentials.token);
		 edit.putString(Constants.PREF_KEY_OAUTH_TOKEN_SECRET, credentials.tokenSecret);
		 edit.commit();

Making API calls

In order to make an authorized API call, we’ll do the following

Retrieve the access token and token secret from our shared preferences
Create a signer object, containing our token secret
Create an authorizer object, containing our signer and access token
Tell the authorizer to sign our requests

These steps can be seen in the code snippet below :

		String token = prefs.getString(Constants.PREF_KEY_OAUTH_TOKEN, "");
		String secret = prefs.getString(Constants.PREF_KEY_OAUTH_TOKEN_SECRET, "");

		OAuthHmacSigner signer = new OAuthHmacSigner();
		signer.clientSharedSecret = Constants.CONSUMER_SECRET;
		signer.tokenSharedSecret = secret;
		OAuthParameters authorizer = new OAuthParameters();
		authorizer.consumerKey = Constants.CONSUMER_KEY;
		authorizer.signer = signer;
		authorizer.token = token;
		authorizer.signRequestsUsingAuthorizationHeader(Util.TRANSPORT);

The signer contains :

Key	Value
clientsharedsecret	`anonymous`
tokensharedsecret	`/m+kCfGms8xI/Zm88oy5OGMC`

The authorizer contains :

Key	Value
consumerKey	`anonymous`
Our signer object	`com.google.api.client.auth.oauth.OAuthHmacSigner`
token	`1/PeJEgwmhgAbQyNTB3knWg5k1ABPBgT7DGC6ZNvkcvMQ`

The actual API calls are done through the Google Buzz model provided by the sample apps, contained in the com.google.api.client.sample.buzz.model.

For example, retrieving a list of Buzz posts is done through the BuzzActivityFeed object:

BuzzActivityFeed feed = BuzzActivityFeed.list();

The list is implemented by executing a GET request through the transport (meaning it’s properly signed), and parsing the respone using the JSON parser to return it as a BuzzActivityFeed item.

  public static BuzzActivityFeed list() throws IOException {
    HttpRequest request = Util.TRANSPORT.buildGetRequest();
    request.url = BuzzUrl.forMyActivityFeed();
    return request.execute().parseAs(BuzzActivityFeed.class);
  }

References

Latify v2.0 screenshots

admin — Wed, 06 Apr 2011 18:53:29 +0000

Latify v2.0 has been released on the Android Market. Introduced location polling profiles and a new screen layout, optimizing screen real estate usage.

Thought I’d share some screenshots:

A 30 minute guide to integrating Facebook in your Android application

ddewaele — Mon, 28 Feb 2011 20:33:56 +0000

Introduction

The goal of this article is to get Facebook integration up & running from your Android app in 30 minutes. The guide will show you how to

setup a Faceook test account
register a Facebook application
authenticate the user in your Android application.
have the user update his Facebook wall from your Android application.

This guide is accompanied by a sample application that’s available in Github in the AndroidFacebookSample repository. To import this project in Eclipse, I suggest using the EGit plugin that can be installed via the Main P2 Repository located at http://download.eclipse.org/egit/updates.

Before running this project, make sure you change the com.ecs.android.facebook.Sample.AndroidFacebookSample file to include your Facebook API key (see subsequent section).
Once you have sample application up & running, you can copy the relevant classes into your projects to have Facebook up & running from your Android application.

First things first … In order to integrate with Facebook, you need 2 things :

A Facebook test account, used in our Android application to login to Facebook and make status updates.
A Facebook application, used to inform the user in your Android application that this application is requesting you to login to Facebook.

Facebook Test Account

We’ll start by creating a test account that we’ll use in our Android application. Signup for a new user account at Facebook. If you already have an account, sign up for a new account using your existing name but specify a different email address. Once the account has been created, we’ll convert it into a Facebook test account.

Note : The following step should not be done on your real facebook account. Converting an existing Facebook account into a test account is irreversible, so please ensure that you do the following step with your newly created “dummy” account.

When logged into Facebook, goto the Facebook Become Test Account page to convert your newly created account into a Facebook test account. Again, do not execute these steps on your “real” user account.

After confirming that you want to convert your account into a test account, you should see the following message :

Facebook Application

Next step is to create a Facebook application. Integration with facebook is based on OAuth 2.0 and requires your to register a Facebook application. Visit the Facebook Developers Authentication page for more information on its OAuth 2.0 implementation.

The Facebook application that we’ll create will have it’s own Application ID that we’ll use in our Android application.

Creating an application cannot be done on the Facebook test account, so you’ll need to have a proper Facebook account in order to create the application. Using your “real” Facebook account, goto the Facebook Create Application page and create your application.

Give it a name, and complete the registration. You should land on a page like this :

So far so good, everything is setup on the Facebook front, now it’s time to start coding our Android application.

On the Android front, we’ll use the Facebook Android SDK located at Github : https://github.com/facebook/facebook-android-sdk
The Facebook Android SDK is licensed under the Apache License and is completely open source.

The project contains several samples in the examples folder, but the core SDK is located in the facebook folder. The sample application included in the facebook sdk repository provides the user the ability to post a message on the wall using a custom dialog, allowing the user to enter some text. The goal of the sample application that we’ll be creating here is to send an automated message to the wall, without any human interaction. Our application will generate a piece of text and post it on the wall without showing a dialog to the user. The user simply presses a button, and the generated message will appear on his/her wall.

But to get started, we’ll begin by importing the facebook project (containing the actual facebook sdk) into Eclipse. Once this is done, you should have the following Eclipse Project in your workspace :

As this is the library project that our sample application will use to do the actual Facebook integration, we’ll need to create a reference in our own project to this Facebook Android SDK project. This is done by going to our project properties, select Android on the left, go to the library section and click Add.

On the following screen, you can select the Facebook Android SDK library project

When selected, it will be made available to your own project.

As you can see in the Eclipse Package explorer, our sample project now also contains a reference to the Facebook Android SDK project

The Facebook SDK project revolves around a central com.facebook.android.Facebook.Facebook class, allowing you to perform various calls to Facebook. It provides basic login/logoff functionality (by leveraging single sign on capabilities if you have the official facebook app installed), handles the OAuth integration, and provides you with a generic API to perform requests to the various Facebook APIs.

In our own sample application, we’ll encapsulate all the Facebook interactions in a FacebookConnector object. The object is constructed like this

	public FacebookConnector(String appId,Activity activity,Context context,String[] permissions) {
		this.facebook = new Facebook(appId);

		SessionStore.restore(facebook, context);
        SessionEvents.addAuthListener(mSessionListener);
        SessionEvents.addLogoutListener(mSessionListener);

		this.context=context;
		this.permissions=permissions;
		this.mHandler = new Handler();
		this.activity=activity;
	}

As you can, under the hook, our FacebookConnector class uses the Facebook class provided by the Facebook SDK project.

Our FacebookConnector will provide a more coarse-grained API than the Facebook class. The Facebook class is designed in a very generic way, allowing you to do a lot of different calls to Facebook. This design results in a fairly fine-grained API, where some knowledge is expected from the application using this API. For example, you’ll need to know the specific endpoints for post a message on a wall, or to retrieve a user profile. In addition to that, you’ll also need to know what parameters you need to send for each request.

Our FacebookConnector exposes a coarse-grained method called postMessageOnWall that’s the main logic behind our Post button. The only thing we need to provide is the actual message we want to post. The FacebookConnector will do the necessary plumbing towards the more generic Facebook class.

The postMessageOnWall method checks if we have a valid Facebook session (meaning we have authenticated properly against Facebook). If this is the case, it setups up the necessary parameters, and does a call through the Facebook class to post a message on the wall. (using the me/feed endpoint)

	public void postMessageOnWall(String msg) {
		if (facebook.isSessionValid()) {
		    Bundle parameters = new Bundle();
		    parameters.putString("message", msg);
		    try {
				String response = facebook.request("me/feed", parameters,"POST");
				System.out.println(response);
			} catch (IOException e) {
				e.printStackTrace();
			}
		} else {
			login();
		}
	}

But we’ll start by explaining what happens if the user doesn’t have a valid Facebook session.

If the user hasn’t authenticated to Facebook yet we need to perform a login. The login() is defined like this :

	public void login() {
        if (!facebook.isSessionValid()) {
            facebook.authorize(this.activity, this.permissions,Facebook.FORCE_DIALOG_AUTH,new LoginDialogListener());
        }
    }

The login method is implemented in such a way that when we don’t have a logged in user, we call the facebook.authorize to start the Facebook OAuth flow. Although the Facebook SDK has a single-sign-on option, allowing you to leverage your existing facebook session you may have with the official Facebook Android application, we’ll add the Facebook.FORCE_DIALOG_AUTH parameter to have the Facebook SDK pop the login dialog.

The first thing that will happen when executing this method, is that the Facebook login dialog will be shown. Notice how the login dialog mentions the Facebook app we created earlier. By passing on our Application ID to the Facebook object, the user is now informed that the TestAndroidIntegration application is initiating the Facebook login. The user can decide at this point if he wants to login to his Facebook account.

When the user does a login, he’ll be presented with yet another dialog. Keep in mind that at this point, although the user is logged in, he didn’t give any permissions yet for this application to post messages on his wall. This particular dialog will now request the user for certain permission.

It basically allows the user to authorize the TestAndroidIntegration application to access basic information and Post to my Wall. Accessing basic information is the default permission that is given when a user logs in this way. Here, an additional permission is requested (Post to my Wall).

In order to post something on the wall, the publish_stream permission is required, hence we pass this on to our FacebookConnector :


	private static final String FACEBOOK_APPID = "PUT YOUR FACEBOOK APPID HERE";
	private static final String FACEBOOK_PERMISSION = "publish_stream";

	facebookConnector = new FacebookConnector(FACEBOOK_APPID, this, getApplicationContext(), new String[] {FACEBOOK_PERMISSION});

Note : ensure that you provide a proper Facebook APPID here.

When the user allows this request for permission (authorization), the Facebook API can begin executing requests on behalf of the user (like posting something on his wall).

Posting a message on the Facebook wall

In order to post a message on the wall, we basically construct a message (Bundle) that we pass on to the facebook request method. We use the “me/feed” ID on the Facebook Graph API to indicate that we’ll be posting something to the Profile feed (Wall in Facebook terminlogy).


	private FacebookConnector facebookConnector;

	private void postMessageInThread() {
		Thread t = new Thread() {
			public void run() {

		    	try {
		    		facebookConnector.postMessageOnWall(getFacebookMsg());
					mFacebookHandler.post(mUpdateFacebookNotification);
				} catch (Exception ex) {
					Log.e(TAG, "Error sending msg",ex);
				}
		    }
		};
		t.start();
	}

The postMethodOnWall() method is called from our main Activity in a background thread. Although we don’t want to interrupt the main UI thread while posting the message (hence the background thread), we do want to send a notification to the user that his message was posted. We use a handler for this in order to show a Toast message on the main UI thread once the background processing has been done.


	private FacebookConnector facebookConnector;

    final Runnable mUpdateFacebookNotification = new Runnable() {
        public void run() {
        	Toast.makeText(getBaseContext(), "Facebook updated !", Toast.LENGTH_LONG).show();
        }
    };

An importing thing to note is that when the user clicks the Post Message button, besides logging just logging in, we also want to send the message to the Facebook wall. Performing the login, immediately followed by an action (in this case sending a message) can be done by adding a AuthenticationListener (SessionEvents.AuthListener) to the SessionEvents.

The following code (wrapper method) illustrates this :

in case of logged in user simply post the message in the background thread.
in case of an anonymous user, we wait for the authentication to succeed, and then continue on to posting the message in the background thread.

	public void postMessage() {
		if (facebookConnector.getFacebook().isSessionValid()) {
			postMessageInThread();
		} else {
			SessionEvents.AuthListener listener = new SessionEvents.AuthListener() {

				@Override
				public void onAuthSucceed() {
					postMessageInThread();
				}

				@Override
				public void onAuthFail(String error) {

				}
			};
			SessionEvents.addAuthListener(listener);
			facebookConnector.login();
		}
	}

The clearCredentials() method is responsible for logoff functionality. All credentials are cleared from the system, and each interaction with Facebook will again trigger a login().

	private void clearCredentials() {
		try {
			facebookConnector.getFacebook().logout(getApplicationContext());
		} catch (MalformedURLException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}

Conclusion

The Android Facebook SDK provides an easy way to integrate Facebook into your Android application. It provides single sign on capabilities, preventing the user from having to login again if a session was already established with Facebook. Also, the OAuth 2.0 implementation that Facebook offers enables a much simpler authentication / authorization mechanism that with traditional OAuth based providers. After having setup the test account to do your testing, you should be up & running with facebook in your application in no time.