Latest posts

Swift and Kotlin are two great languages for iOS and Android development respectively. They both have very modern features and syntax that can help enormously to build native apps. But, how do they both compare to each other? Are they similar? Can we reuse more code between platforms if we adopt them in our projects?

Those are the questions we will explore in this post together with some real app code examples implementing the same features in both languages.

Naming conventions are very important in software development for many reasons, but especially for readability. According to Wikipedia:

Reasons for using a naming convention (as opposed to allowing programmers to choose any character sequence) include the following:

to reduce the effort needed to read and understand source code

to enable code reviews to focus on more important issues than arguing over syntax and naming standards.

to enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences.

So, what is a good name? This issue is controversial because there are multiple dogmas and styles out there. In Swift, despite being a young language, naming conventions are quite established already (with Swift 3), and includes guidelines about casing, naming parameters, methods,... However, there is no “defacto” way to name your implementation classes when you use protocols as a public abstract API and how to group code inside namespaces/modules.

With iOS9, Apple introduced a new container view called UIStackView. Stack views can be seen as the iOS equivalent for the LinearLayout in Android. Likewise, the usage is pretty straightforward, especially if you from Interface Builder, and when used properly can save the developers lots of time.

However, this special view comes with its own set of gotchas that are hard to find at first, and that can complicate your life hugely. With this post I want to cover the main issues and tricks that I have found while using stack views for a few months. Note that I am not going to cover the basic usage of UIStackView, there are plenty of references on Internet for that (check references below). Let’s get started!

Where is the drawing phase?

One of my first issues with Stack Views was setting up some basic properties like background color or borders. An interesting aspect of this views is that they do not have a normal render phase. Instead, they are container views, and any code you place in the drawRect method drawing into the current context will actually output nothing. This is what the documentation says:

DataBindings is a concept that has been there for quite some time with great success in other technologies. However, the Android stack lacked them (at least in an formal way) until June 2015, when Google introduced them in beta during the Google/IO (still in beta version at the moment of writing this post). But, how does DataBinding work? why is DataBinding so important? can it actually help and improve the way we develop Android apps? will this be the new standard when developing Android apps? I really believe so, so let’s get started! there is a lot to cover!

Disclaimer

It has been a long time since I started with the MVC post series. It is not that I didn’t want to write about it, but by the time I was supposed to start with this post Objc.io came with a very good issue on View Controllers, which made my post almost irrelevant as most of the ideas were already mentioned there. Anyway, after receiving quite a lot of messages asking for this post, I finally decided to spend some time and try to address some new points and explain those that are important. That being said, if you haven’t read objc.io issue do not hesitate because it is worth the time and an excellent complement for this post.

The controller role

In MVC, the Controller is the part of your software that communicates your Model layer with your View layer, and it is by far the most abused role in iOS project. But lets first define how a good controller should look like:

A good controller should know how to request data to the model but not its internal details or how to fetch it; it should know what view to use but not how to draw it; it should be the one receiving events from one layer and passing messages to the other layer but not the one creating the events. In brief, a Controller should be the glue needed to connect the Model and the View, but ideally it should not do anything else than that.

However, in iOS projects we often find controllers that make lot more duties that the ones they should. This is not a coincidence: delegation patterns used in most of Apple’s components can be easily implemented on controllers, and the UIViewController API exposes methods like viewWillLayoutSubviews that should concern the View role only. Even the UIViewController name denotes this lack of real distinction between views and controllers!

Nevertheless, writing good controllers make your code lot more reusable (not only the controllers but the other layers also), easier to test, more maintainable and more flexible. So, lets review some important guidelines: