iOS and Android: The Odd Development Couple

We recently ported our app HeyTell from iPhone to Android, and found that we gained a little perspective in the process. Because it uses a large number of system features (native widgets, location, database, audio, network services), porting the app really required a deep understanding of each platform.

A great way to get an understanding of the strengths and weaknesses of any software platform is to port software from one platform to another. For example, in the early days of my programming life, I'd write a simple "Missile Command" game to get a feel for a specific platform.

Here are some of the various perspectives of the iOS and Android platforms, and how we view them differently after the port:

User Interface - iOS has the benefit of being based on a mature UI framework (Cocoa) and Android has had to play catch-up with features (like animated views). iOS has the edge here with some features -- table/list views in particular are much more full-featured, if a bit difficult at times. Interface Builder also is much more slick than anything available on Android (I just edit the XML files directly on Android), so I'd say iOS wins this one.

Application Framework - Android and iPhone have very different ways of looking at the world. Android tries to model an app as a loosely-coupled set of Services, Activities, and Content Providers, while iOS sandboxes each app like a traditional OS. I understand the rationale behind Android's design, but I think it confuses more than it delivers.

Performance - We've never had serious problems with performance, although iOS seems to have a snappier UI in general and do a better job with compositing and animation. Both platforms allow native code (Android via the NDK) for CPU-intensive code.

Language - Objective C does seem to have a steep learning curve and a lot of new concepts compared with Java - especially regarding memory management. However, if you look under the surface, Android has many of the same issues (look up "android memory leaks weak references"). But if you're experienced in Java, you'll have a lot fewer hurdles with things like threading on Android.

Third-Party Libraries - There are roughly equal numbers of iOS and Android libraries on GitHub, for instance. On iOS, you have easy access to any C/C++ library (without going through JNI), while on Android, you have easy access to the thousands of native Java libs. I'd say this one is a tie.

Development Tools - Eclipse is a great environment and is perfectly optimized for Java programming. XCode isn't bad either, and the experience is a bit more polished. I do really appreciate the command-line tools like adb you get on Android, however. My partner is a big fan of the Dalvik Debug Monitor Server (DDMS).

Documentation - Apple has great documentation, and you can find pretty much anything you want to know there or in its example code. The Android docs are not quite as comprehensive, IMHO. We do use Google Code Search to search the Android code base ourselves, which is very helpful at times. But you're going to spend a lot of time on Stack Overflow, no matter what you pick. :)

Market - One feature of the Android Market is that you can push an update at any time without review. This is really comforting from a developer's standpoint (maybe not so much from a user's, but we're happy about it). Android also lets users comment on their stack traces, which is really neat. Okay, sometimes the comments are not so nice, but often they add steps to reproduce - this is really helpful, especially when it seems like we see a new piece of handset hardware appear in our matrix every day and testing across all devices/OSes/firmware revisions/carriers/whizzbang modded ROMs on Android is unfortunately really tricky for a small, bootstrapped team.

Monetization - Because HeyTell is free, we don't have any perspective on pay vs. non-pay apps on either platform, but Apple's In App Purchase capability has served us well. In App purchases are really important for us, because not all users want or need all features, and we don't want to charge users for features they don't want or need. Our fingers are crossed that Google adds an IAP capability soon. In addition, on the advertising side, there really isn't anything on Android quite as turn-key as Apple's iAd. All points go to iOS here, at least for now.

Viral Marketing for Nerds and Data Junkies

Thanks for everyone who attended my Viral Marketing at 360iDev in Austin! Big thanks to John and Nicole for having us as speakers.

For everyone who asked, slides are below :)

Viral marketing by the numbers

View more presentations from Voxilate.

Steve & Jen Speaking at 360|iDev Austin in November

We attended 360|iDev San Jose in Spring of 2010 and had a great time — learned a lot, met a lot of really cool people, and got a chance to connect with fellow travelers on the indie iPhone developer scene. Great fun and a tremendous learning experience!

We enjoyed it so much, that when we heard "November in Austin," we knew we'd be there for sure. It seemed like a good idea to give back and share some of the things we've learned from the release of HeyTell Voice Messenger, so we both submitted talks — and both were accepted!

Steve will be presenting Viral Marketing by the Numbers where he'll bring a developer's perspective to marketing the freemium iPhone app HeyTell Voice Messenger and how it gained 100,000 users using a purely viral marketing model without paid ads or employing conventional PR.

He'll talk about the features and performance of viral vectors by the numbers, predicted vs. actual growth, and will draw some parallels between viral propagation of an app and nuclear reactions. The audience will hopefully take away additional ideas and strategies for successfully incorporating viral elements into their applications.

Jen's going to dig into The Reluctant SysAdmin: Managing the Server-side of a Client/Server iPhone App, where she'll talk about all the fun and not-so-fun things about managing the server-side of a client-server app with an emphasis on security, reliability, and survival (and sleep!) when you're small & indie.

She'll hit on some of the fantastic things about maintaining a server component (metrics, Push Notifications, App Store receipt handling, did we mention metrics?) as well as the not-quite-as-fantastic (24x7 system monitoring, data security, and attacker-thwarting, rolling upgrades for services that can't go down, the occasional sleepless night) and will then focus on processes, products and technologies that make this all easier for a small team to implement, including continuous integration strategies, use & abuse of Amazon Web Services (EC2), and open source solutions for security & monitoring.

As you can see, we're really excited about 360|iDev in Austin - if you're coming, can't wait to see you. If you're considering, hurry up and book it! If you're not, reconsider and book it anyway!

Gauging User Sentiment with Word Clouds

We just released the HeyTell Android Beta and, in the calm before the storm, wanted to take a little break and do something a little frivolous. Perfect time for word cloud creation! Why not take a look at frequency of the words users use to describe HeyTell for iPhone 2.0.3 when reviewing the app on the App Store?

So I popped over to iTunes connect, expanded user comments and saved as HTML. A little command line fu, like such:

grep "review-text" DownloadedComments.html |awk -F '\">|\<\/P' '{print $2}'

Copy and paste the output to http://wordle.net, et voila, user sentiment made pretty:

Requirements Tracking For Total Slobs

I'm now working on an iPhone/mobile startup with just a handful of people, and we typically get things done via shouts, IMs, and emails. This works for us, but I used to work at a company which did things *much* more formally. We will refer to this way of doing things as (drumroll) The Process.

The Process goes as follows: Product Managers generate Functional Requirements which go to the Engineers which turn these into Design Requirements which go to the Developers which develop The Product which goes to QA who uses the Design Requirements to create a Test Plan which then gets sent to Integration Teams which use the Documentation generated from the Design Requirements to make the Installation Guide which then results in the Customer getting ... well, something.

This is a little heavyweight for the standard indie dev shop, but there's a good practice hidden here, which is the generation of Requirements. Why would you want to make actual Requirements when DESIGN.TXT in your home directory will do just fine? There are several reasons:

• They encourage you to record design decisions, and act as high-level code documentation.
• They give you a way to generate test plans - each requirement should be a testable feature of the product.
• When doing a port to another platform, they let you know when you're done (when all the requirements are checked off)
• They let the test team know when they're done (when all the requirements are checked off)

These all boil down to "scoping" your product. Any external party can look at the requirements of your application and get the gist of what's going on without looking at code, and if you do it right, they can test/document/port/translate/regress/whatever and know that they haven't missed anything.

Of course, no one is really going to go through much extra effort generating documentation when they could be making apps and making money. That's foolish. That's why I'm going to show you my bone-simple Requirements Generation Technique. Watch closely!

1. A requirement is defined in a source file (.c, .cpp, .m, .java etc) with a code comment. Here is an example:

// Requirement: When a Butterball is hit with a bullet, split it into two Niblets.

2. Generating a design document is done as follows:

% find . -name '*.[cm]' -print0 | xargs -0 grep Requirement: > design.txt

3. Doing a "Gap Analysis" (comparing two design docs) is done as follows:

% sdiff design1.txt design2.txt

With a little effort, you can pipe requirements to CSV files and upload to Google Docs so other team members can review, make test plans, etc.

Congratulations! You've just replaced thousands of dollars of expensive requirements-tracking tools and at least three middle managers! You've also taken a step to better documenting your code and your product so others can more easily play in your sandbox. You don't need an overweight version of The Process like our example bureaucratic organization, but it helps to have a little organization in whatever you do.

Top 10 Bolt-On Cocoa Touch Libraries

In the last few months of iPhone dev on apps such as HeyTell, we've learned a lot about how to save time and add features by taking advantage of third-party libraries. In no particular order, here are some of the easiest to integrate (thus "bolt-on"):

1. Reachability - Every iPhone developer should know about this. It's the Apple-approved way to check to see if network connectivity is available from your app. It helps to wrap this with your own code for generating helpful Alerts when the network bounces up and down.

2. SFHFKeychainUtils - The Keychain API may look scary, but it's useful too. How else will you store encrypted, backed-up key-value pairs that persist across uninstalls of your app? This wrapper API has just a handful of easy-to-understand methods.

3. Plug in an analytics API like the Medialets SDKs to capture information about your app at runtime. In just a few minutes you can be capturing app installs and start/stop events, a little more time gives you custom app events and lets you integrate ads into your app.

4. java-apns - Ashwin Phatak's Java library for push notification. Requires a bit of integration work (and a server component) but much better than rolling your own. (ok, so it's not a Cocoa Touch library per se - but it's essential if you're doing APNS in Java)

5. Combine your native code with HTML by using PhoneGap and iUI to make look-alike user interfaces in HTML, JavaScript, and CSS.

6. If you're a game developer you must have heard of OpenFeint, so there's no need to explain this popular social-media-enabling bolt-on library.

7. Appirater helps you get feedback on your app by requesting a review after a configurable amount of time or number of app runs. Just a few minutes to integrate.

8. The default HTTP client libraries sometimes don't cut it, especially when streaming or multi-threading. Try ASIHTTPRequest and get a wealth of features above and beyond what the standard NSURLRequest provides.

9. When building apps that parse XML from REST queries, you may want to try TouchXML which provides an easy-to-navigate DOM tree object from your XML documents. Don't like XML? Try Google's Protocol Buffers or Apache Thrift for more efficient and robust network protocol structures.

10. And when your project is ready to ship, give Hudson a try to automate your builds. The new Xcode 3.2 provides features that may help in archiving built products, but I think there's still value in doing a clean checkout and build from the repository (instructions for iPhone here)

We hope these give you some ideas on how to save precious mental CPU cycles on your next iPhone/iPod/iPad project!

Reduce your micro-startup burn rate...and see the world, too!

At Voxilate, we've taken a novel approach to reducing capital expenditures while maximizing productivity and creativity: we're taking the show on the road and are putting our money where our mouths are--creating voice-activated applications for mobile devices while being mobile ourselves!

This is a bit easier to do as a micro-startup (also known as "Micro ISV"), given highly-available mobile broadband and ubiquitous wireless Internet connectivity, competitive hosting and "cloud" solutions, and the myriad online, hosted services at our beck and call these days.

Here's a quick rundown of tips we've found vital to our mobility so far (we will expand on these in later posts):

Mobile broadband: Don't leave home without it. We purchased a wireless broadband plan and wireless card that's plug-and-play with our mobile broadband-enabled CradlePoint MBR900 router. We also have a PepWave Surf personal wi-fi receiver that can harness available wi-fi and make it available to more than one team member or computer.

Network redundancy: Make sure you're bound to more than one network and/or cell provider. You want to always be able to call out, check email, and connect to remote systems with at least one of your team's phones or netbooks using wireless broadband cards or cell-phone tethering. We often switch between AT&T and Verizon services. Would be better to switch between three or four - but we're talking about belt-tightening, here!

Hardware: In addition to your mobile broadband card and portable routers, a good mix of laptops, external hard drives, and small form-factor systems like the Mac Mini will serve you well. You'll also want cigarette-lighter power adapters to power and charge your stuff - and, if there are more than one of you not driving while on the road, use the router in the car with the broadband card. Also remember to bring power strips, outlet expanders, Ethernet cables, thumb drives, extra chargers, connectors, and so on.

Internal Systems: You should have a source control system, build system, and bug system for development. What you choose to administer locally or remotely is up to you, but do make sure that everyone's got a copy of the source repository checked out and if you're self-hosting build & source control, ensure that you can swap build and source control systems from one laptop or mini-server to another in case of catastrophe. If you're going to be someplace for a day or two, make sure you check in your code. During this 'period of stability,' remember to also rsync (or some other replication method) to back up your critical systems to your hard drives as well as a secure off-site backup provider that you trust and uses encryption.

Hosting redundancy: Choose hosting providers you trust and who have good reputations - don't always go for the cheapest (although price doesn't always mean quality, either!). Look for hosting providers that provide data center geographic diversity. Augment with other providers - you want the ability to quickly bring your systems up in case of a hosting provider's catastrophic failure. Amazon's web services are excellent for this purpose--encrypt and backup your data to S3, build your backup systems with EC2 & EBS--and pay only when you need to bring them up or test (and you can bring them up in minutes, with simple shell scripts). Great for staging/development/pre-production servers, too.

System monitoring & Maintenance: You'll want to set up something to quickly alert you via email or SMS when remote systems go down - use a service like Pingdom and supplement with self-monitoring on your hosts. Sign up for system status and downtime alerts (if you're not added by default) for all of your providers. Follow their Twitter feeds and check your email. Do what you feel you need to do to keep peace of mind and security; script it, add it to crontab, and have it email you its results. For example, scan your web logs for unexpected traffic that doesn't 404. Monitor vulnerability alert RSS feeds for software you use (both locally and especially on your externally hosted systems). Use Snort and OSSEC. Use whatever tool(s) you love. I love elementary shell scripts. Lots of people love Nagios. Many adore splunk. Mix and match for great justice.

Delegation: Use services to do your bidding and spend your time doing what you do best. Take advantage of great services like Amazon's Mechanical Turk for quick, repetitive, or data entry type tasks and 99designs.com for graphic design expertise. Get a good accountant that can meet via phone or email. Use online fax and voice services to stay connected wherever you happen to be.

Mail: We use trusted family members and a mail receiving/scanning service, Earth Class Mail. You can view your mail online and have it scanned and/or snail mailed to you wherever you happen to be, singly or in batches. They even have an auto-deposit option for checks you receive. Also try to configure anything you can to send you bills and notices online--scanning costs can add up.

Digital and Physical Security: This is a biggie! When you're carrying your tech like a turtle on your back and depending on the wireless of others, an awareness of both physical and network security are vital. Don't connect to wireless networks you don't trust. Don't check your bank balance using hotel wireless, for example, and always check certificates (although that isn't any guarantee these days, unfortunately). Be careful what you download. Bring your own routers to ensure that you can connect to your local resources without going over the public Internet.

As far as the real world goes: Assume everything you have will be stolen and plan for the occasion. Make copies of all important documents and store with someone you trust. Categorize the importance of what you're lugging, then lock up the most valuable things and keep them on your person when you leave your vehicle for the night. Get into a routine, and make everyone crosscheck each other so you don't leave anything behind.

Short-term locations: Go beautiful, go off-season. Use sites like HomeAway.com. Check out executive long-term stay spots as well - if you plan ahead, you can often get a really nice condo in a great location for much less than you'd pay for a standard hotel room.

Make sure they've got broadband, and come prepared with all the things described above. Plan your stays around your work schedule - stay awhile if you're in deep development. You don't want to be on the road (well, with the tips above, you can be if you want to be!) when you've got a lot of coding or testing to do!

Trust, but verify: Verify your setup before you embark long-term. Use your network setup where you're currently at, then take it with you on the road. Try staying somewhere local for a week or more, near friends/family/business acquaintances so that you can easily offload equipment you find you don't really need.

These are just a few of the things we've done to reduce our micro-startup 'burn' while enjoying a spectacular view.

EN576M6GTHWF

Turking the Healthcare Bill

As some of you have no doubt heard, the 2,000+ page healthcare bill is making its way through the U.S. Senate and is due for a preliminary vote on Saturday evening. There's a big challenge ahead for legislators trying to make sense of this complex and lengthy legislation.

We'd hate to pass up the opportunity to perform a public service, so we took a few minutes to use our technology to ask Internet denizens (via Amazon's Mechanical Turk) to collectively read the bill in a lot less time than the 36 hours it would take to read it on the Senate floor.

We know that the eyes of the average citizen tend to glaze over looking at the bill, so we opted out of asking turkers for a deep analysis of each page -- they wouldn't have context of neighboring pages, for instance. We instead asked for a visceral response; we asked each turker to type in their most favorite and least favorite words (from their point of view, of course) that they could find in their particular page of legislation.

First we converted each page of the extremely-long PDF into individual bitmaps -- each one looking something like this (though larger):





Then we used our command-line client (discussed previously) to submit each page individually to Mechanical Turk.

The best (most preferred) words can be visualized in the following word cloud:



The worst (least preferred) words are here:



So what does this all mean? Well, if you read the images literally, citizens want quality affordable health benefits, information, and respect. They are fearful of abuse and fiscal limitations . They also loathe the bill's document structure ("subparagraphs" and "subsections") and legal mumbo-jumbo ("striking" and "amended").

The final costs were as follows:

Mechanical Turk fees: $20
Time until entire bill was read: 8 hours

The $20 fee results from each worker's payout of 1 cent for their analysis of a single page. Certainly you'd have to pay a well-heeled K-Street analysis firm a bit more for a similar result. ;)

Batching Mechanical Turk Jobs at the Command Line

Here at Voxilate, we use Amazon Mechanical Turk for a lot of things - from crowdsourcing translations to gathering market research to deciding where to go for lunch! Some of the jobs are one-time deals that we don't want to spend a lot of time on.

Typically, you can submit, monitor, and approve Mechanical Turk jobs (HITs) using the API or the web interface. The web interface requires a lot of mouse-clicking and .csv file generation and it really doesn't allow for full control. The API is complex and doesn't lend itself to quick experimentation. There are also a set of command-line tools provided by Amazon, but these just wrap the API and can be a little clunky.

Wouldn't it be nice if you could just type a single line and watch Workers' responses come back in real-time like this:

% mturk -j 3 -t "What is your favorite color?"
blue
blue
red

Or this:

% mturk -t "Who is in this picture?" albert.jpg bea.jpg
Albert Einstein
Bea Arthur

We thought it would be pretty cool, so we created a quick script using Python and the boto library.

How does it work?

Given a command like:

./mturk.py -p .50 -j 10 -t "Is there text in this graphic?" -D "If you see text in this graphic, type \"text.\" If not, type \"no text.\"" -w 300 -A IsThereText01.jpg IsThereText02.jpg

We'd create two distinct HITs - one for each file (JPEGs, in this case). The -j parameter controls the number of assignments we submit for each HIT; in this case, we'd run 10 iterations of each HIT, for a total of 20 assignments. Each assignment would pay out 50 cents (specified by -p .50), and because we used -A for auto-approval, you'd be out $10 if workers accepted and completed all of your hits!

By default, the script uses the Mechanical Turk sandbox so that you ensure that your usage is correct before spending real money. The -w option ensures that the script waits the specified number of seconds for HIT results to print to standard out, then exits.

In our example, we used JPEG files, but the input files themselves can be:

• Blank - You don't want to pass any data, you just want to ask a question with a single answer.
  
• Image, Audio, Video - show the user a picture, video, or sound and have them return a response.
  
• HTML - This allows you to have full control over the HIT. Whatever <form> tags you use in the HTML file now posts results to Mechanical Turk. They are hosted on Amazon S3 as an "external question" and appear in the IFRAME of the HIT. (More on this in a future blog post.)

We've found this really kind of useful - for instance, we've used this script as part of a Makefile to implement a complicated workflow. Let's run through an example.

First, let's check our status:

$ ./mturk.py
You are in test mode.
Funds remaining: [$10,000.00]
There are 0 jobs active.

Note that we see $10,000 because we're using the sandbox. If you had active jobs, you'd see the jobs listed by HIT ID and filename. Running mturk.py in live mode (./mturk.py -l) will show you how much money you really have:

$ ./mturk.py -l
You are in LIVE MODE.
Funds remaining: [$41.38]
There are 0 jobs active.


Next, let's submit a job. In this batch, we're using the sandbox (no -l!), and "paying" 4 cents for each assignment, with two iterations of two graphics for tagging. We should auto-approve submissions 360 seconds after completion and wait 400 seconds before exiting the script.

Here's what we run and see on the command line:

$ ./mturk.py -p .04 -j 2 -t "Tag this graphic" -D "Type keywords, separated by spaces, that you think best describe the image. Please enter at least 2 and no more than 5 keywords." -k "voxilate tagging" -d 120 -e 300 -a 360 -w 400 Namazu.jpg SydneyOperaHouse.jpg
You are in test mode.
Uploaded to http://com.voxilate.mturk.s3.amazonaws.com/home/jen/Turkpipe/Namazu.jpg
/home/jen/Turkpipe/Namazu.jpg: Created HIT 936MY1Y9KY4ZTJH4ZXTZ.
Uploaded to http://com.voxilate.mturk.s3.amazonaws.com/home/jen/Turkpipe/SydneyOperaHouse.jpg
/home/jen/Turkpipe/SydneyOperaHouse.jpg: Created HIT M1N2Y04MX34RW21CGY6Z.
/home/jen/Turkpipe/Namazu.jpg: 0/2 assignments completed.
/home/jen/Turkpipe/SydneyOperaHouse.jpg: 0/2 assignments completed.


And here's what we see in the Mechanical Turk Sandbox:



Next, we'll play worker and grab some of these HITs:



And the other:



We'll then see changes at the console, as it polls for completion:

/home/jen/Turkpipe/Namazu.jpg: 1/2 assignments completed.
/home/jen/Turkpipe/SydneyOperaHouse.jpg: 1/2 assignments completed.

Because we submitted two iterations, the Turk won't let me do *all* of the tasks myself, so we wait for other workers to jump in to complete them (on the Sandbox, bug a friend or use another account). When complete, the script exits, dumping the following to the console:

/home/jen/workspace/Turkpipe/Namazu.jpg: 2/2 assignments completed.
/home/jen/workspace/Turkpipe/SydneyOperaHouse.jpg: 2/2 assignments completed.
catfish japanese art
japanese catfish painting
sydney australia opera house
Sydney opera hall Australia water

And that's it - Turking at the command line successful! Add a -l to the command (and an -o output_file to save results to file) and you're ready to go live!

Mobile-Enabled Silent Auction

We've been recently playing with Twilio, and looking for other niche IVR applications to build. The perfect opportunity arose as we were involved with helping out a local charity event.

During the event, there's a silent auction. Attendees bid by entering their name and the amount of their bid on a bid sheet next to the item, and at the end of the event the winners collect their bid sheets and pay for their item.

Cash and check are obvious -- but using a credit card requires the winner to transfer his information to a volunteer who manually enters it into a payment system. There are always more people looking to check out than volunteers to take their payment, so this process is ripe for automation.

Here's a quick walk-through of how it works:

1. All bid items are listed in a Google spreadsheet


2. Users at the silent auction enter their name, bid amount, and phone number on the auction sheets.


3. When the auction completes, on-site staff enter the winners into the Google Spreadsheet.


4. Bidders dial the Twilio-provided number and enter their phone number as a PIN (automatic if they send Caller ID). They are told whether they have won, and if so, what their total is (important for those who bid on multiple items!). They are then instructed to say their names, addresses, and other pertinent information and are of course thanked for participating.


5. This information is then transcribed and posted into the Google Spreadsheet (this is fun to watch in real-time!) The Twilio link to audio is also included in case the information needs to be double-checked.


6. On-site staff can then complete the checkout at their leisure.

We're using Google App Engine for serving the TwiML responses to Twilio, and the Google Data APIs for connecting to Google Spreadsheet.

There are a couple of issues right now, like that of credit card numbers traveling throughout the cloud -- even though all communciation is encrypted between Twilio <-> Google, some of us have a security background and we like to be extra careful ;) We're also looking @ payment integration to pre-authorize cards, for instance, and a SMS back to the winner to tell them their payment has been verified.

The ultimate addition would be to have the entire bidding process phone-enabled, and a demo of such a system is what we've demonstrated with our Twilio contest entry! You can call (877) 277-9839 to try it from your cell phone. Click here beforehand to see the auction items. (Don't worry, it's only a demo .. bid away!)

But this does show how a mashup that takes just a few hours to build might save a ton of headaches and help out a good cause!