Tensory Labs

In continuing my mobile OTR work, I’m confronting a lot of the same issues that every dev team faces. This time, though, I am an army of one. Keeping my own work straight has brought me to a couple of best practices:

• Commit early and often. Git was made for this. When I first started out as a developer, I was using SVN, and commits to even a working branch were considered a big deal — committing a work-in-progress that didn’t even necessarily run without barfing errors was unacceptable. With Github and Bitbucket on the table, and git and Mercurial both allowing local commits against a personal working copy with the option to push later, you can make as many mistakes as you need to without damaging your trunk.
• Diagram dependencies as simply as possible. The dependency chain to build this app looks something like this, from highest-level to lowest:
  • JavaScript UI (jQuery, jQMobile, or maybe xUI)
  • JS class that connects to OTR library
  • JS class that connects to XMPP library
    (I’m using Strophe as the world’s simplest XMPP connection library for JS. Works fine in a dev context. For XMPP running on the device, it seems wiser to connect to a native library that correctly positions the phone as its own origin server. So eventually, I get to write wrappers for Smack and xmppframework.)
  • Phonegap JS
  • Java plugin for OTR library
  • Java plugin for XMPP library
  • Obj-C wrappers for OTR and XMPP on the iOS side! (Lest we forget…)
  • Phonegap compile-time includes, to make it all run.
• Distribute your non-code reference material. Delicious is a good link repository for the many, many Stack Overflow results and Phonegap tutorials that I’ve googled in the last two weeks. I also have a /ref directory in my code base that contains some searchable text files with things like sample XMPP stanzas. Beats re-running a simulator or re-searching for the same result, or littering comments with examples.
• Find out the distribution terms of any libraries you plan to include. This might be painfully obvious, but I spent a good hour facepalming after a conversation like this:
  Someone on IRC: You should really use libpurple as a connection manager to support multiple accounts.
  Me: Great idea! I’ll get right on that. *download read design design*
  Someone else: Apple doesn’t allow apps with the GPL license in the App Store, and libpurple is GPL’d, so using it would disqualify you from distribution by Apple.
  Me: Well, then I guess this will only support exactly one XMPP account, because I have far too much else to do to reinvent a multisession manager.
  — fin —

  There’s a tangent conversation to be had here about why, exactly, having the option to accept virally-open source code is an ideological problem for Apple. They do permit open-source apps under less aggressive licenses, and the GPL doesn’t prohibit charging money for one’s app as long as it’s also distributed for free, so no problem there. I can think of two possible explanations: they want to insulate themselves from any possible interpretation that the App Store itself would be included in a GPL’d package, and, more likely, FLOSS sentiment doesn’t jibe well with their models for profit and control. And we want to develop for the App Store nonetheless because that’s where the user base actually is. Well played, but a frustrating barrier to the self-same dev community that’s so enthusiastic to contribute to the market.

• Know the limitations of your toolchain. Phonegap has a pretty great API for phone events. It does not have an XMPP library — many people on various Google Groups have requested one. Personally, I think it makes sense that it doesn’t, since sending and receiving IMs isn’t a common device feature in the same context as a tilt sensor or a received-call event. It’s just necessary to find out from API docs and READMEs whether your new tool can actually solve the problem at hand.

That mobile chat application I was contemplating a few weeks ago has officially taken over my brain. I’ve continued playing around with Gibberbot source, but I just can’t get past the sense that this tool should be unavailable to the iPhone crowd just because no one has time to develop it specifically for iOS.

Furthermore, the issues I’ve taken on in Gibberbot are things where I’m not sure what’s the best way to suggest patches, like the XMPP library. If you see an issue in an included library, is it best to switch to that project and make a patch for the include rather than fork it within your main project? Seems right, but that rabbit hole runs deep.

I’m currently trying on a Phonegap-based approach. I know how to write an interface in jQuery, and including the Java port of OTR as a plugin for Android no longer seems so scary. The Java port contains an interface called OTRCallback that offers to make the OTR functions available to whatever you choose to use for XMPP (I’ve got an installation of JSJaC semi-working), and that looks pretty awesome.

The scarier parts are these. One: redeveloping plugins for the other operating system(s) you choose to support with Phonegap (after all, the whole point is to spend less time becoming an iOS developer!) Two: figuring out whether the security features of any XMPP library for JS are appropriate for what is, at heart, a better-secured-communications platform.

Currently I’m stepping through an issue where XMPP from JS needs a source URL. Internet lore holds that Phonegap may be able to simulate a self-originating request (but don’t hold me to that; that’s just what I got from a couple of hours with Google Groups!) but I’d rather save hours of reloading the Android emulator and develop in a desktop, where request origin matters, and where I’m using a Mac running Apache. I’m unable to lock down a cogent description of whether Phonegap emulates its own server. This may kill the whole project, but it’s certainly taught me a whole lot about XMPP and Apache along the way.

Onward!

I’ve been longing for a usable mobile chat service that lets you send encrypted messages to folks using OTR with a desktop IM client like Adium. The Guardian Project is a (NYC-based?) group that produced Gibberbot to solve this for Android users.

I do use an Android phone, for the moment, but I’ve been having a lot of trouble running Gibberbot. Those of you in the iPhone camp are out of luck — it’s cleartext all the way down. Platform-dependence really bothers me, as a Web developer — and I’ve given the ol’ college try to dropping everything and learning a bit of iOS development, but honestly, it would take me several years and rather a lot of career-redirection to gain those chops.

So, what about media that runs on all devices?

The mobile web might be able to save you here, though the approach lacks the one-touch appeal of a real app. There are real security problems to solve, and you’d be better off starting from a proxied connection via Tor. Marco has done interesting work packaging Tor for iOS, and the Guardian Project takes care of providing Tor for Android.

I’m taking a stab at a web app that’s just as pleasant to use as a native app solution and runs on any platform. App lockdown is a serious problem on Android, and we need it before the platform wars end.