Install the Salesforce Chatter for Android App on Your Phone

Jeff Douglas

Salesforce.com invited me to attend Cloudforce last Tuesday to demo my Salesforce Chatter for Android app. The reception was incredible and there is a big push to get a Salesforce.com app running on Android. Parker Harris (Co-founder & EVP, Technology) even made the statement in the keynote that, "I do have a team working on a native Android Chatter application that will be out later this year....". At that point, Narinder promptly tweeted:

Well that created a lot of buzz so over the last couple of days I've had an amazing number of people email, tweet and post chatter asking me how people can run the Chatter for Android app on their own phones. I checked with Kris Muller at salesforce.com and we've decided to let anyone install the app and try it out. The functionality is limited (you can only view the Chatter feed and post an update) and it is connected to a DE org so you can't really screw anything up.

So here's a little background and how it started. The application is combination of the Force.com platform, Google App Engine and a Google Android mobile handset. It utilizes Force.com Remote Access Applications with 3-legged OAuth for security allowing App Engine to fetch chatter feeds and post new status updates using the Force.com Web Services Connector running on App Engine. The Google App Engine app runs at https://chatter-android-demo.appspot.com.

The Android client makes a request to refresh it's chatter feed and makes a call to this endpoint on App Engine. The WSC queries Salesforce for the chatter feed and returns the feed as a series of JSON objects. The Android client consumes the JSON objects and stores them in the local SQLite database. When the feed list is displayed on the Android client, the images are download lazily from App Engine when needed. You may see a slight lag while new threads are spawned and the images are downloaded. If the images do not display quickly, try scrolling through the list back and forth for them to display. Part of the roadmap is to store these images in the local database instead of downloading them each time.

Installation Instructions

To install the app on your own phone:

• Download either the original 2.1 application or a 1.6+ version that runs on older handsets to your desktop
• On your phone, install eoeAppInstaller from the Android Market.
• Mount your phone to your computer via your USB cable so that you can access the SD card on your phone from Finder.
• Drop the .apk file into the root of your SD card
• Unmount your phone and disconnect your USB cable
• Go to Settings -> Applications and check “Unknown Sources” to allow installation of non-Market applications
• Launch eoeAppInstaller and it should display the Salesforce Chatter app
• Long press the app and select "Install this apk"

When you launch the application, simply click anywhere on the white Android/Chatter logo to display the chatter feed. The first time you run the application there will be no chatter updates. You will need to hit Menu -> Refresh to populate the local database with updates. The app is currently set to only return the last 15 updates. The app runs as the user Scott Thompson and you cannot switch to a different user.

If you want to see Salesforce come to the Android platform, please vote for this idea.

Install Google GO on Mac OS (Snow Leopard)

Google GO is a systems language Google uses on it's own production instances. It's nearly as fast as C++, has garbage collection, and can handle thousands of concurrent "routines". When we started with GO, we followed the installation notes, but noticed a few other steps that needed to take place as well. We hope you find this walk through helpful.

Disclaimer: Hey, this is Appirio, right? Why a systems language? What's that have to do w/ Cloud? The GO team is working w/ the Google App Engine team (no release date yet) and it already has huge ramifications on EC2 environments... we think it'll be a major player down the road. Always healthy to stay ahead of the curve.

Prerequisites:
- Python (Mercurial requires Python)
- Mercurial (Source Control Management)
- XCode
- ~/bin directory with 755 permissions. (mkdir ~/bin then chmod 755 ~bin)

Here's how to check your prerequisites, for reference:

Kyle-Roche-MPB:~ kyleroche$ python -V
Python 2.6.1

Kyle-Roche-MPB:~ kyleroche$ hg version
Mercurial Distributed SCM (version 1.5.4+20100601)
Copyright (C) 2005-2010 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Kyle-Roche-MPB:~ kyleroche$ xcodebuild -version
Xcode 3.2.2
Component versions: DevToolsCore-1648.0; DevToolsSupport-1631.0
BuildVersion: 10M2148

Adjust .bash_profile
Add the following code to your .bash_profile. If you don't have one, create it in your ~ directory.

export GOROOT=$HOME/go
export GOOS=darwin
export GOARCH=386
export GOBIN=$HOME/bin
export PATH=$GOBIN:$PATH

Here's how to check your profile, for reference:

Kyle-Roche-MPB:~ kyleroche$ source .bash_profile

Kyle-Roche-MPB:~ kyleroche$ env | grep ^GO
GOBIN=/Users/kyleroche/bin
GOARCH=386
GOROOT=/Users/kyleroche/go
GOOS=darwin

Pulling down the source package:
You can use Mercurial to pull down the package from Google Code. Run the following command:

Kyle-Roche-MPB:~ kyleroche$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
requesting all changes
adding changesets
adding manifests
adding file changes
added 5632 changesets with 22984 changes to 3660 files
updating to branch default2215 files updated, 0 files merged, 0 files removed, 0 files unresolved

Compile the package.

Final step... change to the $GOROOT/src directory. Run the following command:

Kyle-Roche-MPB:src kyleroche$ ./all.bash

There's way too much output to be useful copying to this article. I noticed a different set of output then described in the installation guide. I think the safest way to test if it was successful is to go ahead and follow the Hello World example. If you're confident that existence = success, you can always run which 8g or which 8l. Both of those files exists after the language is compiled.

Salesforce Chatter for Android

Jeff Douglas

This is an overview and demo of the application that I submitted for the Chatter Developer Challenge. It is a Salesforce Chatter for Android app running on a combination of the Force.com platform, Google App Engine and a Google Android mobile handset. It utilizes Force.com Remote Access Applications with OAuth for security.

The Android application has the following functionality:

• Display your Chatter NewsFeed
• Update your User status
• Refresh your Chatter NewsFeed and store it in the local SQLite database
• Choose a project (custom object) that you are following and view its Chatter Feed
• Update the project’s status
• Refresh the Chatter Feed for the project (including field changes to the record) and store it in the local SQLite database

The app does not include the functionality to reply to posts. Since Chatter is running in a Developer Edition and they are only allowed to have 1 user, it seemed rather pointless to respond to my own posts.

Here are some screenshots of the application in case you want to skip the video.

I use Google App Engine to tie all of this applications together and provide a coherent security model. So I wrote a small App Engine app that uses 3-legged OAuth to authorize access to Force.com and my Chatter feeds using Force.com Remote Access Application. Once authorized the Force.com Web Services Connector, running on App Engine, performs the interactions with SFDC such as submitting new status updates, fetching my feeds and displaying them as JSON objects.

App Engine recently started supporting 2-legged OAuth in combination with Google Accounts so that any App Engine application can become an OAuth service provider. Since OAuth support is baked into the Android platform I tried to hook up the Android handset as an OAuth consumer but could not finish in time to submit my entry to the Developer Challenge.

Since Android doesn’t play well with SOAP-based Web Services I think this approach in combination to JSON makes an appealing option. If you have any ideas, I’d love to hear them.