The Showmax iOS team has released the SHMTableView library, a wrapper for UITableView data sources. With this nifty little tool, you can maximize your iOS application’s UX while minimizing boilerplate.
SHMTableView is a wrapper around your UITableView datasource, that helps you define table contents by mapping view types to model instances.
As Showmax’s resident Apple fanatic, I’ve long been disappointed by Apple’s lack of progress in developing UITableViews. Sure, it’s a common and generalized approach that lets you build just about anything, but there’s no extra middle layer to help you and make your life easier.
You have to waste a lot of time doing repetitive busywork. You’re probably familiar with having to make and maintain something like this.
Look at all those methods. It’s a mess.
One of the problems is that it’s based on indexes. Developers have to handle all those indexes, which makes the code hard to read and a bother to use.
Wouldn’t you like to get rid of those indexes? Me too. Fortunately, at Showmax, we love to solve problems and share our results with community. This is the story of how we made SHMTableViews.
I’ve had this idea for several years now. At first I was fine with the status quo, but after all the repetitive busywork, it came into my mind that it would be nice to have something that would take care of it for me instead. I didn’t know if it was possible, but when Swift came out I saw a way to make it happen, and a few months ago I finally had the time to give it a try at Showmax.
In the fast-evolving world of delivering subscription video on demand, it’s not practical to manage the tables as the SDK suggests - using UITableViews delegates. In the Showmax iOS application, we always have to support at least two different layouts, based on UX parameters. A single user can view up to four different layouts for different purposes.
Maintaining this kind of code complexity inevitably leads to problems, and we’d prefer to avoid problems by doing things a better way from the beginning.
Compare these two examples. There are two different UX layouts, which makes managing UITableViews complicated. Using the SDK this way is painful.
To get acceptable results, you waste a lot of time with tedious, repetitive work. There’s been no good tool to encapsulate this effort.
I’m not alone in disliking UITableViews. I’d like to drop all the SDK methods. All of them. Including the dependency on indexes. Instead I want to work just with the data.
I’ve long thought that passing that data through a blackbox logic module should work. So I tried it and it worked. Now, with my colleagues at Showmax, we’ve improved it, and now we are releasing SHMTableView so you can try it too (requires iOS SDK8 or later).
Before SHMTableView
This is how iOS asset details page used to look like.
We weren’t satisfied with our design so we kept digging for a new approach. We wanted a modern look as well as something we could easily and efficiently transform. We had to support a variety of use cases from the product and UX perspective. Above all, we needed solid automated UI testing. After several iterations we arrived at a good design.
Showmax UX with SHMTableView
The new Showmax design represents huge progress on both the UX and UI sides. Basically we present two different view levels to help our users find and watch the programs they like.
The level one view shows the information for a season of a television series. The level two view shows the details for an episode, and lists the episodes that follow.
For us, the question is how to make it work, what is the best code architecture, and which UI elements can we combine to get the desired interactions.
You can see the same blocks in both views, only the order is different. But there are also new sections which behave differently depending on the planned user experience. In the near future, we’ll be sure to add more variations and views. So we wanted to get this right, without creating future maintenance issues.
Most mobile screens serve as a place for one simple feature like the settings screen, sign in/out, grids with uniform items, and so on. If your app is like this, you’ve got no problems.
Often it gets more complex, usually in the details pages. You may have screens which need to carry more atomized information, requiring different structures. Think of common data you have to display, like opening hours (probably a table), gallery (maybe a grid of pictures), important phone numbers (simple lists), emails, synopsis, and so on. Individually, they don’t present a problem, but the more you combine them the more complexity you create.
The situation gets worse and worse with every new piece of data which needs to be added to the details screen. Of course, there are different ways to deal with this. We considered several options, but they didn’t suit our needs. (Contact us for details of the options we tried and rejected.)
Minimum Effort, Maximum Results
Our team was influenced by the Generics approach in Swift, and used this concept to guide our thinking.
The philosophy behind SHMTableView is to be generic. We want to avoid doing the boring repetitive stuff, and find some way to get the same results with less effort.
SHMTableView is a wrapper around your UITableView datasource, that helps you define table contents by mapping view types to model instances.
SHMTableView helps you abstract away the routine stuff in UITableViewDataSource and UITableViewDelegate. Instead you can focus on structure and content to be displayed by UITableView.
To use SHMTableView, you must:
- Create data model instances
- Map data models to view types
- Pass your mapping to the SHMTableView library
SHMTableView creates and configures all UITableViewCell instances to be displayed in your UITableView. Here’s a look at the architecture in Swift.
With SHMTableView, you don’t have to use delegates. You can focus on connecting your data to the UI.
Our little tool takes care of all that boring stuff, it works, it’s been tested, and we are using it in production right now.
Your UI still follows the same principles and guidelines without changing the business logic of UITableView, but the way you can work with data is totally different. We’ve wrapped it up in a much nicer API and added logic to quickly create what is typically boilerplate code.
Our little tool takes care of all that boring stuff, it works, it’s been tested, and we are using it in production right now.
It’s super cool that Showmax encourages us to do cool projects like this, and then share what we’ve made.
My 2 day prototype worked (not perfectly, but it worked) and showed it was possible, then Michal and Ondřej joined the effort and a month later we had a working version.
Since we started using SHMTableView we estimate that we’ve cut 30% off our required time to develop a screen based on tables.
It’s in production at Showmax, and we’re now finishing documentation, performing more testing, and writing some tutorial examples.
The SHMTableView (v.1.0) was released as open source under an Apache 2.0 license. It’s available now at github.
