Category Archives: UI

Fast splash screens on Android

In order to make an app feel fast, it’s important that the user sees something immediately when the app launches. I still see many apps that take several seconds to show anything, and it makes me wonder if the developer simply don’t know how to achieve this instant gratification. Therefore I’ve decided to write a small post explaining how to get this done. If your app needs a lighting fast splash screen then this is for you.

Splash screen example

Splash screen that loads instantaneous

Executive summary

Launch an empty activity, with a custom theme where windowBackground is set. The activity launches the main activity after a short delay and then finishes.

The git repo is available here.

You can install the example here.

Do we need a splash screen?

Some of you might be thinking: If you’re so slow that you need a splash screen you’re doing it wrong! I would normally agree, but there are two reasons why I think it’s better to have a splash screen nonetheless. Firstly, inflating a layout on Android is slow, so no matter what you do there will be a delay before the user sees it. Secondly, the main activity often does a lot of stuff, so it is hard to keep it lean.

It’s all in the theme

The splash activity is the first activity to be launched. It shows the splash screen and then, after a short delay, it starts the main activity and finishes. The splash activity has no actual content view, and the reason for this is that it takes too long to inflate even the simplest layout. Instead the splash activity uses a custom theme which defines a default windows background  drawable. We set the custom theme in the manifest.

A responsive splash Drawable

A splash screen typically consists of a background and some logos. To make a single drawable that works well across different resolutions and PPIs you need to use the LayerDrawable. The LayerDrawable is a stack of several drawables on top of each other. The stacked drawables can be of different types and can be positioned individually, and you can choose if they are scaled or not.

In my example drawable I use three bitmaps. The first one is a tiled background, the second is the product logo which is positioned a little bit above the middle, and the third one is the company logo positioned in the bottom.

Transitions and progress bar

To make the transition from the splash activity to the main activity smooth I suggest that you override the animation between them. I also suggest that you re-use elements in the splash drawable in the main activity. For example, you can re-use a header or footer. This ties the two activities more together.

If you want to display a progressbar inside the splash activity, then you can add it to the (currently) empty splash layout. It won’t inflate and be shown immediately like the background, but it will still be fairly snappy.

The good and the bad

Pocket

Pocket

Stay.com

Stay.com

If you want to try out some apps which shows good usage of splash screens then install Pocket or Stay.com. They both have splash screens that show immediately, and they have no disturbing background color which is shown before that splash screen.

Kindle

Kindle

LinkedIn

LinkedIn

If you want a slightly worse example of splash screen usage, then try out  LinkedIn.  It has a very nice splash screen, but it is not shown immediately and it shows a solid white color before the splash screen appears. This happens because they have a white background in their theme, and another in their splash layout. Another example is Kindle. They have correctly set the windowBackground, but they have the Kindle logo as part of a layout – so the logo appears slightly after the background of the splash because it needs to be inflated.

YouTube

YouTube

If you want to see a “good” example of what happens when you don’t use a splash screen at all, then try out YouTube. If you do a cold start of YouTube it takes several seconds before anything is displayed. On my S3 it takes around 3 seconds. It makes you wonder if the phone registered the tap at all.

Can we do even better?

It seems to be possible to change the window background drawable at runtime. So one idea I’ve been considering is merging the splash activity into the main activity. The main activity could start out with a custom window background that shows the splash on startup, and have the main layout invisible. It could show a spinning progressbar until it’s all done  and inflated, and then change the window background and set the main layout to visible. Leave any comments or ideas here or on Twitter / @snowpong.

Developing Stay.com 2.0 – an app post-mortem

You’re only as good as your last app. And the last one we’ve developed here at Cutehacks is Stay.com for Android and iOS. We developed the Android version and helped finalize the  iOS version. Here is a small write-up of some of our experiences developing and launching Stay.com 2.0. Overall it was a great success, but as you’ll see – we learned a few things along the way.

A short intro to Stay.com

If you don’t already know Stay.com here is a small introduction: Stay.com lets you create your own personal travel guides which you can download to your phone and use while offline. This saves a lot of money as roaming fees are still ridiculously high around the globe. Here are some screenshots:

The app is available for  Android and iOS, and if you want to know more check out this short video explaining the service.

What went wrong

We spent about five and a half months developing Stay.com for Android. We were two full time developers. We learned a lot along the way and I’ve selected three areas where we met problems.

Wrong#1 – Ignoring the Android look

Stay.com was developed for Android and iOS in parallel. At the start of the project we were asked by the designers what kind of modifications were needed to adapt the design, which was iOS focused, to Android. We estimated that no big changes were needed and promised we could make the iOS inspired design work on Android as well. We delivered on the promise, and launched a great looking app that handled the different resolutions of Android and followed the design close to pixel-perfection.

What we, or I guess I should say I, didn’t expect, was the negative reviews this provoked from some of the users downloading and rating the app on Google Play. I honestly didn’t know there were Android fanboys out there that cared. Some excerpts:

  • “…a converted iOS app on Android is an insult…”
  • “…it’s just an iOS app…”
  • “…iOS look on Android is not cool…”

Clear and honest feedback right there. And looking at things as they are now with Ice Cream Sandwich in use, updated fonts and proper design guidelines, I’d say they have a point. In my defense, the guidelines were not published when we started the project.

However, we’ve seen the errors of our ways and have have released several updates of the Android app that fixes most of these issues. Here are a few screenshots that shows some of the design changes:

Wrong#2 – Memory and performance

Another area that took us by surprise was the memory handling on Android. In short: the maximum heap size allowed for each app is limited and device dependent. If you try to allocate memory above this limit, your app is killed – just like that.  This is clearly not the way to do it, and I was surprised to find this behavior on a modern mobile OS like Android. We ended up having to rewrite some of our caching algorithms for  images, databases, and offline maps in order to run Stay.com on inferior Android devices. If you’re wondering how to do memory profiling on Android I recommend you watch this video - several times.

We also experienced performance issues with the default Android database. Every app can easily create a database where it adds, edits and retrieves data in a sensible manner. It turns out that inserts are really slow. If you want any sort of adequate performance you need to pay special attention to how you manipulate the database. For example, when inserting multiple rows in the same table make sure you do bulk inserts and not one row at a time.

Wrong#3 – Facebook SDKs

I’m not a big Facebook fan. In truth, up till we developed Stay.com I didn’t even have an account. Yeah, I know. One of the things we discovered during the implementations of some of the more advanced features of Stay.com and its Facebook integration was: the Facebook APIs suck. For the Android app we use both the official Facebook SDK for Android, as well as some of the REST APIs. We found them poorly documented, unstable, broken, non-compliant and confusing. Especially the REST APIs. Odd! The only tip I can give you are to keep an eye out for changes mentioned on the developer pages and search for tips and tricks on Stack Overflow.

What went right

Right#1 – Crash logger ACRA

A few days before we were ready to launch in Google Play, after we were done with most of the testing and debugging, I came across a post where someone mentioned this crash logger tool called ACRA. And just as an afterthought, we added it to the build. This turned out to be a great idea.

ACRA works in a very simple way. When the application crashes the user is given the chance to report back what just happened. If the user sends a report, a lot of debug data ends up in a Google spreadsheet of our choosing. ACRA is easy to integrate and has helped us expose a lot of bugs in our code. I highly recommend ACRA.

Right#2 – Trello, Git and GitHub

We use a lot of tools, but I’d like to focus on three of the ones we used when developing Stay.com.

Trello is a low-impact collaboration tool. It’s free, simple and online. You create a board for your project, you add some lists to the board, and in each list you add some cards. We used two boards when developing Stay.com – one for the Android client and one for iOS. We’re using Trello for all our projects now. We love it.

Git is a version control system. If you’re still using something like Perforce, Subversion or CVS, you need to get out more. Here are two reasons for using Git:

  • branches cost nothing
  • it works offline

Now, if you like being sysadmin it’s fairly easy to setup and maintain your own server where you can host your repositories. But if you just want something that works, go with GitHub. We’ve now upgraded to their business plan and I have to say that makes administrating different repositories, teams and access control very easy. Thumbs up!

Right#3 – Small teams, small companies

Developing Stay.com 2.0 for iOS and Android involved teams in different companies:

Somehow, this all went great. I think the combination of small teams in small companies really melded well together. Weekly meetings, IRC and Skype, shared source code, Basecamp, Trello and a mishmash of other tools helped collaboration.

Conclusion

Overall the development and launch of Stay.com 2.0 was a great success. The user feedback has been great and we’re proud of what we developed. The app has a 4 star rating on Google Play and 4+ on iTunes. Although the initial launch was in mid-June 2012 – we’re still working full-time on the Android and iOS versions, continuously fixing bugs and adding new features.

Designing assets for app developers

The development of apps is becoming more professional. As a result of this specialists like graphic designers are more often the creators of the look of an app these days. However, it’s still very much the realm of the programmer to deconstruct the design – and breath life into it. As a graphic designer, you can either help or hinder the developer in this job. It all depends on the assets you provide. Here is a list of best practices for graphic designers delivering assets to mobile developers. I assume the original designs are made with Photoshop/ Illustrator/ GiMP and that the programmer prefers them as 24bit .PNGs with an alpha channel.

1. Break up your screens into UI elements

It’s a good idea to provide mock-up screens  as a reference –  but these are not the files a developer wants to work with. You need to break the design apart into its different UI elements. Any button, frame, indicator, switch, arrow, toggle that you designed needs to be provided  in a separate file. If you leave this task to the developer your design might suffer inferior Photoshop skills and you’re wasting his time.

2. USE LAYERS, align them, provide all states

In each element file you need to provide all the states and color variations as separate layers. Take a custom button as an example. It comes in three colors and has two states (normal and pressed). That means you have to provide a button.psd with  six  layers: “black_normal”, “black_pressed”, “blue_normal” … you get the idea. Make sure to provide complete sets here. If you leave out layers, you’ve left the completion of your design to the programmer.  When you have complex set of layers where it is not obvious how they interact, make it simple for people by creating Layer comps in Photoshop. Also, make sure you’ve aligned the content of the different layers to their correct positions. The programmer should be able to simply save each layer in a separate .PNG without any extra work.

3. Use a sensible naming convention

If you pick a sensible naming convention for your files the programmer can adopt them and carry them on into the code with their original names. This makes it easier for both parties when designs needs to be updated, changed or expanded. Sensible file names from a programmers perspective means:

  • follow a consistent naming pattern. Example: header_button.psd, header_gradient.psd, header_logo.psd or similar.
  • use safe characters: lowercase a-z, 0-9 and _

4. Align to pixels

This really shouldn’t need telling, but apparently still does: Align your shapes to pixels. This means, almost without exception, any shape you add to your design must have a top-left and width-height that is in full-pixel values. This can be done easily in Illustrator, and moderately easily in Photoshop (“Snap to pixels” in the Shapes dialog). Coming back to the programmer with miss-aligned half pixels  is literally like flipping him the bird.

5. Summarize your color, font and margin choices

A lot of what the programmer ends up doing is condensing your design into reusable components and variables, hopefully without compromising its look. You can help in this by providing a list of your design guidelines. Ideally this list would contain your choices of:

  • Colors: text colors, button colors, list colors, effect colors
  • Gradients: backgrounds, effects etc.
  • Fonts: list of faces used, list of sizes used, shadow effect settings
  • Margins/Paddings: numbers for guides or grids used

6. Make your graphics scalable

It is no longer realistic to believe you are designing for one resolution or platform. More likely your design will be used for developing apps on both tablets and mobile phones across multiple platforms. Your design needs to be scaleable. You should always use vector shapes, your gradients and effects should be scaleable, you should never use pixmaps, your fonts should be readily available or embedded in the file. Basically, your image should look good rasterized to any size.

7. Tips for the elite designer

If you’re already following the above guidelines you’re making most  app developer happy. But if you want to go the extra mile, here are some tips to make your programmer even happier:

  • create scripts the programmer can run to render all assets to an arbitrary resolution
  • put your designs into any sort of version control system (git / svn / rcs / perforce)  - we honestly don’t care. Anything is better than zip files over mail, dropbox or whatever.
  • pre-render the assets to our current target resolutions – we’d love you for it.

Icons by http://dryicons.com