One suggestion made at our GitHub project was to keep grid items at a fixed size. The original implementation let you specify the number of columns, and then automatically resized your grid items based on the available space. However, there are some cases where you would prefer for the grid items to keep a consistent size, and vary the number of columns. This is particularly useful for cases like presenting a gallery of image thumbnails, where aspect ratio is important.

For example, the previous implementation running on a handset might look like the following.

Sectioned grid with 2 columns specified.

When using the new mode, it’s possible to specify that every item should be 190dp by 190dp large. This will keep every item as a perfect square, regardless of the screen size or device orientation. The following four screens show the same layout rendering on a Nexus 4 and a Nexus 7 in both horizontal and vertical orientations.

As a bonus, when using this mode you can use a single layout for all screen sizes without needing to use configuration qualifiers. Depending on your app needs, you still might want to provide an alternative layout; for example, you might specify a larger item size in layout-w720dp if you would like to show larger thumbnails on tablets.

Our updated version of the Sectioned Grid Adapter is now available for pulling. By default it maintains the previous behavior of varying column widths. To switch to the new method of varying the number of columns, pass the argument SectionableAdapter.MODE_VARY_COUNT to the SectionableAdapter constructor.

You will need to slightly tweak your layouts as well. When using the default behavior (now called MODE_VARY_WIDTHS), the number of columns is determined from the number of child item elements in a row.

When using MODE_VARY_COUNT, the adapter will automatically determine how many columns will fit in your rows. Just supply enough items to support your expected maximum count. The adapter will hide any unused items.

Finally, you’ll want to omit layout_weight for your grid items, since this would cause Android to stretch them out. Just provide specific values for your layout_width and layout_height.

If you choose to specify the widths of your columns, try to pick values that fit well into a variety of screen sizes. This should help avoid showing too much empty space on the end of your rows. Of course, you could also use other approaches like horizontally aligning your grid to make it look balanced.

Feel free to check out the project. Hopefully it will serve you as well as it has served us!

Well it’s not. Introducing Harlem Shake for iOS.

Here’s another example using MusicID:

It’s super easy to use. Just give it a view to do the initial ‘dance’ like so:

Then when you want craziness to ensue:

Please don’t ship this. And before you say anything, we know this is incredibly dumb. We promise we’ll release some real open source soon enough.

Enjoy!

Here at Velos, we’ve often found that presenting information in a grid format can look really sharp on tablet devices. You can present many grid items in a single row, which lets the user see a lot of information before they need to start scrolling. Since grids with fewer columns present nicely on handsets as well, it’s also a good way to maintain consistency between handset and tablet while still taking advantage of each device’s strengths.

There is a pretty significant limitation with the standard Android GridView, though: it cannot be sectioned. Like with the ListView, there’s no API-level ability to add sections that divide up the items within your collection. Designers still enjoy specifying them, though, and for good reason: section headers help give users crucial context and help them more easily navigate through a large body of information.

We had previously tackled the section header limitation for basic scrolling lists, but what about grids? Imagine that we want to create an app that presents the books in a user’s library. To make it easier to browse, we’ll put each author in a separate section. That way, you can quickly scroll down to find your author, and then look through the rows to find your particular book. (It’s tricky to find an author who’s buried between two other, more prolific writers.) The app might look something like this on a tablet:

Sectioned grid displayed on a tablet.

A phone could use a list, or just fewer columns, like so:

Sectioned grid displayed on a phone.

This isn’t supported with any native Android UI components (at least, not to the best of my knowledge), but proved to be relatively simple to implement. The key is to forget about overriding GridView, and instead build this as a complex ListView. From the ListView’s perspective, each row is a single item; we can then enhance the Adapter subclass to manage the logic of translating to the specific item in each row.

When you take this approach, your Activity and ListView are very simple. All the grunt work needed to define sections, determine how many items fit within each section, where to display the headers, and so on, can be handled within the Adapter subclass.

We have created a reusable component that does exactly this, called SectionableAdapter. A SectionableAdapter overrides two important methods. getCount() handles the conversion between the actual number of items to display and the number of rows required to display them. For example, in the first screenshot above, the screen is displaying 17 items, split across 3 different sections, for a total of 4 rows. To do this, we keep track of how many cells we can fit in each row.

Secondly, getView() similarly manages the translation between the list row, and the items within that row. From Android’s perspective, “David Mitchell” is a single list item; internally, we expand the 5 data items to draw within that row.

You can subclass SectionableAdapter and set it on your ListView to create your own sectioned grid. You just need to provide a few pieces of information.

1. Create an XML layout file for each row within your grid. This will probably include an optional section header at the top, and one or more cell items below. You’ll likely want to create at least two versions of this file, one for handset and one for tablet, and you may even want to create different tablet versions to optimize for both 7″ and 10″ screens, or for tablets in portrait orientation.
2. Tell the adapter the resource IDs you have defined for the header and to hold your cell items. SectionableAdapter will then manage all the bookkeeping around this: determining whether the header should be made visible, counting the number of columns in your grid, etc.
3. Implement the abstract methods that tell the adapter how many sections you want to support, how many items are in each section, and what header to use for each section. These are completely under your control, and depending on how you source your Adapter data source they may be statically defined, loaded from the network, driven by user input, etc.
4. Finally, implement the bindView() method. This is basically equivalent to the standard getView() method, except the adapter has already taken care of the boilerplate tasks like recycling views, inflating new views if necessary, and so on. All you need to do now is populate your item’s UI, and attach any click handlers or other controls you want to support.

Also of note: if you still want sectioned data, but want to present it in a list instead of a grid, that is supported by SectionableAdapter as a degenerate case where you provide a single column. This might be a useful approach if you are using fragments and don’t have much horizontal space on a tablet.

This class has served us very well so far. If you’d like to give it a whirl yourself, or check out the full code, head on over to our GitHub repository.

UICollectionView

This used to be a lot harder.

Older versions of iOS didn’t have a built-in control for displaying grid views, similar to the ones in Pinterest or iBooks. Anyone implementing a more complex UI (like Cover Flow) had to either hope a good open-source version existed or start from scratch.

Collection Views solve all these problems and more. Out of the box, it works just like a table view, but with the contents displayed in a grid. Built-in APIs make it easy to customize how the background, different sections, and individual items are displayed. For more complex interfaces, it’s possible to redefine how items are arranged using a layout manager.

Ash Furrow has a great article about using UICollectionView with NSFetchedResultsController to make developing custom UI components even easier. And yes, collection views can even be used to re-create Cover Flow.

Maps and Routing

Vector mapping means we can finally view The Embarcadero like it’s the end of the world.

There’s been a lot of press coverage since iOS 6 launched about what the switch from Google Maps data means for users. As unfortunate as some of the launch bugs might be, there are more than enough useful additions on the developer side to make it worthwhile in the long run.

Using new APIs in MapKit, apps can now display the name, phone number, and URL for one or many locations directly in the Maps app, or display this information while getting directions. Apps can now also provide directions between two addresses, opening up an entirely new way of interacting with apps that provide information about transit, highways, bicycles, and even cabs.

Sharing

iOS 6 adds a new Social framework. Building on the Twitter framework from iOS 5, it allows users to post to Facebook, Twitter, or Sina Weibo, without having to enter their username and password in every app they want to share from.

There’s also a new Activity View Controller, which you probably know better as the new sharing sheet in Safari. It can display a mix of built-in services (like Facebook or Twitter sharing) and custom options your app defines (like printing, or reposting on your own social network).

An Activity View Controller in Safari on iOS 6.

Using the Social framework and Activity controllers in iOS 6 make sharing easier for users and faster for developers.

Should my new app require iOS 6?

iOS adoption statistics courtesy David Smith.

These APIs are great, but are they enough to require iOS 6? The answer to that question really depends on the app that’s being developed. But with these great new APIs, the ease of over-the-air updates, and stats like the chart above, we think the answer for most of our clients is a resounding yes.

There are several approaches to doing wireframing and many tools that can help you wireframe. At Velos, we use Omnigraffle Pro, combined with our custom stencil composed of several freely available resources.

Create a Template

You’ll want a template which provides the background for your wireframes. Here are some simple steps to make your own template:

1. Go to File > New Resource > New Template…
2. Choose a Blank file.
3. Modify the Canvas Size and Canvas Grid inspectors to be the following:

4. Save as “Wireframe” in the Templates directory.

By setting snap to grid and having the major spacing be 10px with 10 steps, we can get pixel accurate wireframes. If you don’t set these, your views won’t fall on pixel boundaries as you nudge them around.

Create a Stencil

You’ll want to gather all your wireframing resources in one place. Perhaps you have a particular style to which you’d like to adhere. We’ve compiled our own Stencil from various sources. Here are some valuable stencil components that you can use to create your own.

• iPad/iPhone wireframe Stencil by David Morford.
• Twitter Bootstrap Stencil by Vigit.
• Glyphish Icons. The vector versions of these icons work great in Omnigraffle to provide placeholder iconography.

Add Flow Graphics

In order to make the flow of your wires obvious, you’ll want to have graphics that make it clear how a user gets from one screen to another. Omnigraffle Pro has quite a few arrow designs. We’ve set up arrows that jump over other arrows for easy visibility and also uses an orthogonal path.

Showing touches is important too. To illustrate a touch, we use circle with a semitransparent, large stroke. The end result looks something like this:

Our Stencil

To get you started, download a simplified version of our stencil. It has some other interesting things in it like vector forms of our branding and typography we commonly use. This allows you to keep a consistent style.

Example Wireframe

Once everything is set up properly, it’s very easy to produce high quality wireframes. I’ve created a simple example out of Mail for iOS. It isn’t complete, but it gives you an idea of what the software is capable of.

⬇ Example.graffle

Adapting to Changes

Android device fragmentation affects all aspects of development, but differences in screens probably have the biggest impacts on an app’s visual design. A few common resolutions account for the most popular devices: 1280×800, 480×800, 480×854, 1280×720, and 1024×600 will cover most of today’s popular handsets and tablets. But, there will always be device manufacturers large and small that want to “push the boundaries” by releasing their own unique screens. Remember when the Droid X 2 came out? Motorola helpfully increased the screen resolution from earlier Droids’ 480×800 to 540×960. That close-but-different size meant that many apps looked just a little wrong when running on the newer devices.

The simplest apps tend to do the best at running on a wide variety of Android screen sizes: as long as you stick to the default Android layouts and styles, the platform does a good job of resizing everything to fit appropriately. Unfortunately, this rarely looks impressive; it’s great for hobby projects or open-source apps, but I’ve never met a business that didn’t want to brand their app and make it look at least somewhat distinctive.

At the other extreme, many designers who are new to mobile software want to specify everything down to the pixel. They may pick two or three “target” screens, create a design that lays everything out precisely, and then hand it over to development to build. It’s easy to make this type of design run properly on the target devices, but harder to make it look correct on larger screens, and even more challenging to look good on smaller screens. It also can lead to some confused customers asking, “We already have the app running on a tablet that’s 800×480, why can’t we just put that same design on a phone that’s 480×800?”

Designing for Differences

You need two things to escape from the morass of Android screen layouts, a small tool and a big solution. The tool is to always use density-independent pixels (commonly expressed as “dp” or “dip”) in your layouts. Google has been very good at pushing this approach from the very beginning of Android, and describing the motivation behind it. A density-independent pixel will always occupy the same physical size on a screen, regardless of that screen’s dot pitch. 10 pixels on a ViewSonic 7″ tablet will be much larger than 10 pixels on a Samsung Galaxy S III; however, 10 dp will be the same size on each.

Density-independent pixels are not a panacea, though. Even if you create your tablet UI using dp units, the UI still may draw off the edge of the screen when you try and run it on a handset. As a general rule, Android designs tend to do well when running on screens that are physically larger than the ones they were created for, but not in the other way. We’ve found that the most skilled Android designers we work with tend to do the following.

1. Decide how many different designs you want to create. This is usually one handset and one tablet design, but it could easily be one small handset, one large handset, one 7″ tablet and one 10″ tablet.
2. For each design, build to the lowest common denominator: focus on the “worst” device that needs to be capable of running that app. If you want to use one design for both 480×800 and 480×854, design for the former, and it should look fine on the latter.
3. Decide whether to handle rotation. Android makes it fairly easy to support both portrait and landscape orientations, but it’s even easier (and cheaper) to only support one. People are used to portrait-only apps for handsets and landscape-only apps for tablets.
4. Try to keep app flow as consistent as possible across all designs, while taking advantage of the opportunities larger screens afford. That means using fragments or Master-Detail designs for tablets, which should ideally behave similarly to single-screen designs for handsets.
5. Design to the width, and let the height flow, scrolling vertically if necessary. This is the standard UI experience on most Android apps, including the pre-loaded apps like GMail and the browser.

Leave Room for More

Finally, the part that separates veteran designers from novices: describe where unclaimed space should go. This is what will future-proof your design, and ensure that it will look fine on screen sizes that you don’t have to specifically build for.

I’m not a designer, but here’s a rough sketch of the type of design I love receiving.

This looks different from a standard Photoshop-style design, which precisely positions every element at a specific location. Instead, this type of design gives sizes for most elements, describes the margins and borders for nested elements, and most importantly, describes where unallocated space should go. This last point allows the design to “scale up” to arbitrarily larger devices.

Partners in Design

Ultimately, a successful mobile app will depend on the coordination of designer and developer. The designer is responsible for creating an attractive and useful interface; the developer should help by providing technical feedback and encouraging the designer to think about what will happen if the app runs on different types of devices. Iteration of design helps a lot, and spending a few days or weeks at the start of a project to future-proof an app design can save weeks or months of headaches at the end. Developers, be good to your designers, because everyone will judge your app by what they produce; designers, consult your developers, because they will make your app feel as good as it looks.

Register for GitHub.

Using version control of some kind is not optional. I suggest using GIT with GitHub as it adds several tools to help with collaboration such as a news feed of activity, wiki and simple bug tracker.

Define some SCM best practices.

First, start your project off on the right foot with a proper git ignore file, which GitHub provides here. Next set some guidelines for commit messages. Since you’re using a bug tracker (see below), define how commits that fix bugs should be expressed. Here’s an example of a good commit message.

Fix for interaction being disabled for an entire view hierarchy on iOS 4.X whereas iOS 5.0 only disables interaction on the view being animated. Now the cancel button is tappable on iOS 4.X. Fixes #243.

Now here’s a bad commit message.

Fix for #243.

Make sure your team knows that you need a detailed commit message and a reference to the bug number using a unified format. Some bug trackers can parse bug numbers and assign commits to the actual bug, making a descriptive commit even more important.

Set up a bug tracker.

This part might seem optional or unnecessary on small projects. It’s not. Having a bug tracker helps keep your developers focused on remaining tasks and helps management define releases.

At the very least, use GitHub Issues. But consider something a little more full-featured such as JIRA.

It’s a good idea to set up best practices for your bug tracker too. Here are a couple of my personal best practices.

Everything goes in the bug tracker. No matter how trivial or silly a bug is, put it in the bug tracker. Don’t mention it to a developer over lunch and think that it will get fixed. It might, but it probably won’t.

Don’t mix up severity and priority and use both. Severity is how severe a bug is. Does it cause a crash? Does it delete user data? Does it set the user’s house on fire? Priority is how important a bug is to finish. This can (and should) factor in severity, but all Severity 1 bugs aren’t necessarily the highest priority. If you have a crasher, but you can only reproduce by doing 16 tasks in a particular order, it’s probably not the highest priority. Conversely, a typo would be of the lowest severity. But if it’s your product name on your splash screen, that should be high priority.

Use the features of the tracker. Add a build number to your bugs. Make sure that your bugs have target versions associated with them. Attach screenshots and include steps to reproduce. These all might seem obvious, but you’d be surprised how much time is wasted working off of incomplete bugs.

Use assignment and bug state in a structured way. When a bug first gets put into the system, it gets assigned to a QA manager. QA then verifies the bug exists and cleans up the bug description and steps to reproduce. After verification, QA assigns it to an engineer. When the engineer is done, the bug is marked as fixed (not closed) and assigned back to QA. When the bug is verified fixed, it is closed.

Register for TestFlight.

TestFlight allows you to distribute iOS builds over the air to groups of testers. It’s magic. TestFlight also supports distribution groups. Meaning you can choose where your builds go. Set up a “Continuous” distribution group for the automated builds. It should only include your development team and perhaps your QA. These builds are bleeding edge, so sometimes they are bug-filled.

Adding new testers to TestFlight is a breeze. Once a tester registers for TestFlight and installs a simple configuration profile, you immediately have access to her device identifier. So your new tester process will go something like this:

1. Invite them to your team on TestFlight.
2. Put them in a distribution group that makes sense.
3. Add the device to your provisioning portal.
4. Generate a new provisioning profile.
5. Add the profile to the build machine (see below).

Setup a build machine.

Your build machine sits there, listens for updates on GitHub, builds the latest source tree and pushes the new build to TestFlight. It is the hub that stitches all these pieces together.

Continuous integration is a valuable tool for development. Being able to discover bugs as soon as they develop is required for a quality software product. If bugs are only caught near the end of a development cycle, be prepared to blow right past the due date.

Several tools can help with this battle against bugs. Jenkins is a continuous integration tool that can kick off builds as soon as commits hit your repository. Tests can be run as part of the build and developers can be held personally responsible for failures introduced.

After a successful build, TestFlight can be used to push new builds directly to your testers. Automated, bleeding edge builds can be sent to your internal QA, and select builds can be promoted to your clients or external beta testers.

I won’t go into details, but if you’d like a good tutorial on setting up Jenkins + TestFlight, check out this tutorial.

Develop.

Ah, the hard part. Definitely integrate the TestFlight SDK into your app. It brings a couple cool features to the table:

• Crash reporting. This is the killer feature. TestFlight will collate and symbolicate your crash logs for you.
• The TFLog() calls for the sessions. In development, just define NSLog as TFLog.
• A list of activity in your application. By using “checkpoints” you can see when users are doing particular tasks.
• Update notifications. When your build server kicks out a new build, users of the old build will get an in-app notification of the build.

So that’s a high-level overview of best practices when developing a project on iOS. I use these steps even when I’m working by myself. When working in a small or large team, being able during the debug cycle to iterate on a bug and get a build to the testers within minutes, is incredibly valuable. Once you work on a project like this, going back to ad-hoc builds and disorganized bug reporting will be unthinkable.

This is great when it works, but makes it all the more annoying when they fail to behave. We recently ran into a problem while building a UI that involved several tabs. When launching a new Activity from a tab other than the first one, the app would crash with a NullPointerException deep within the FragmentManager call stack.

As usual, the open-source nature of Android makes these sorts of bugs easier to track down (have I mentioned how glad I am to finally have source again after going on a fast during the Honeycomb era?). It turns out that it’s  a problem with FragmentManager, which fails to create an internal Bundle under certain circumstances (specifically, if the internal “user visible hint” flag hasn’t been raised). A few enterprising souls have recently identified the bug, and Google should be patching it shortly.

Of course, there’s still a question of how to solve the problem. For now, we’re taking the approach of avoiding the bug by overriding onSaveInstanceState in our Activity and not calling through to the superclass. That works fine for our app, but if yours relies on this method to save its UI state, then you’ll need to selectively replicate that functionality, which would be tedious and risky. Once the bug is fixed, you can grab the updated build of the support package; however, this requires you to convert all of your Fragment-related code to use the android.support.v4 versions instead of the android.app versions, which in turn may cause other issues – for example, the android.support.v13 version of FragmentPagerAdapter uses regular Fragments and not the v4 support versions. Eventually the fix should show up in the standard platform version of FragmentManager, but not every device will necessarily get that fix.

The morals of the story: More recent additions to an API should be viewed with caution. Take advantage of the Android source code – if you haven’t already linked to it in Eclipse, I highly recommend it, as it will even make your own bugs easier to find. And do report real issues you find to Google so they can fix them.

Needless to say we didn’t even bother buying a coffee pot when we moved in, our neighbors will always make better coffee than our pot ever would have yielded. It kinda sucks that my first coffee blog post is probably the best coffee I have ever tasted, perhaps this will drain my motivation to make a second post? Nah.

One more reason to call a meeting with Velos and meet up in our hood, we’ll feed you coffee from FOURBARREL.

To celebrate our new offices, we had a few people over and called it an office warming. There was laughing, there was crying. There was also RockBand. See some shots below.