Why Open Source?
In last week’s post, I introduced you to Pager – my iOS UI library for better mobile navigation. In this post, I’ll be exploring why I decided to go down that route with Pager – highlighting the many benefits of Open Source software.
When I first considered using Open Source with Pager, I wanted to ensure that I was isolating a component that would save my fellow app developers a great deal of time and energy. In order to meet these expectations, and for the component to be reusable, it needed to be highly customisable and easy to set up.
Before proceeding, I made a list of both the functional and non-functional requirements.
It needed to…
- Display a top menu to navigate between the different pages.
- Be able to set a title for each item in the menu.
- Allow for scroll interaction between the different pages.
- Present the detail view when tapping or scrolling forwards and backwards.
- Enable interaction with the detail view.
- Allow customisation of labels, colours and interaction.
It needed to…
- Have a smooth scrolling transition.
- Scroll fast but not have a significant performance impact on the device.
- Look like a native iOS component and make use of only standard UIKit interface elements.
Using Container View Controller
When considering the build, as well as what APIs UIKIt provides, the Container View Controller stood out.
Container view controllers allow developers to add a view controller to its view. It’s an effective way to decouple a view, and the logic around its subviews, making it reusable in various other places in the UI.
This solution allows us to break down the MenuViewController and the PageViewController in separate components and display them simultaneously in the same UIWindow.
The Container controller hides that and exposes the methods to configure the component, like so…
It allows for instantiation and configuration:
My future Open Source plans
Pager is far from perfect.
One of my short-term goals is to improve its functionality. For instance, I want to reduce the dependencies it introduces to its clients – solely using abstractions instead. I still haven’t figured out if I want people to be able to contribute to the project. The short answer is probably not (or at least not on a regular basis). The component is intended to be easily extendable but it now achieves what it was intended for.
I will, however, be continuing to Open Source other projects. I am particularly motivated to create small reusable and well-tested components as these work to reduce the size of applications, are faster to extend and don’t break often. Watch this space!
Why Open Source your project?
My goal when I started writing Pager, from an architectural point of view, was to create something that was:
- Resistant to change.
- Easy to understand.
- Usable and useful.
- Built on best practices.
Open sourcing your project will force you to work in a more modular way. When working in this way, your code is constrained to its own domain so it needs to have a clear interface and good encapsulation. Good encapsulation means having a cohesive set of data and functions by hiding the data and exposing just a few functions.
On isolating the Pager component, I also reduced its complexity and achieved high relatability as its codebase doesn’t have any dependencies. This will also reduce the complexity on the clients using Pager.
Should you launch your own Open Source project?
The short answer is yes because, no matter the outcome, launching your own project is a great way to learn how the world of Open Source works. Generally speaking, you should only Open Source your project when you feel comfortable having others view it and give feedback.
Programming is like any other creative discipline. It can feel scary to share your work with the world but the only way to get better is to practice. What are important things to consider before sharing your project?
Set your Open Source goals
Set yourself some Open Source goals to give a much clearer overview of your motivations and the problems you’re looking to solve.
Start by asking yourself: Why am I open sourcing this project? How will it help people? What does it need to include to achieve this?
You may have multiple goals for a single project. That’s to be expected.
Organise your documentation
No matter what stage of the process you decide to Open Source your project, every project should include the following documentation:
- Open Source license.
- Contributing guidelines.
- Code of conduct.
As a maintainer, these components will help you to communicate expectations, manage contributions and protect everyone’s legal rights (including your own). If your project is on GitHub, putting these files in your root directory, with the recommended filenames, will help GitHub recognise and automatically surface them to your readers.
Head to the Open Source guidelines for more information on starting your project.
In short, you should try Open Source!
You don’t want to be re-inventing the wheel and extracting non-domain specific code all the time. If you have an idea that you feel could make a difference to fellow developers, give it a go! Do you love Open Source projects? What are your top Open Source libraries and why? Tweet us at @WeAreMobile1st and we’ll retweet your responses.
We Are Mobile First is a digital product agency based in Barcelona. Follow us on Twitter, LinkedIn or Medium to be notified of our future posts and company updates. We share weekly posts on everything from how to create easy animations for your Android app to advice for new developers.