SwiftSpringBoard: implementing the iOS home screen layout
SwiftSpringBoard is a project meant to reproduce iOS’s home screen icons disposition and features.
Genesis
The need for SwiftSpringBoard came from one of our clients who uses a collection view for the home screen of his iOS application. This client was willing to include the Apple-style home buttons re-ordering functionality and the ability to hide cells as an evolution.
We needed a component able to accomplish these features:
- Presenting items in the same way applications are displayed on the iOS home screen
- Re-ordering (with drag & drop) elements on one or more pages of the screen
- Deleting elements from the screen
The first thing we did of course was to look up the available frameworks that could fit our needs. And if you do so yourself, you’ll probably come to the same conclusion we did: first of all, a very small number of frameworks are relevant for our goal, and secondly as of November 2017 most the tools available did not received an update for at least two years.
Setup
Our library relies on 4 types of objects:
- SpringBoardView: the view displaying the home screen-style items (subclass of UICollectionView)
- SpringBoardManager: the object implementing the core logic of the view behavior
- SpringBoardDataSource: the protocol the application uses to setup the component
- SpringBoardLayout: the custom layout used by the view (subclass of UICollectionViewFlowLayout)
To minimize headaches and unnecessary re-implementations (and to maximize the understanding by the rest of the world), the SwiftSpringBoard component uses mostly standard behaviors from UICollectionViews: since iOS 9.0, UICollectionViews are natively able to offer a re-ordering mechanism that suits basic needs. Furthermore, UIScrollViews are able to use paging since iOS 2.0. Combined together, these features offer us a solid starting point for our needs.
Loading the Content
We designed the SpringBoardDataSource protocol so that users of the classic UICollectionView mechanism would not get lost. First, the user must set the number of columns and rows his spring board will use on a single page. To do so, the user must implement the following methods:
The number of pages in the spring board is passed in a similar way:
Finally, to load the items themselves, the user needs to implement the following methods:
Which should be familiar to UICollectionViewDataSource users.
Receiving events
The methods called by the component to notify interactions are pretty straightforward for UICollectionViewDelegate users:
Understanding the Layout
The layout of the spring board is computed using the sectionInsets, minimuInterItemSpacing and minimumLineSpacing properties found on UICollectionViewFlowLayouts.
We decided to let the user choose what sizing mode should be used: the SpringBoardView object takes an optional itemSize parameter. If set to nil, the layout of the items will be computed to fill the available space in the view. Otherwise, the items will have a fixed size and will be spaced evenly in the view. The trickiest part of the project was to handle moving items between screens. We chose to consider each page as a different section of the spring board. As a subclass of UICollectionViewFlowLayout, the layout’s default behaviour is to compute the items’ positions according to the scrolling direction:
For a vertical scrolling, items will be loaded row after row:
For an horizontal scrolling, items will be loaded column after column:
The problem is, since paging in the home screen occurs horizontally, we have to stick with horizontal scroll. But as you can see, vertical scroll places items in the way one would expect home items to be placed. So we had to compute item positions ourselves the way a vertical layout would. Computing item positions ourselves meant handling item creation and deletion, otherwise we would be keeping references to useless variables which most certainly causes crashes when working with UIKit’s default components, and we would be unaware of new items being added to the view, meaning they would never be displayed. The layout would also have to handle pages that would not be entirely filled, which is the behavior we can see on the home screen.
After much troubleshooting we succeeded at handling the layout and its several updates. But part of the component’s logic still has to be handled by the user, since he is the only one with full access to the raw data that is loaded in the spring board.
Example Implementation
Let’s say your spring board data is composed of arrays of numbers stored in one main array called dataContent. Your implementation for the SpringBoardDataSource should look something like this:
Future Improvements
As of today, several ways in which we intend to improve SwiftSpringBoard include:
- Dynamic columns & rows counts: This will be our next evolution. As of today the user has to set manually its number of rows and columns for the layout to compute dimensions properly. We expect to accomplish an automatic computation of the number of rows and columns based solely on the insets and spacing attributes of the layout and a fixed size for the items.
- Handling folders: Although users can already implement this behavior, we are looking for a clean and simple way to add this feature to our library. An option would be to create another instance of SpringBoardView for the opened folder.
If you happen to use our component, we are really curious as to what you will do with it. And if you have any question / suggestion, feel free to contact us.
Do you want to know more about Wassa?
Wassa is an innovative digital agency expert in Indoor Location and Computer Vision. Whether you are looking to help your customers to find their way in a building, enhance the user experience of your products, collect data about your customers or analyze the human traffic and behavior in a location, our Innovation Lab brings scientific expertise to design the most adapted solution to your goals.
Find us on:
