Today’s topic is not connected with RxSwift at all. Recently, I’ve started using an awesome library so I decided to write an article about it, because it’s worth to mention. Don’t worry, I will come back with reactive stuff soon 😉
I hope you know how important unit tests are in writing software applications. In case you don’t know I recommend you my article series and Jon’s Raid website about unit tests in the iOS world.
However, it is difficult (or even impossible) to cover all the code you have with tests. Writing unit tests for classes inherited from UIView was a hard task for me, because the outcome was not worth the time spent on it. As a result, I stopped writing unit tests for any of views.
In my last project, a colleague of mine introduced me FBSnapshotTestCase library developed by Facebook.
It has been a long time since my last post. I wanted to prepare an article which will cover the theory which stands behind Observable and show the usage on real, not dummy example. It has turned out it was not trivial task as I thought 😉
The article is split into 2 parts. At the beginning, I try to explain what is the Observable and how should you treat them.
The second part is a tutorial how to implement a search of Spotify tracks using RxSwift. A theory is a theory, but an example is a thing which makes a subject easier to understand.
My journey with FRP has started with ReactiveCocoa v2.4 which was the most popular library implementing concepts of Functional Reactive Programming in Objective-C. At the beginning, I had a shallow understanding of ReactiveCocoa so I limited the usage only for listening for UI events (like button taps) or handling REST API calls. It was a fantastic approach because later it was much easier for me to understand the idea which stands behind RxSwift.
This is it what I want to show you. Without diving into details of RxSwift and what a stream, sequence or Observable is I would like to demonstrate you the best use cases how FRP can simplify your ordinary problems. It’s a stretch before a long rx-run 😉
Sometimes I have a feeling that not everybody cares about where to put a piece of code which we’re writing. Sometimes, the “does it work?” question is sufficient requirement to mark a task as done. Especially, when it comes to adding new code into existing project.
Recently, we had a task to write a module which allows a user to update his data in his profile. We end up with UIViewController, which is responsible for the UI and gathering data from text fields, UserUpdater which creates a request based on ViewController data and the HTTPClient which knows how to send the request to the API.
For nearly last 6 months I’ve been writing code only in Swift. I can say it was a “love at first use”. Now I cannot imagine that I can start a new project with Objective-C. During these 6 months, I’ve read a lot of stuff about good practices in Swift. I found few nice ideas and I also have my own thoughts.
Get rid of storyboards
The title is not a mistake. Swift doesn’t like to work with storyboards in spite of they are recommended by Apple. Why? Using of storyboards forces you to use init?(coder aDecoder: NSCoder) inside UIViewController classes. That leads us to a question: How would you like to initiate the ViewController dependencies? The only answer is “You have to make them optional”. Generally speaking, when you mark something as an optional it has to have a reason in a business logic. Continue Reading
hat I love in my job is a community of people with common interests. Our society really likes to share with knowledge which we have learned. That is awesome! Thanks to it we can constantly increase a quality of our code and don’t repeat unnecessary mistakes. That brings us to what we have now.
We have thousands of open source library which we use everyday. However, sometimes you need to choose which tool you want to use. The same is with unit tests in iOS. There are two kinds of iOS developers who practice TDD: