In search for a different perspective
Less than a 30 days and we’ll face the official version of Marzipan, the Apple’s vision for a Universal Platform. Officially it’s a port of the UIKit framework for macOS… pretty funny if you think UIKit was born from a rib of AppKit for OSX in late 2007.
But today is a very different worldthan 2000s; this is a world where most of the Apple devs never approached Cocoa programming and the AppKit itself when considered, at best, is the old mistreated father.
In the early days before WWDC 2018 lots of devs started dreaming about a new functional-inspired UI framework which is able to replace some of the oddities of the AppKit heritage in UIKit.
In a post-reactive world everyone is talking about stream, observable, function as first citizen as the next Holy Grail. I love it.
But we need to be serious about our job, dude.
A framework must be a tool to support and move a business, not a fancy playground for developers: it must be stable and reliable over the time (I’m in ❥ withSwift but actually I’m very happy to see Obj-C hanging around).
UIKit mostlyworks fine and it’s based onsolid foundations(more than 30 yearsof story and evolution baby);it’s not another JS frameworkwhich may disappear tomorrow, at best.
But the good news is this:
Influences and trends are part of the game of the evolution; they are the way to improve, disrupt the status quo and provide a new fresh view over the world.
So learning newtool, a new language or doing something new is a chance to look at a world from a different perspective and get different solutions. Some of these disrupting ideas may be the start of a new journey.
A tale of lists
This story starts more than a year ago.
While I was writing yet another table view I suddenly stopped and started thinking about how much boilerplate code I wrote every fucking tim just to put some elements in a sequence.
As Tool Builders our critical capacity over our job is essential.
It’s not just a matter of clean code (whatever that means) but a mindset where:
- (as good engineer)You need to have a positive impacton your teammates. While coding is very personal, sharing your work and having it exposed to the feedback of the team is a huge source of growth.
- You just stop thinking how good you areat your job(especially if you think you’re senior-something) and put think how big is the world and how much you still have to learn.
- You’re living in an ever-changing world: it’s part of your job to question your approach, question your tools, stop always taking all as a dogmajust because you’re using daily since years.
Frameworks/Libraries & Tools can have a doublelife from a developer perspective: they can be source of good practices(especially at the beginning of a career), while their limitations (in a specific context) can be the propulsive thrust need to move over.
Frankly I got bored fighting with delegates, data sources, double check of the indexes, write stupid calls in the correct order to get animations without crashes. IMHO these stuff should be taken for granted in 2019…
It was time to question this approach.
Inside of every problemlies an opportunity to grow or change.
Be inspired, look out the walled garden
So that day I decided to question a UIKit approach; that’s bloody arrogant, actually, Daniele. But I just need of fresh air…
I suddenly closed Xcode (or it was incidentallycrashed?) and started looking around for inspirations.
Inspiration is a strange beast; usually the best thing you can do is to stop thinking your problem and do something else.
But before to let your creativity run wild you should put some stuff in the works, so:
I opened my web browser to investigate how lists are managed in different platforms. I spent the next three hours just looking outside my walled garden.
IGListKit, Reactive Programming, — a coffee break — Android, Web — the sunny day outside…
The most arrogant thing you can do, is not to question the status quo, but to be certain of the right answer lies only inside your knowledge.
Before ever writing one line of code is your precise duty to make research. And it’s not about looking at one answer in StackOverflow; it’s more to see how people approach problems, because there is a world behind every choice and you may miss the most useful one just because you’re lazy or arrogant.
You can always learn something new.
It’s matter of goals
At the end of search I had a clear vision of the problems I would to solve and how other devs approached the problem.
It’s time to grab sketchpad and play out different scenarios.
Imagine that you are a five-year-old kid and try to warm up your problem-solving imagination with countless questions:‘what if’, ‘why not’, ‘can we’, ‘how about’, etc. What rules should we break? What beliefs should we drop?The motto of this technique is always the same: ‘Look at things from a different perspective’.
Asking compelling questions is a pre-problem-solving stage that allows brains to play out different scenarios and broaden decision-making proces.
For Every Yes There Are A Thousand No’s
At the end of the process I finally got a coincise list which breakout the problem along with a possible initial approach.
An idea for a new approach
That’s my checklist, sorted by importance:
1. I want a type-safe codeas much as I can
A type-strict approach can help reduce the likelihood of some kinds of errors, force us to think carefully what we write and prevents code crashes and errors in production.
My approach must allow to access at models & cells instances of a table knowing exactly the type of the object. I want to reduce type-casting as much as I can.
2. Declare the content, not describe how to make it
I like the declarative approach to UI design; even with limitations it’s a good way to put the focus on content and forget how it works.
3. Connect Models & UI but keep them separated
Tables and collections offers a graphical representation for one or more data model objects. I would to encapsulate this strict relationship in a single entity but in the meantime I would to keep their uniqueness. TableAdapter(the name is clearly inspired by Android)is its name; when you create an adapter you are saying: “I want to look at this Model with this UI”.
4. Consolidate Events by dropping the delegate/datasource approach
I should premise, this is very questionable: I don’t like datasource & delegates and still prefer callbacks where available: I would to look at one place and delegates tends to spread over the codeeven if you //MARK this or that.
The idea is to consolidate the points where to configure cells, headers or manage the content of the list. Each adapter, with its
eventsproperty, can handle cell/model configuration and behaviour.
5. Let’s the machine do the animations
I don’t want to write tons of code just to perform simple animations, neither spent time debugging weird behaviour because I’ve put these calls in the wrong order.
This is clearly a job for a machine; I’m just a human!
Crafting around the intention
The entire work took me several months (not full-time obviously), a huge amount of time for a library, even if complex.
Typically with a clear plan I could end with an MVP in a reasonable amount of time, but with new stuff everything is different: the most challenging part it is also the biggest source of problems and doubts.
Then, suddenly, two problems have come up:
– I would the project to be perfect from any point of view: the architecture, the code. Everything is a great excuse to rewrite it while time passed
– People suggested me some edge cases to keep in mind
During the following months I got several other ideas, changed my perspective countless times, then I started to iterate over and over again because I CAN DO IT MUCH BETTER, FOR SURE.
On other hand it was just a side project.
You cannot be a perfectionist (especially in software development) because there will be not a point in a story where you will end up with all the informations.
The maze will always be incomplete and you need to face and live with this uncertainty: it’s your job.
So stop blaming your managers because you are frustrated by changes: if you want to be a senior developer you need to manage uncertainty.
Don’t be surprised if goals change. They are never simple and the process of deciding will help you uncover goals that may not have been explicit.
Lot of times goals are discovered not handed down; you need to accept and adapt to it.
The first iterationtooks over 2 months of works and tests, from August to Sept 2017. Then I’ve started using it in a production project and, suddenly, the world “fall apart”: some approaches are not scalable, some others are clearly an eyesore.
Some suggestions solves edge cases but shaped the entire architecture.
I had big performance issues which lies in the architecture design; essentially I had broken the good design of UIKit to craft a monster.
Even with all the carefulness I put in it, it didn’t worked as I expected.
It was a failure!
When you love your work you put all of your energies in it.
You are expecting every decision you took was the most rational one.
So you are tempted to take your time. Too much time.
In this scenario the risk of obsessively collecting more and more information instead of making decision is high.
This is called hypervigilance.
How many times I have rewritten that code? I stopped counting.
Months passed writing code just for my pleasure.
You need to collect just the relevant data in a reasonable amount of time, then make the best choice for the actual context. Validation must be the primary goal.
No amount of research can make the decision safe, rational or completely objective. You can’t make the perfect decision, and it can be counter-productive to try.
There comes a point with you have to stop searching and start deciding. Aculture of fear can be a serious barrier to your growth.
On April 2018, after several months of inactivity on the project, I eventually end up with another variant of the approach which is able to solve the major issues.
I started focusing only on my main goals to produce a much stable version. I used it in production projects effectively; these months gave to me the opportunity to refine and craft the entire architecture.
I’m ready to move forward; I used few other weeks to consolidate the APIs and the architecture, add support for collection view and works on a production ready animation engine.
And May 2019 has come…
It’s time for a premiere
The library is out; Owl is the final name of the project and that’s the repository. It was a long journey full of old & new lessons and mistakes.
But after-all, what you can achieve with Owl?
This is example which shows an Address Book; even if it’s pretty silly it’s a good way to look at how powerful and coincise it can be:
We just declared an adapter: it just say “Hey table, use
<em>ContactCell</em>to render the
<em>Contact</em>model”.Then we assign some behaviour (dequeue, didSelect, shouldHighlight) to all models rendered by this adapter.
In each of these events you will receive what I call context
ctxit contains all the necessary information about the involved model object and it’s cell. All of these infos are obviously type-safe.
You will have an adapter for each pair of
{Model,UI}you have registered.
The next interesting part is the declarative patterat the end; we just need to create sections for table, add elements inside and say “director add this section here and render it”. Pretty simple uh?
Clearly you can manage the tables by adding elements, moving elements between sections, removing sections and all of these stuff.
Finally I’d like spend some words on update; Owl implements a little variation of DifferenceKit, one of the best/fastest framework you can choose to compare changes in dataset(it’s based upon an original paper by Paul Heckel). It’s really fast… faster than RxDatasources or IGListKit!
But how it works exactly?
Completely transparent!Just call the reload()function and perform changes to your data model. At the end of the operation Owl will discover changes between dataset before/after your changes and produce a changeset of animations. Automagically!
I’m very happy of the result and… you know what? As I said above it’s just the beginning: I plan to add scrollable stackview and several other interesting features.
But now, with an official public project, you can help me moving this arrogantapproach further: