just a dude abiding

IntentChooser: my first PhoneGap/Cordova plugin

In the last couple of months I’ve done a fair bit of programming on iOS/Android/HTML & JS. I’ve also been experimenting a bit with PhoneGap/Cordova (I’ll call it Cordova from here on out). While playing with a Cordova application of my own I ran into the need for a native interaction that wasn’t possible with just PhoneGap. I wanted to display what is called an “Intent Chooser” on Android. This is a dialog that displays a list of applications that can be used to handle a specific user request. In my case I wanted to send a tweet using whichever application was installed.

Since I couldn’t find an easy method using the built-in tools, I thought I’d learn a few things and write the plugin myself. Creating a Cordova plugin is actually pretty simple, it’s a single class and a single JS file. I went a couple of steps further and made/modified a couple of build scripts to make the process easier. If you’re interested you can find that code in my Cordova Plugin Template Github repo.

The Intent Chooser plugin can also be found on Github. So let’s see a quick example of how this thing integrates into an application.

That simple code will pop up a native dialog, limited to apps with the name ‘twitter’ in them, and send the text ‘This is my content’. Since it calls a new Android Activity, there’s not much else to it. There are no callbacks, just fire and forget. In the near future I’d like to add support for sending binary data types like images as well, but I didn’t need them for my immediate use case.

If you find any issues, or have feature requests just file issues on Github.

Thoughts on Appcelerator Titanium

Appcelerator Titanium is a product that bills itself as the easy way to create cross-platform, native, mobile applications. It’s a lofty goal. After several months of development on a decent sized application, I can say that currently the platform falls short of meeting that goal, way short.

A promising start..

I was drawn to Appcelerator because of the idea of being able to write straightforward JS and get native widgets. This would allow me to focus on the logic of my application, and not making sure I hadn’t forgot to track the retain/release counts on my objects correctly. Initially I was able to make tremendous progress in mocking up the UI. Sure I don’t get the great Interface Builder, but with minor tweaks I can deploy to Android! What had taken me weeks to sketch out in Obj-c was taking me hours or days instead. Multi-level navigation heirarchies with back buttons? Easy! But shortly after I reached the end of mocking up my UI flow, I began running into trouble. The documentation for the platform was sparse, but seemed to be improving. If you got really stuck, you could look at the “KitchenSink” sample app to see how various components worked. This isn’t too bad, but progress is slowing…

It does what?

So the first clear sign of troubl was that I had to use a separate application (Titanium Developer) to build/launch/monitor my applications. There wasn’t (and still isn’t) a visible method to run an app from the command line, or even to just generate code to run from within XCode. Sure, Titanium Developer is a bit slow, a little clumsy, and not terribly stable, but the code is going so much faster it’s bound to be worth it. Surely it is. I was wrong. Titanium Developer rapidly became the bane of my existence. It’s only syntax/static checking is done via JSLint with a pretty arcane set of rules. Want to write one line if statements? That’s a warning. A for loop without checking for property existence? That’s a warning. Appcelerator’s own sample app generates hundreds of JSLint warnings. What use are warnings if they are too verbose to find real problems? Get used to missing a comma, or a semi-colon, and it going unnoticed in the sea of other warnings.

Once I settled into the fact that the Titanium Developer app itself is pretty brutal to work with, I moved onto the next set of troubles. The documentation is terrible. It’s a simple API doc, with almost no supporting code, and nearly useless descriptions for many properties. If you really want to know how a particular API or widget reacts, you have to look at the KitchenSink and hope your use case is covered. If it is covered, then you have to figure out how to work with the spaghetti nature of the sample app, and shoe-horn it into your app. If it’s not, then you’re off to the next giant pain, the community forum.

The idea behind the community forum is great, a place for users to ask and hopefully answer each others questions. Instead what you find are questions that are 6 or 7 months old, unanswered, full of “any update?” responses. The most common official responses are “please provide Titanium and platform SDK versions”, with no follow up. When there are solutions, or work arounds, they may no longer be applicable to the newer versions.

Minor platform versions routinely caused regressions in functionality (like grouped table views scrolling whenever the keyboard is present) while adding more ways for Appcelerator to make a dime (paid Modules), but without fixing persistent, core problems. Don’t get me wrong, they deserve to make some money off of their product, but leaving broken functionality in place for months with no expected resolution dates just doesn’t cut it. Some recent examples of major platform bugs: ‘swipe’ gestures not being handled correctly or consistently including in their own custom horizontal scrolling view, platform specific overrides not working on devices (but working fine in the simulator) on iOS. And more that I’ve probably blocked out for my own sanity.

Almost there…

I managed to suffer through all of this, I’d put too much time and effort into the app to give up yet. I’m too close to the finish line. I’d become used to the undocumented idiosyncracies (like event propogation failing if you add subviews after the parent view has been added, or image views that cannot be scaled in a logical fashion, strange positiong issues if setting both lef/right or top/bottom). It was time for some last minute bug squashing, and pushing the data off to beta testers! Thanks to the fantastic TestFlight we were able to gather a group of testers, and get our permissioning setup to be able to send them an ad-hoc build. Now all I have to do is get a clean, release build ready.

Great, Titanium Developer crashes everytime I try and create a release package. The builds take 5 or 6 minutes, have no stop button, and often hang the Titanium Developer UI. The only way to kill a build that’s already begun is to `killall xcodebuild`, which is certainly not documented. After waiting for the full rebuild (it doesn’t appear to cache ANY compilation steps), I am greeted with a large build log error. Usually about a failure to copy some file. The good news is that at this point Titanium Developer has generated a functional(ish) XCode project. Open it in XCode to find…it hasn’t set my distribution profile at all, it doesn’t seem to be targetting the correct platform, and in fact seems to be defaulting to a debug build. In fact some of the generated code seems to still be set to debug mode, must be a custom script that runs outside of XCode to fix that…

An hour of learning what isn’t set correctly in the generated XCode project and I’m finally building again. Replace a few missing files (default icon, and Default.png don’t seem to copy correctly), fight with provisioning profiles some more, and a build is finally made. Now I load the fresh beta release onto my device, and immediately find a bug that didn’t seem to appear in the simulator, curse loudly, and call it a night.

Lessons learned?

Middleware platforms are a great idea, in theory. In practice it means working through a vendor who is struggling to keep up with the underlying platforms, stuggling to support their paid customers (speculating here), and completely failing to support their free user base. There is practically no external community for the Appcelerator platform, no solid bare bones starter applications, gotcha lists, or much of anything else. It’s a community of people all fighting to get their project done, and get the hell out of the way. I’m sure they mean well, but things don’t look good.

I’m monumentally disappointed in the current state of the Appcelerator platform, community, and toolset, and have no plans on doing further development on the platform after completing my current project. I’m just going to cut my losses and either go back to direct native development, or forget native development alltogether and get with "PhoneGap"http://phonegap.com/

My Weekend Project

Once upon a time there was a website, a website that catered to the lowest of lowbrow humor. It was aptly named, lowbrow. Then, for no real reason, it vanished. Those of us who were fond of it made varying attempts to resurrect the bits of it that were available to us, and ultimately we all failed. But just as suddenly as it vanished all of those years ago, it reappeared on a new domain. But this time with something new, almost unfathomable for lowbrow, an API. Let the gears begin turning…

After playing a bit with the API I decided that I desperately needed a lowbrow application on my iPod Touch, and I needed it immediately. So I gave myself a 48 hour deadline to design and write an iOS app. And unlike all of the OTHER times I’ve set arbitrary deadlines for side projects, I actually completed this one. I’d do a full write-up on the application itself, but it’s pretty unremarkable. It makes an XML based API call using the built in XML parsing, has a single button, and formats HTML content via a web view. It’s quick, simple, and to the point. If you’re interested in my app (and if you’re reading my blog, you should be), you can check it out on iTunes.

The bummer was that I sent the app to the App Store for review on February 25th, and waited until March 3rd for the actual review itself to begin. And now, March 7th, it’s been approved! All told it was just over a week from idea, through development, and to approval. Not bad, not bad at all.

My 2011 Quest

Background

I got a PDA (A Sharp Zaurus, running Linux to be exact) in 2001. By 2003, I was on my third PDA, my cell-phone could act as a bluetooth modem, and it had a camera. Skip forward a few years, and there’s Palm’s, Blackberry’s, and Android devices. In 10 years I’ve gone through a dozen PDAs and cell-phones, each with more features and capabilities than the last. But in 2011, I’m moving backwards, I traded my Android phone in for a $20 nearly-disposable flip phone.

This wasn’t a spur of the moment decision, I’ve been plotting, and thinking, and planning this for months. I started telling folks in December that I would ditch my smartphone in 2011. They almost uniformly had the same response, disbelief. How was I going to go back to not having internet access with me all the time. I wouldn’t have automatic syncing with my google calendar, or contacts. No email, no web sites, no camera, nothing, just phone calls and sms.

Why?

That’s the question everyone wants to know. Why on earth would I give up all the benefits of a smartphone? I don’t know. Part of me says this is crazy, stupid, and I’ll be clamoring for a new phone within a month. The other part of me says this is a valid personal study, and might provide worthwhile insight. I’m listening to the latter part, and trying to answer two questions in the process:

  1. Does a smart phone actually make my life easier or better in some appreciable way?
  2. How do my daily routines, and general habits change when I don’t have constant hand-held access to the internet?

I’m hoping that at bare minimum this experience provides me with better knowledge about what features I actually need in a smartphone, so my next purchase can be more about function than form.

How’s it going?

I took the plunge right before New Years. I went to Wal-Mart and bought the absolute cheapest T-Mobile compatible phone I could find, it was a $19.99 Samsung flip-phone of some sort. It’s small, light, and absolutely mediocre at all of it’s basic functions. Which makes it pretty prime for this kind of experiment.

I’m now a couple of weeks into my little experiment, and I can tell you that I’m a bit twitchy everytime I open my email. Did i get 5 emails or 500 since I last checked? Did I miss an email from the boss? There is some noticable apprehension when I open my email. But it does seem to be subsiding.

I’ve also become hyper-aware of other people using smartphones. Sitting at a restaurant I noticed an entire table playing with iPhones, and completely ignoring each other. I hope I wasn’t one of those oblivious people when I was using mine, but I probably was.

As to how I’m progressing on answering my two big questions? Well, I can’t say that I’ve really missed having a smart phone with me all the time. If anything, the week-long (yes, I charge this thing once a week) battery life of my phone, means that I’m even less aware that I even have a phone with me.

The second question is probably harder for me to answer directly, but I have noticed some small things. I have no idea what the weather is supposed to be like today, or tomorrow, or a week from now. None. I think I’m actually organizing my email better. Since I’m not skimming a lot of email on my phone, I’m actually doing a better job of sorting and filing email as I see it come in. I need a small camera I can actually stick in a bag and have with me most of the time.

And…

I’ll post another follow up to this later, once this change has really sunk in. In the meantime, wish me luck, I feel like I’m going to need it.

Now, with more GitHub

When I setup this blog, I set it up as a GitHub repository so that I could write my posts in vim, track them in git, and publish my changes in a way that’s extremely similar to how I deploy all of my other apps. This was, and still is, an extremely appealing process. But sometime in the last couple of months post-receive hook script has busted. It doesn’t error, it runs fine when I trigger it manually, but doesn’t seem to work when called via git. I spent an hour or so trying to figure out what was going on without much luck. So I decided to just take things a step farther.

This blog now lives, and is hosted, directly from GitHub. Thanks to their excellent Pages, I don’t have to manage a deploy process at all. I just push into my blog repository and a few minutes later everything is updated. This was an easy process to move to, given that I was already using Jekyll, it was just a matter of renaming my repository, a couple of quick DNS changes and I’m all set.