Forem: Eleazar Estrella

Map, Filter and Reduce in Swift

Eleazar Estrella — Tue, 06 Nov 2018 16:48:02 +0000

Swift, like many modern languages, has implemented some beautiful, functional capabilities to its core. If you are not experienced with the functional paradigm, it's common to implement the classic for-loop for resolving the frequently seen problems around collection types, but that's not the Swiftiest way. So today, I'm going to introduce High Order Functions, which will let you simplify your code when a collection type joins in.

A Higher-Order Function is a function that receives other functions as arguments or a function that returns another function as its result. We'll be using Map, Reduce, and Filter in this post. Let's get started!

Map

In many programming languages, map is the name of a higher-order function that applies a given function to each element of a functor, e.g. a list, returning a list of results in the same order.
Source: Wikipedia

Instead of writing a for loop and applying your business logic to each element, the map function takes care of that for you. It's only necessary to code the function that will be used to each element, saving us time and lines.

For example:

Also you are able to transform your collection to another collection with a different type.

Filter

In functional programming, filter is a higher-order function that processes a data structure (usually a list) in some order to produce a new data structure containing exactly those elements of the original data structure for which a given predicate returns the boolean value true.
Source: Wikipedia

The filter function iterates over a collection and then returns a new array containing those elements that have matched our predicate condition.

Reduce

In functional programming, fold (also termed reduce, accumulate, aggregate, compress, or inject) refers to a family of higher-order functions that analyze a recursive data structure and through use of a given combining operation, recombine the results of recursively processing its constituent parts, building up a return value.
Source: Wikipedia

Okay, that sounds too technical. Let me explain it in other words. What reduce function does is to combine every item of a collection in a unique value.

Let's see all of these together in action. Do you remember my previous post where I was introducing a new way to solve a common problem? Now let's do that again but using what we just learned.

So, now instead of using the classic for-loop like this:

We could just reduce this to a one single line:

It's now more elegant than before.

Swift pro tip of the day: Extension with generic where clause

Eleazar Estrella — Fri, 07 Sep 2018 20:33:35 +0000

Inspired by how successful was my previous post a few days ago, I'm writing a continuation with a better approach and in which I can introduce Swift features that are just as interesting as computed properties: extensions and generics, and besides you'll notice how these two converge in a majestic combination. First of all let's quickly define what these two features are:

Extensions:

Extensions add new functionality to an existing class, structure, enumeration, or protocol type. This includes the ability to extend types for which you do not have access to the source code (known as retroactive modeling).

Extensions in Swift can:

Add computed instance properties and computed type properties
Define instance methods and type methods
Provide new initializers
Define subscripts
Define and use new nested types
Make an existing type conform to a protocol

Source: The Swift Programming Language

The most common sample could be to make a ViewController comfort a protocol using extensions:

Generic type:

Generic code enables you to write flexible, reusable functions, and types that can work with any type, subject to requirements that you define. You can write code that avoids duplication and expresses its intent in a clear, abstracted manner.

In addition to generic functions, Swift enables you to define your own generic types. These are custom classes, structures, and enumerations that can work with any type, in a similar way to Array and Dictionary.

Source: The Swift Programming Language

Keep in mind that Arrays and Dictionaries are using Generic Types because that's going to be useful later. Do you remember the problem I was facing in my previous post? Let's recapitulate: I need the sum of selected pieces prices within a group of data. The approach I implemented with computed properties was like this:

There is another way to solve this problem using extensions and the generic where clause. You can make an Array extension that requires the element to be a specific type or to conform to a protocol. So the above problem -using this combination- can be solved in the following way:

With the Where Clause, we're specifying that we want the Array Element to be type of Piece and then we are able to add a new property with the necessary logic. Same problem, solved from two different approaches taking advantage of Swift. I hope you enjoyed the post and if so, please follow me because more content will come soon. Goodbye!

Swift computed properties in a nutshell

Eleazar Estrella — Tue, 04 Sep 2018 22:48:56 +0000

Hello everyone. Today I have a free hour, so I've decided to write a little post about some essential and exciting Swift features. And since today, I needed to use computed properties in my job; I want to share that knowledge with whoever is starting in the world of programming as well as in iOS and Swift. With nothing more to add, let's begin.

What are computed properties?

Sometimes in our classes, some properties are not so simple as to be only quantities or values represented in a variable (such as the value of a string, integer, etc.). Some times in execution time, we need some business logic behind some properties for its correct operation. Instead of encapsulating that logic in functions, we can also do it in the so-called computed properties. Every time we access this kind of property, its value is recalculated, this brings many advantages, and it's also straightforward to use in Swift! Let's see an example:

The use case that I was facing today was a computed property representing the total value of the selected pieces within a group of data. As the selected pieces can change on the fly, it's necessary to do the calculation again by iterating and adding the price of the chosen pieces to the total every single time the property is accessed. The way to do this in Swift is to open brackets right after declaring the property, and inside the getter, we should write the logic necessary for it to work:

Each time the "total" property is accessed, it iterates recalculating the value based on the selected pieces. As you can see, the advantages are several, starting with having a more concise code and always having the property value updated. You can also create "writable" computed properties using the keyword "set," do you want to try it out?

This has been my mini post for today, and I hope you enjoyed it. If you have any questions, please leave a comment below. Goodbye!

4 things I've learned after 10 months as an iOS developer

Eleazar Estrella — Mon, 23 Jul 2018 14:13:20 +0000

A few years ago I started my journey in the world of native mobile development using the android environment and java. Then, due to requirements at the company I was working with, I saw myself in the opportunity to start as an iOS developer and since then 10 months have passed. It’s been a long journey that never ends and today I’ll tell you 4 things that this beautiful experience has taught me. What I’m going to present below are just some tips that I've been learning on the fly and that I implement in my day to day. I hope you find it useful, let's get started!

1- MVC also known as Massive View Controller

Apple's MVC in the long-run does not work. Your viewcontroller sooner or later ends up doing a lot more than it should and that will end up in a class with 600 lines of code that is very hard to follow. It's better to use some design patterns on top of the traditional MVC Apple provides. There are many options out there: VIPER, MVVM, MVP, etc. It will depend on you and the specific needs of your project. Some time ago I wrote an introduction to MVVM using swift, please take a look:

MVVM pattern sample in swift/ios

2- Avoid non-optional optionals!

The optionals are one of the most powerful Swift features without any doubt however the developer doesn't always use it in a suitable way to the use cases. I've noticed that it's very common to use optionals that really are not optionals. I mean, when a property is 100% required for our program to work, is it really an "optional" at the end of the day? Let's see this in an example. Suppose you have a basic UIViewController, which consumes a service that populates a tableview. For this viewcontroller to work correctly, you must have assigned the 'service' property and the 'tableView' property as well.

It's tempting to put these attributes as optionals and pass them from outside. However, what happens if these properties are not assigned? The user will visualize an undefined state in the ui. Here's a subject that is very debatable but in my opinion it's better to get a runtime/compilation-time error than showing an undefined state to the user, because at least the developer is able to handle the exception. And you can achieve this by using implicitly unwrapped optionals.

Keep moving foward: Handling non-optional optionals in Swift

3- Stop using segues!

When you have to pass data between viewcontrollers and your application is having a slightly more complex flow, it can all become very tedious. One way to handle the routing is to use segues in the interface builder, but I've realized that it's not always the best way to handle it and I'll explain why. Let's take a look at this piece of code:

This code is difficult to read, difficult to maintain and is also very sensitive to changes because if someone modify an identifier or the viewController type the whole project could become a disaster. Some developers prefer to create the viewcontroller from scratch using swift and xib files but the approach that I like the most is to use a middle point between both forms and use another class that allows us to manage the routing in an efficient way.

By using wireframes you can achieve a better maintainable and testable code, have all the logic of routing in one place (single responsibility principle) and also prevent your application from collapsing if someone changes the segue identifier.

Cleaner, simpler and a better way to handle errors. It also helps you avoid the massive view controller that I mentioned in point number one. I will write more about this in the future so please stay tuned.

4- Swift is sexy, take advantage of it!

Coming from a strong background in java, many of you will be able to understand why swift could seem to me as such an attractive language. Swift implements some powerful features and some functional paradigm features that are really useful. One of the things that I've learned is how powerful Swift is and the more you take advantage of it the more powerful it becomes.So I'm going to finish with several links to learn (and keep learning) Swift and iOS. And remember, we never stop! Every day we can learn something new that leads us to be better professionals.

The Swift Programming Language 4.0

Developing iOS apps with Swift

MVVM Pattern Sample in Swift/iOS

Eleazar Estrella — Mon, 26 Feb 2018 19:50:17 +0000

MVVM is a pattern that has been gaining more popularity, while more event-oriented applications have been becoming. There are many advantages to using MVVM vs. the classic MVC in iOS development, starting with completely dividing the business logic with the presentation layer. Instead of having a "massive ViewController" that is responsible for doing too many things, we can delegate things like requesting data from the network or a local database to another entity.

All this application logic is within the ViewModel, which never knows what the view is or what the view does. What makes this architecture quite testable and takes complexity away from the view leaving it as dumb as possible.

The view owns the ViewModel and is always "listening" for changes for updating the UI. Here comes the famous "two-way data binding," if there is a change in the view, the model is updated, and if there is a change in the model, the view is updated, always having as an intermediary the ViewModel.

Well, what if we see this in practice? Imagine the following scenario: I want to develop an app that connects with the API rest of Github and allows me to search among the repositories, select one of them, and see its most recent commits. Let's get started!

I'm going to start with the search functionality, I will ignore many things for brevity, but you can see all the source code at the end.

Let's code the protocol that satisfies our ViewModel:

protocol SearchRepositoriesDelegate {
    func searchResultsDidChanged()
}

protocol SearchViewModelType {
    var results: [SearchResult] {get}

    var query: String {get set}

    var delegate: SearchRepositoriesDelegate? {get set }
}

A property for results, a property for the query that retrieves those results, and a delegate to notify the view that there have been changes. Simple, right?

Please note that 'SearchRepositoriesDelegate' in another scenario should be replaced by some data binding mechanism or implement observables, but this will be for another post.

Then our ViewModel will work in the following way:

1- The view will have a reference to the ViewModel.
2- While the user is typing in the search bar, the view will update the 'query' property of the ViewModel based on the query.
3- Each time the 'query' property is updated, the ViewModel makes a request to the Github API rest and updates the results.
4- Once there is a server response, the ViewModel notifies the view (through the delegate) that there were changes in the results.
5- Every time the function 'searchResultsDidChanged' is called, the view updates the UI.

Let's see how the implementation is:

ViewModel:

    class SearchViewModel : SearchViewModelType {
    var delegate: SearchRepositoriesDelegate?

    var results : [SearchResult] = [] {//0 results by default
        didSet{
            delegate?.searchResultsDidChanged() //notify
        }
    }

    var searchService: SearchService

    var query: String = "" {
        didSet {
            if query == "" {
                results = []
            }else {
                performSearch()
            }
        }
    }

    init(service: SearchService) {
        self.searchService = service
    }

    private func performSearch() {
        searchService.search(query: self.query)
            .onSuccess { results in
                self.results = results
            }.onFailure { error in
                //do nothing
        }
    }
}

View:

class SearchViewController: UIViewController {

    ...

    var searchViewModel: SearchViewModelType!

    override func viewDidLoad() {
        super.viewDidLoad()

        searchViewModel.delegate = self

        ...
    }
}

extension SearchViewController: UISearchBarDelegate {
    func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) {
        searchViewModel.query = searchText
    }
}

extension SearchViewController: SearchRepositoriesDelegate {
    func searchResultsDidChanged() {
        self.tableView.reloadData()
    }
}

...

While the user is typing in the search bar, the property 'query' is updated, and the ViewModel requests the server-side. Once a request completes, it notifies the view, and it calls the UITableView 'reloadData ()' function to reflect the changes in the UI. As you may have seen, the class SearchViewModel is very easy to test since we only need to create a mock 'SearchService' object to check if it works correctly. ViewModel has no reference to the view, and the view is exempt from all business logic.

That's all! Don't be afraid to see all the source code in this link and comment on any questions.