Google OAuth on Android using AccountManager

Implementing a proper OAuth flow on Android is a lot more complicated than it should be. Either you use a custom WebView (sucks for the user, because it doesn't autocomplete his usernames and passwords) or register your app for a certain URL-scheme ("myoauthcallback://..."), which is a really strange (and hijackable!) solution.

The solution is Android's AccountManager! At least if you're trying to authorize to a Google service which supports OAuth (most of them do, thankfully). I think Twitter supports the AccountManager too, but that's semi-official I guess...

Anyway, here's a really simple implementation of an activity which 1. asks the user for the Google account to use for authentication and 2. requests a token for that account. It handles some of the common gotchas during the authentication / authorization "dance", but it doesn't handle things like missing connectivity, etc.

PS: If you want to request multiple scopes, provide them as a space-separated list, like this: "oauth2:https://www.googleapis.com/auth/glass.timeline https://www.googleapis.com/auth/userinfo.profile"

If you want to read more about the AccountManager, check out the official docs here.

Uploading a File to AppEngine from Android (without any additional libraries!)

This is going to be a really short post. Recently I had to upload a file from an Android app to an AppEngine server. Most people recommend using third-party libraries, like Apache's HttpClient for that purpose. However, this increases your app's size unnecessarily if you really only want to upload a file to a server. (I think it was an increase of about 1MB). Thankfully, Android already includes (old) parts of Apache's HttpClient, which you can easily use. This won't add anything up to your app's size obviously, because you're using libraries already included in the system.

Here's the code for you:

GTalk on Android using Smack, OAuth and AccountManager

Google finally released an API to authenticate to GTalk using OAuth a few months ago. This is great, but it makes it even harder to use GTalk in your app. However, it obviously increases the usability a thousand times (especially for users with 2-step-authentication enabled) so you should definitely use OAuth if you plan to release an app which uses GTalk.

You can find the full source for a project using these techniques here: github.com/TomTasche/joppfm.droid, but I also extracted the parts that really matter into a Gist here:


The library used for XMPP connection is a fork of Smack, called aSmack. It's a patched and tweaked version of Smack for Android.

Nice little bonus: you receive a notification for every new mail that ends up in a user's inbox. For more information on how to use that please refer to the code located in this folder: github.com/TomTasche/joppfm.droid/src/at/tomtasche/joppfm/xmpp/gmail

Routing things and stuff

Unfortunately I'm pretty bad at mathematics, but there's one thing that makes me wish I would know more about it: programming (of course). People who don't know a lot about programming always think that you have to be a mathematics-pro if you want to program: that's not true at all! Of course it highly depends on the things you want to create, but for things like a "normal" Android app you barely have to do any math.

For more sophisticated stuff you'll probably need to do some calculations sooner or later though. The first time I worked for indoo.rs (actually, my first job as a developer ever) I had the pleasure to implement a routing algorithm. A what!? I had absolutely no clue about that stuff when I started working for them. However, I wanted to do my job as good as I can and started reading Wikipedia articles in both German and English to get an idea about how routing algorithms (and in this case A*) work and how to implement them.

What I want to share with you today is an implementation of some routing algorithm I implemented a few days ago. It's a mixture of everything I still remembered from a few years back when I had to implement routing for indoo.rs. I think it's best described as a depth-first, kind-of-dijkstra thing.

The challenge in my case was that I had to implement an algorithm which routes between... things. Of course I can't go into detail about what the "things" are, but it comes down to this: the algorithm had to find a path between points, which are no points in the common sense (they have no coordinates or similar, just a name and connections to other points). So, to be very specific, the points were simply represented by a String, and I knew which point is connected to another point. Of course that means we can't use a full-blown A* algorithm, because it needs some kind of heuristic (for example the distance between two points) - which I didn't have.

So here it is. Let's call it EinStern, okay?


If there's any question or problem using this I'd love to help you in the comments.

Google Apps Script revisited: still crap if you're using it wrong

You probably read my first post about Google Apps Script, which described my (mostly) bad experiences while experimenting with it. Well, I might have been wrong. Not that Google Apps Script is not slow - it is! - but maybe that doesn't even matter.

If you want to know why I think Apps Script is so slow, check out the previously mentioned post, or simply take a look at this script (exactly the same I used 9 months ago, by the way). On a cold start, the script takes about 10 seconds to load. That's horrible. Loading my blog doesn't take that long, even though it contains a ton more content than this simple script. Moreover, the UI is quite unresponsive (input some text and click "search uss!"). To be honest, this is simply because there's virtually no client-side logic - which means that clicking the button sends a request to the server what to do next. That's the way Google Apps Script is designed, and I think this makes things for people who aren't experienced developers a lot easier.

I love your inner values

So, what about the "inner values" of Google Apps Script, then? It offers quite a big range of built-in APIs to access and modify data from Google services - ranging from Drive, to Gmail (yes, an API for Gmail!), to Analytics, Tasks, Calendar, and so on... That's pretty impressive and I think that's the real value of Google Apps Script. You don't want to use this to create stunning web apps, but you want to use this for organizing and analyzing your data stored in various Google services.

GmailArchiver

A few weeks ago some random lawyer asked me to create an application using Apps Script for him, which archives all mails in a specific label into a spreadsheet. "Peanuts", I thought and gave it a try. A few days later I had finished GmailArchiver. Thanks to the APIs built into Apps Script this was not hard at all. The only thing that gets into your way when developing for Apps Script again and again: a single execution of a script isn't allowed to last longer than X minutes (I think it's five minutes Apps Script specialist +Sergii Kauk says your script is allowed to run for 6 minutes). Therefore you have to prepare your script to get killed at any time and resume it a few seconds later at the same progress. You can see the actual implementation in the script, but it comes down to a Trigger which triggers execution every 5 minutes so your script can resume at the last known state.

The point is: it doesn't matter how slow Apps Script performs in this case, because it's doing the job without any user interaction. When it's done, it sends an email to the user telling him where to find the archived mails.

By the way, that guy who actually requested this script never replied, so all the time I spent on this is wasted time. :'( That's what you get for working with lawyers...

StackUnderflow

Another script I made, which doesn't access data on Google services at all this time. It's a simple utility which translates the StackExchange API into a RSS feed. In my case, I wanted a feed for featured (android-tagged) questions and another feed of unanswered (android-tagged) questions. Again, it doesn't matter how slow the RSS feed is being created, because it's only requested by some RSS aggregating server (RIP Google Reader :'().
You can find these scripts here and here.

DriveCleaner

Aaand one more: a script which deletes all files matching the specified regular expression. Particularly useful if you want to get rid of unintentionally uploaded hordes of .class-files. Use with caution. You can find the script here.

TL;DR

Google Apps Script is cool. Just don't use it for creating web apps / mobile apps / or any other app outside of spreadsheets.