Category Archives: iOS

iOS

TIL: CoreSimulator logs

Adding an Intent Extension to an existing WatchKit app, and trying to run the project in the simulator immediately after will not work, at least on the latest Xcode9 beta.

The error message does not look very helpful:

Somehow I recalled reading a few days ago that the simulator logs to ~/Library/Logs/CoreSimulator/CoreSimulator.log

So I checked the logs in Console, and I found this:

And there is the actual reason. A Siri Intent extension without actual intents is preventing the app from installing in the simulator.

Standard
CodingAdventures, iOS, Objective-C, OOD, Swift

Protocols as boundaries between the known and the unknown

In the previous post, we discussed how protocols 1 are the foundation of polymorphism, and how using protocols we can define a contract, an expectation, that can be implemented in many different ways.

Today we are also to explore how we can use protocols as a way to use code that does not exist yet, as a boundary between what we know (our code) and what we don’t know (other people’s code).

In an ideal world (maybe not ideal for everyone, but that would be a different discussion) we don’t develop our software in isolation. We have team mates, or we use modules or frameworks developed by other teams within the same company.

Some time ago, I was with a time developing a set of Video On Demand applications. We had to implement a new feature: add support for recommendations based on user’s content consumption habits. The recommendations engine was not developed yet, in fact there was no team assigned to build it at that time.

We knew were our side of the solution started and ended. We knew we were going to need to tell the recommendations engine that a user had watched a particular item, and we were going to need to get a list of recommended items from the engine.

We started by defining our own interface for that recommendations engine. We looked at the problem from ur side of it, and wrote the interface we wished the recommendations engine had.

Did we know how the actual interface of the actual recommendations engine would look? Not at all. Did we care? We did not.

But we could start working on our side of the solution using fake data.

Having a clear boundary, clear separation between our side and their side, allowed us to build our side completely decoupled from the recommendations engine.

Having a clear boundary also gave us the confidence that we would be able to adapt to whatever the actual interface of the recommendations engine would look. And why I mean by adapt is literally write an adapter between our interface and the actually interface of the engine, if necessary (see the Adapter Pattern)

Also, having a clear boundary allowed us to unit test our solution from day one, giving us the confidence we needed to move forward fast.

It’s not rocket science. But it is worth remembering that protocols are not just those things that you use for table views data sources and delegates, but that they are probably the most powerful tool in our reach.

  1. I have never been a fan of how the Cocoa frameworks use the word protocol instead of interface. ↩︎
Standard
CodingAdventures, iOS

The reason why I try to avoid storyboards

Sometimes you know that you like or dislike something, but you are not sure exactly why. Sometimes you find yourself in a unpleasant situation, but it is hard for you to pinpoint why you find it unpleasant.

Well, I just had an epiphany, and I think I finally understand why I don’t feel comfortable working with storyboards, for anything bigger than a two screens app.

Storyboards do not let me slice the problem.

Consciously, or most likely unconsciously, I tend to slice problems, and rearrange those slices in a way that suits me, or suits the context I am working on.

Each of those slices can then be sliced down even further, so those new slices can be rearranged again.

That helps me, first, make the problem solvable. Which, immediately, increases my productivity: when I am facing a problem that happens to be too big, or just seems to be too big, I tend to procrastinate a lot.

But by slicing problems as much as possible, trying to comply with the single responsibility principle, abstractions start popping up, screaming at me.

Because even though I would love to say that I can design a solution to a problem upfront, truth is I have embraced the fact, long time ago, that I am better at noticing when the problem I am trying to solve is suggesting me a solution, than at trying to make the problem fit my pre-conceived solution to it.

Also, I find easier to make small slices work faster. It might be the time spent doing TDD, it might be that it’s just the way my brain works, but the shorter the feedback cycles, the faster I can move forward. It is like I physically feel impediments removing themselves, getting out of my way. Taking a storyboard of a certain complexity to a stage where I can make it work takes so long!

So I guess we are back to a recurrent theme of this blog: the single responsibility principle.

A storyboard can be a time saver, a great solution to build a kick prototype or a product with a well defined, clean and simple navigation flow.

But, in my opinion, more often than not, it is just a big chunk of muddy of responsibilities than I’m better off breaking down.

Standard