This is part 5 of a 5-part series on introductory Android development. If you’re just arriving, you should head on over to Part 1. Warning: While the general ideas and Android-specific code contained here still apply, the Twitter-specific portions are now outdated thanks to the so-called “OAuthocalypse,” Twitter’s phasing out of HTTP basic auth.
In Part 4, we dug into accessing our Views from our Activity’s code, and registered an OnClickListener to handle the user’s interactions with our button. In the final part (a big one!) we’ll cover using J2SE libraries, debugging, and Android permissions.
So far we’ve gotten a lot done without too much “boilerplate” coding, and that’s great. But what we don’t have (yet) is an application that leaves its mark on the world. After all, what’s a Twitter application if people can’t benefit from your 140 characters of deep, meaningful insight into the state of the world (or what you ate for breakfast)?
On the shoulders of giants
One great thing about Android is that you have access to a full J2SE stack. That means you can take advantage of lots of libraries other suckers wonderfully generous people have already written. There are some caveats — code using some kinds of runtime code modification / introspection or deep JVM voodoo won’t work properly under Dalvik, for example — but many simpler libraries can be partially reused or just dropped in wholesale in JAR form. For twitter, there’s a great super-light library called JTwitter, released with an LGPL license. Go ahead and download that now — I’ll wait.
Done? Great! Put the .jar file into your project. I’ll create a /lib folder in our project and drag the file there, but you could also keep it in a totally separate folder on your computer to be linked as an external .jar in the project. Then go to Project -> Properties and add the .jar file (add as an external if you’re keeping the .jar outside your project’s folder). And that’s it — Android’s SDK tools take care of turning the compiled code in the .JAR file into proper Android Dalvik bytecode behind the scenes.
Now let’s wire that Twitter code in.
Add at the top of the Activity class:
1 2 | public static final String TWITTER_USERNAME = "someusername"; public static final String TWITTER_PASSWORD = "somepassword"; //this is a very bad idea for a real product. |
And add to our onclick handler right before popping up that Toast:
1 2 | Twitter twitter = new Twitter(TWITTER_USERNAME, TWITTER_PASSWORD); twitter.updateStatus(twitterStatus); |
(Again, you’ll get easily-corrected missing-import errors – let Eclipse autofix that for you by importing winterwell.jtwitter.Twitter).
Advance warnings
Cool – before we run it, though, here’s 3 big caveats/notes:
- For the purposes of this demo, I’m hardcoding a password into my file. Don’t do this. You probably want to use OAuth, or at least prompt the user for their password and store the encrypted version somewhere.
- This is running in the same thread as your UI. This makes your app hang during the operation, and could lead to the user being prompted to end your app for being unresponsive (the dreaded “ANR” dialog). For a real app, you’d run the twitter-posting in a separate thread or as a background service, but that’s outside the scope of this tutorial.
- This actually won’t work yet – trust me, I’m showing you how to debug things. Pretend to be surprised, though.
Go ahead and run the app in debug mode in the emulator (run -> debug -> Android Application). When it loads up, type in a message and click the Tweet! button.
Click 'Tweet!', and then...
You’ll find yourself rudely thrown back into Eclipse with this error message:
Oh no!
When things go wrong
Whoops! So your code isn’t doing what you expect — and worse yet, it blows up and crashes – hard. Once upon a time you’d have to know a series of arcane serial debugging commands to get anything resembling useful output from a mobile phone application. But thanks to the magic of DDMS (Dalvik Debug Monitoring Service), debugging your code is as minimally painful as anything I’ve used until now, and is *actually* less painful than a root canal! Let’s step through the Perspective you get thrown into in Eclipse.
The debug perspective
You’ll notice you can use the Debug panel to view the current state of our application as well as any variables. You can also see the Logcat error messages, which are generated by various application and system events (you can create your own using the android.util.Log library). Right now the only relevant log entry says “InetAddr Unknown host twitter.com,” which isn’t really helpful, but the execution has been paused to let us inspect the code behind that top-level error.
We can resume execution through the exception to the next line of code causing it. Usually this can get you a more detailed error message, and you can even inspect the code and variables at each step. Try it now (it’s the button that looks like “Play” on a tape deck — yes, I said tape deck; so I’m dating myself a bit), and notice the log messages scrolling at the bottom (you might have to click Resume a few times to get the right level of detail).
That's much more helpful.
You can use the Logcat view’s controls to filter error messages by severity or tag if there’s a lot to sort through — in this case, though, a little reading makes the culprit fairly obvious. We never told the app that it needs to ask for Internet access permissions!
Let’s go back and add that to AndroidManifest.xml. Again, you can use the XML wizardy-view to go to the Permissions section and add Uses Permissions -> android.permission.INTERNET, but if you’re old-school or just prefer a good text edit, add this line to the <manifest> node (usually as the last thing before </manifest>):
1 | <uses-permission android:name="android.permission.INTERNET"></uses-permission> |
Now when your users install this app, they’re warned once on installation that your application will access the Internet (but never again after that).
Go ahead and run one more time, filling in a message:
Now with 100% fewer Exceptions!
And check out our test Twitter account:
It worked!
Hooray!
This concludes the tutorial – but hopefully just starts your Android development experience. Go ahead, start making an app of your own!
To get started (or in case you got lost during this tutorial) you can download the source of the application we’ve built. You can also comment away if you have any questions or feedback on the tutorial.
If you just want to bang around with some more advanced development techniques without starting from scratch, here are some ways you could improve the current app:
- Use the AsyncTask class or a Service to make the updating happen in the background instead of locking the UI
- prompt the user for a username/password on first use, using a Preferences activity (easy way: Preferences from XML)
- Handle network failure gracefully.
- Display a progress bar / loading spinner while tweeting.
- Display updates from the users’ timeline in a ListView.
- use an AlarmService to update the Timeline in the background, displaying a notification to the user
- Cache tweets to an SQLite database or a flat file on the SD card
- Use the Location services and the reverse-geocoder classes to tweet your location
I’ll also be posting a more advanced tutorial on AppWidgets (homescreen widgets) soon – so subscribe to the Active Frequency blog in your RSS reader.
Tags: android, twitternator-tutorial
Pingback: Ground-Up Android, Part 4: Writing the Code « Active Frequency