Not so long ago I’ve published an article called “Forget datasource & delegate: a new approach to UITableView“; the title may appear as a bit pretentious but, believe me when I say I’m tired to fill-up datasource and delegates methods placeholders just to make a simple (or complex) table/collection.

I do not want to bore you with yet another article about massive view controllers but the whole thing is easy to become a big jumble when you want to implement some business logic and flexible rendering to represented data.

My first attempt to approach this problem ended in Flow, a little but useful utility which allows you to create and manage the content of a table in a declarative way. I liked it so much and I’m still using it in different production projects with success; however, as often happens in this work, time, attempts, failures and, in a single word, experiences helped me to better understand the problem, the implications of my solution by giving to you the opportunity to improve my original work.

The following article recounts the story behind the original idea and propose a new improved approach you can use both for UITableView and UICollectionView.

View the article

In this article we’ll take a depth look at Timers and how it works; timer allows us to execute some piece of code after a timer interval one or more times. There are multiple types of clocks used to create timers and, even if apparently all ofthem run at the same rate, they still have different behaviours.

In the second part of this article I’ll present an NSTimer alternative made using GCD library which allows us to simplify our work with timer by removing memory management and thread constraints, also making our timer reusable and configurable.

View the article

As programmers we constantly use frameworks and libraries while developing new applications. Most of you will probably never deal with frameworks or library design nevertheless a certain amount of knowledge of the topic is useful even working on standalone applications.

The following article is an introduction to the differences between these entities and how they interact to produce a consistent and maintainable product.

We will look at their different roles and scopes, when we need one or the other and the best practices for our development cycle.

The last part contains several tips to write a good library I’ve collected in these past years.

View the article

This is my first contribution to the Swift Server Side community; during these months I’m evaluating Swift as backend language for server side programming. In fact it was not my first attempt, but during this year I’ve seen many improvements in all main server projects like Kitura and Vapor.
Moving away from NodeJS is a tricky decision but the advantages of moving to a modern language like Swift are tempting me since the first release.
So while it’s still a long path to the goal I’m slowly moving to see how I can make this a valuable solution.

With this goal in mind I’ve tried to port a first small contribution to the community by porting of the most famous library used in NodeJS in Swift; UAParserSwift is a port of ua-parser-js made for Swift server side. This library aims to identify detailed type of web browser, layout engine, operating system, cpu architecture, and device type/model, entirely from user-agent string with a relatively small footprint.

View the article
@