I’ve been experimenting with what I’m going to call the one-shot banner pattern in Sudoku.

Borrowed idea

We ran a private beta when I was working on the Songkick Android app. The most common piece of feedback by far was that existing users wanted to log in straight away and couldn’t find the option. (It normally presents itself when you take an action that requires an account.)

We sketched out a few different options: dialog, notification and banner. The log in/sign up banner won. It sits within the context of the app, it’s immediately visible without being jarring and it’s friendly to users that don’t want to take either action yet.

Current implementation

The version in Sudoku has evolved a little. It has more in common with the action bar, sharing a consistent height and action pressed states. It’s also slightly transparent to hint that it’s a transient feature of the UI.

In practical terms, this is just a Fragment added to the bottom of the Activity layout. Completing the action or pressing the dismiss button will remove the Fragment and SharedPreferences are used to maintain the shown state. All quite simple.

The user is invited to +1 the game after 2 completed puzzles. This is just pressing a button so it’s pretty low commitment.

I want to ask the user to rate the game once they’ve played long enough to have formed an opinion. (Hopefully the fact that they’re still playing means they like it.) This action takes the user out of the app to Google Play, which is potentially disruptive, so it’s only shown after 5 completed puzzles.

After 10 games, the user probably knows what difficulty they like to play. They might even be running low on puzzles of a particular level. This is probably a good time hint that there are more available.

Click-through rates

Roughly 1/30 users who are presented the rating banner click ‘Rate it!’. This suggests that it’s serving it’s purpose. It also makes a pretty strong case against doing something modal. The vast majority of people will not be interested in rating an app even if you know they’re active users when you ask.

Other resources

Stefano Dacchille has a great blog post on holding off asking users to rate an app if they’ve experienced a crash recently.

Back in November, I was browsing games on a rather boring train journey. There are a lot of sudoku games on Google Play. Some of them have respectable ratings and millions of downloads, but none of them felt right to me. They didn’t feel at home on Android. I started to sketch out what a sudoku game might look like with the Holo design language applied.

I didn’t want fancy graphics or complicated customisation options. I wanted something clean, simple, flat, familiar and content-first. This quickly became something I was going to do. The game in my head seemed so obviously missing. I tweeted my fear that I was about to sink a lot of time into something people would never find in such a saturated category. Okay, genius was definitely the wrong word, but I was excited.

When my train arrived, I had a project on GitHub and a really clear idea of what I was building. The first version took two months of spare evenings and weekends. I finally had something that I was comfortable releasing on Christmas eve.

Getting featured

I was on the same train last Friday when I noticed a few crash reports for the game in my inbox. I’d never had two on the same day before, so I loaded up Google Play to check the featured section. That was a bit optimistic, really, but I knew that the featured apps change on Fridays. It had happend! The game has been downloaded over half a million times since then.

I’ve worked on a couple featured apps before but this felt different. It’s always been as part of an incredible team. This was just me. It wasn’t my job. I did it for fun, in my spare time. That was pretty cool.

Taking it places

The sudden influx of users has brought a lot of great feedback. I’ve read every email and comment. They’ve been amazingly helpful in planning the next couple of updates. There is definitely more to come.

Download the game and let me know what you think.

View has a neat keepScreenOn attribute. Simply setting this attribute in the XML style for the game board means that the screen will no longer dim when that View is visible.

Lose the system nav bar

Create a custom emulator device from the Device Definitions tab in AVD manager. Configure the device with one of the supported screenshot resolutions (such as 720×1280) and change the Buttons toggle to Hardware.

Full health

The emulator status bar will be empty but it displays the battery as discharging by default. Telling the emulator that it has full battery is just a couple of commands (5554 is the default emulator port).

Consistent times

Set the same time between screenshots for maximum consistency. You can even try to reflect the current app version number in the time, if you’re feeling super nerdy: adb shell date -s 20130411.130000

Result

The first thing I built was a latest news extension for DashClock. DashClock has a really nice API, so the whole thing was finished in a couple of hours.

I also made made a resizable home and lock screen picture widget. There was a positive “can we keep it?” conversation with the project manager, so this will probably find it’s way into a future release.

There are some of these built into the platform. Try dialling *#*#4636#*#*.

With these snippets, dialling *#*#1111#*#* will launch the SecretActivity. FLAG_ACTIVITY_NEW_TASK is required because we don’t have an Activity context for the startActivity() call.

Note: The use of the secret code is clearly visible in the AndroidManifest.xml, so it’s a bad idea to put anything sensitive behind this in a release build.

I’ve been working as a software developer for a couple of years now. I’ve noticed you around. At first I thought it was sad that nobody liked you. Now I understand it, and I think we need to talk…

Now, you’re not the recruiter that’s in the employ of some interesting company. I have the occasional affable conversation with those people. You’re the unsolicited emailer. The LinkedIn connector. The “I know you didn’t give me your number, but…”-er. The third agency I’ve never heard of that’s contacted me today.

You tell me I am special, but you get my name wrong.

It probably doesn’t help that I write code for a platform that’s in such high demand at the moment. It seems relatively difficult to find good Android developers. However, I’ve yet to meet anybody in the tech world with a nice thing to say about the recruitment industry. So here is my advice:

1. People who make software actually turn out to be people. I’m not a resource. Treat me like a human being. Be polite.

2. Don’t email me unless I or some trusted friend/colleague gave you my email address. The emails that I get from recruitment agencies are exactly as interesting as the ones I get from IKEA about decorating my bedroom. I gave IKEA my email address, though.

3. Same goes for my phone number. Stop calling me. Ugh. It’s so exhausting. We are never…

4. Don’t pretend we’re friends or send LinkedIn invitations claiming we know each other. Stop trying to hang out. We see you prowling at the back of the meetup in your suit trousers. We go to those things to learn stuff and have interesting tech talk with our peers, not to be recruited.

5. Stop advertising roles for rockstars and ninja programmers. It sounds ridiculous and you’re alienating everybody that’s less of a single mid-twenties male nerd than I am. Definitely never say “brogrammer”. Urgh.

6. Please, really, seriously don’t word emails as if I’m obliged to get in contact with you. This is so obnoxious.

7. Don’t contact me about jobs at companies where I used to work. Not to say that those aren’t good jobs. (Android devs! Go work for Novoda. They make cool stuff.) I just think that if I wanted to work there again, I’d go for a beer with Kevin and Carl instead of giving you 10% of my salary to introduce me to friends.

8. When you break rule 2, don’t tell me how many years you’ve been in the industry, the yearly turnover of your client or how great a fit you determined I am without even meeting me. I just do not care.

9. I also don’t care how you found my profile (It was on LinkedIn, no matter how many times you write “GitHub”). Somebody even found my GitHub profile through “Boolean Searches”. (Yes, with initial caps, like it’s a thing.)

10. If you really must ignore everything else. Do tell me the only thing I would care about if I was thinking of changing jobs: the name of the company.

I know, I know. You’re thinking “This is just how recruitment works. It gets results!”. Well, maybe, but these are the reasons that I’m not responding to your emails. Like, ever. Your industry is broken.

Love,
Steve

Can you auto-complete all emails rather than just Google ones?

Yes. This version checks that account names are email addresses with a regular expression and puts them in a set to avoid duplicates. If you’re targeting API level 8 or above, there is even an email pattern in the Android framework. (You could also reverse the email check and use this code to auto-complete usernames.)

Thanks to Akshay Dashrath, Nick Butcher and Christopher Orr for suggesting those revisions.

Will users complain about the GET_ACCOUNTS permission?

Yes. A few probably will. I think that for the majority users who pay attention to permissions, it will come down to whether or not they trust your app with their accounts. If you need to add this permission solely to improve your login screen UX then it’s something to consider. However, there are several reasons you might need GET_ACCOUNTS anyway, like if you’re storing tokens in the account manager or using Google Cloud Messaging.

ImageLoader provides a utility for downloading Bitmaps in this scenario (it’s synchronous, you need to handle threading yourself):

Bitmap thumbnail = new DirectLoader().download(url)

If your thumbnail isn’t served as a square of just the right size, here’s a helper class that I threw together to scale and crop a Bitmap to the dimensions expected by the notification tray.

Bitmap scaled = new NotificationThumbnailHelper(context).scaleBitmap(thumbnail)

Firstly, ask for the GET_ACCOUNTS permission in the AndroidManifest.xml:
<uses-permission android:name="android.permission.GET_ACCOUNTS" />

The method that does all the work queries the account manager for Google accounts (every user should have at least one of these) and puts those email addresses in an ArrayAdapter.

The only thing left to do is change the EditText to an AutoCompleteTextView and call setAdapter(getEmailAddressAdapter(context)) on that View.

You might also consider simply setting the text of the email field when there is a single email address in the account manager.