Friday, 31 August 2012

Users expect things to work a certain way. For example, pressing the back button on the main menu of an app should actually take you back to the home screen of your device. Unfortunately, a ton of Android game makers ignore this rule and override the back button behaviour to do nothing. Some display an Android textview to exit the app instead. Often, those that don't override the back button indulge your patience by throwing up a "helpful" dialog, "Do you really want to exit? Really? Really really?"... "YES PLEASE!" The worst offenders of this design however, do nothing. That's right, nothing.

Enter "Gears and Guts". This is a great game, but notoriously hard to actually exit unless you press the home button (this doesn't actually exit the app). The main menu screen of the game offers no way of exiting. Plus the back button is overridden to do nothing. Pressing the home button fixes this right? Not really. The app still consumes a significant amount of memory in the background (unless it is auto terminated in low memory situations). Unless I'm missing something, this is quite a shoddy implemetation.

Another annoying appp, widget rather, is the reader for Reddit, called reddit is fun. After reading an article, pressing back prompts the user with the following dialog "Really exit?". Stop nagging me, ma!

So game makers, please follow design guidelines. And for gods sake please don't use Apple's design guidelines on Android. They're two different use cases.

Friday, 24 August 2012

I kinda don't get peer programming. Recently, I had a chance to see it in action (and even participate), though it failed to win me over. Imagine sitting alongside a fellow developer, frequently interrupting his or her train of thought.

Others assert that this might actually increase focus, as developers are less likely to stray off and log on to Facebook or whatever. Developers can learn from each other too.

Peer programming seems like something you might use to get fresh recruits up to speed. Otherwise, I feel that the constant interruptions will probably suck all the fun out of programming. There's a time and place for everything- perhaps during the design phase, consulting and brainstorming with peers would be a good option. Once that's decided though, implementation should probably be an individual thing. Let your creative juices flow and all. Plus, when coupled with code reviews, peer programming seems wholly unnecessary.

Thursday, 23 August 2012

Some "API's" just need to die. Consider the one I recently worked with- an abstruse, and seemingly undecipherable pile of slop. This particular API exposed a UNIX-like command line interface for querying a library database. Queries were frequently piped (c.f. SQL JOIN), and almost completely undecipherable without the help of a poorly worded, massive, "manual" (password protected of course).

My specific task was to circumvent the piping functionality for a few commands, which were failing on Windows. The specific API commands were apparently designed for UNIX systems. Piping them on Cygwin was leading to rogue spawned processes. Long story short, it was decided that the piping behaviour be handled manually.

Windows imposes a 8191 character limit on its commands. I couldn't just redirect input as I pleased- input often exceeded this limit. Sending input by chunks proved viable initially, by was an O(N) solution, N being the number of chunks. This scaled poorly for popular library books.

Scrapping that, I made a custom parser for handling the API commands, where only the bare minimum was piped. This was an interesting, but tedious, hack. Without giving too much away, this was the only alternative (to give you a hint of the irritating stuff which led to this decision, consider running primitive API commands in a primitive Gnuwin32 environment, with a whole ton of other medieval restrictions). It was tough going, though worth the extra effort. It ran at O(N), N being the number of piped commands, a significant improvement, most commands being really short.

Even for the most popular library books, our queries ran under 800ms!

What a hellish ride though. I'm sure this will make a good story someday, and by good, I mean I'll probably have to stab somebody after.

Wednesday, 22 August 2012

My Android app, Bingle, was published fairly recently. The analytics are fairly surprising- a steady, almost unwavering, increase in downloads followed by a precipitous drop. The Google Admob campaign I started might explain the initial increase, but even after withdrawing the funding, the numbers kept rising. Might be due to some residual multiplier effect. The drop is what confuses me though.