How to Get OAuth Codes to Talk to the Twitter Server with Your Android App
For your Android app to communicate with Twitter servers, you need your own OAuth codes. To get them, follow the simple steps listed below and you will be on your way to developing your own Twitter app.
Twitter might change the design of its website at any time without notice.
Sign in to your Twitter user account (or register for an account if you don’t already have one).
Visit Twitter’s app developer page.
If the stars are aligned harmoniously, you should see Twitter’s Create an Application page.
On the Create an Application page, fill in all required fields along with the (misleadingly optional) Callback URL field.
When you visit the page, you see the Name field, the Description field, the website field, and the Callback URL field. All but the Callback URL field are listed as being required.
Making up an application name (for the Name field) isn’t challenging. But what do you use for the other fields? After all, you aren’t creating an industrial-strength Android app. You’re creating only a test app — an app to help you see how to use Twitter4J.
The good news is that almost anything you type in the Description field is okay. The same is true for the website and Callback URL fields, as long as you type things that look like real URLs.
To communicate with Twitter via an Android app, you need a callback URL. Neither the website field nor the Callback URL field has to point to a real web page. But you must fill in those two fields.
Using OAuth, you can log a user into Twitter through a web browser. When the log in is successful, the user’s browser visits a particular page, and that page’s URL is the callback URL.
The Callback URL field isn’t marked as being required. Nevertheless, you must type a URL (such as http://www.example.com) in the Callback URL field.
After agreeing to the terms, and doing the other stuff to prove that you’re a good person, click the Create Your Twitter Application button.
Doing so brings you to a page where you see some details about your new application — the Details tab, in other words. For this example, the two most important items are your app’s access level and its consumer key.
In the OAuth world, an app whose code communicates with Twitter’s servers is a consumer. To identify itself as a trustworthy consumer, an app must send passwords to Twitter’s servers. In OAuth terminology, these passwords are called the consumer key and the consumer secret.
On that same web page, select your application’s Permissions tab.
In the Permissions tab, you see a choice of access types.
Change your app’s access from Read Only (the default) to Read, Write and Access Direct Messages.
For this toy application, you select Read, Write and Access Direct Messages — the most permissive access model that’s available. This option prevents your app from hitting brick walls because of access problems. But when you develop a real-life application, you do the opposite — you select the least permissive option that suits your application’s requirements.
First change your app’s access level, and then create the app’s access token (as explained in Step 9). Don’t create the access token before changing the access level. If you try to change the access level after you’ve created the access token, your app won’t work. What’s worse, the dev.twitter.com page won’t warn you about the problem.
Click the button that offers to update your application’s settings.
Doing so changes your app’s access level to Read, Write and Access Direct Messages.
On that same web page, select the Keys and Access Tokens tab.
After selecting that tab, you see some new stuff on the page.
Click the Create My Access Token button.
After doing so, your app’s Keys and Access Tokens tab displays your app’s access token and the access token secret, in addition to your app’s access level, consumer key, and consumer secret.
Copy the four codes (Consumer Key, Consumer Secret, Access Token, and Access Token Secret) from your app’s Details tab to the appropriate lines in your app’s main activity.