The content of this post relates to version 1.12 of Twitter's Android APIs (which were the latest versions at the time of publishing)

One of the most annoying things that I have encountered as an engineer is those situations whereby you encounter an issue which you are adamant that you have encountered before yet cannot remember how to fix.

I had one of those moments today when utilising Twitters Fabric APIs for Android.

My issue was not a bug, but rather a missing piece of functionality (bad Twitter !).

onActivityResult

It is well known that in an Android application when you call startActivityForResult the result is received in the onActivityResult method of your Activity.

If you call it from a Fragment (fragmentInstance.startActivityForResult), the Activity will pass the call to its onActivityResult method onto the Fragment IF you make sure to call super.onActivityResult within the Activities implementation. This is all handled by the Android framework, and is extremely useful when building Fragment based applications.

Unfortunately Twitter's API does not provide an authorisation endpoint which executes from a Fragment context. If you take a look at the TwitterAuthClient source code you will see that they have a method authorize which takes an Activity context but not one which takes a Fragment context. As such you have to handle passing the onActivityResult call from the Activity to the Fragment yourself.

This is not the end of the world, but it is such an easy thing to implement that it is really bemusing as to why Twitter have not implemented such a method. It would be somewhat OK had they provided concise and clear documentation for utilising their API but sadly all they provide is a very basic overview of how to use their widget-esque offerings (namely TwitterLoginButton). If you want any kind of customised Twitter login experience (who doesn't), then you are on your own.

What is your requestCode?

As if that wasn't bad enough, to be able to implement such functionality in a safe and consistent manner (that is future-proofed from API updates) you need to know the request code which Twitter is using to 'start its Activity for a result'. It just so happens that the request code is 140, but were you not aware of that you'd have to find out somehow so as to discern when to pass calls to onActivityResult onto the Fragment interacting with Twitter's APIs.

I could not find this information in their documentation - once again I had to look in the source. The value is defined in a static property TwitterAuthConfig.DEFAULT_AUTH_REQUEST_CODE. The naming convention of the property suggests that as it is a default there would be some way to change it. There is not.

There is a getter on the TwitterAuthClient class - getRequestCode, but that simply calls a method on TwitterAuthConfig which returns the hard coded value '140'. The getter doesn't even use the constant :)

OK, I am sorry

All things considered, these issues are not particularly significant. My problem is that Twitter is a massive company with a really large engineering team.

They have built Fabric (which on the whole is an amazing product) which allows me to build applications on multiple platforms to interact with Twitter (which is itself an awesome platform). They (I suspect) built this product to make it easy for app developers to integrate with their services so as to grow their own user base and increase their social impact.

Given that, I cannot get my head around the idea that you'd build a complete and feature rich API and then miss out some simple but incredibly useful functionality that contradicts generally recognised patterns for the platform you are targeting. Weird.

Documentation

As I alluded to above, the Twitter API documentation is somewhat lacking. I guess that they want you to use their widgets rather than implementing custom flows.

It is however (in my opinion) completely reasonable to expect developers to want to implement custom flows, and for the same reasons outlined above I do not see why they have not invested the small amount of required time in improved documentation so as to aid developers in integrating their products with Twitter.

So..

Hopefully someone at Twitter will see this and share some insight as to why they have written their Android APIs in this manner.

What are your thoughts? Am I just being unreasonable and ungrateful?