Improving code readability

Everyone knows about the nightmarish closures in Swift. Because of the nature of mobile development, asynchronous processes must be called in time. This used to be done with closures. Some of you may still use closures to do this, and that’s fine.

But one day you will run into nested closures. And the nightmare will begin. Reading and editing nested closures is a pain. Everyone understands that.

So how does reactive programming in Swift help reduce this pain?

You can chain observables using functions: map, flatMap and flatMapLatest. This way you can process queries simultaneously without bothering to read nested closures.

So it’s very useful to spend time making your code clearer and more readable.

This does not mean that you should stop using closures altogether. However, by using closures along with the reactive library of your choice, you can make your code more readable.

Help with event handling

In a general iOS development scenario, you need to react to events from different parts of the app. For example, someone changed their name in one controller, and you need to update it in another.

There are several scripts for such cases: delegates, notifications, and key-value pairs. Each of them works pretty well. But the reactive approach has a lot to offer.

First, reactive programming can simplify working with these scripts. All you need to do is create an observer or subject and subscribe to it. Then, every time the observer spawns an object, all the subscribers will know about it.

You can subscribe to the subject from the first controller anywhere in the program. And then use myObject for your own purposes. For example, you can skip the first two objects. You can use skip function to do that. And as I said before, you can combine the two objects using the merge and zip functions.

Make the code more modular

One of my any reactive programming features is to pass observable as variables. For example, you can pass a network request to another object and execute it when needed. This makes the code more readable and modular.

Let’s say you have controllers that need a specific type. You can use any network request with them whose observers spawn objects of the right type.

I always use this when I need overused controllers to display data to the user. Let’s take an application similar to Instagram, where you have a post object and a screen where those posts are displayed. You need to display posts from one user or the other on the same screen. Since this is most likely done with network requests, you can create the request as observable and pass it to the controller. The controller will do the rest.

Thus, the advantage here is modularity and versatility. This one controller can be reused any time you need to display a list of messages. And all you have to do is pass it to the controller. The controller will do the rest.

The post Why do I need reactive programming in Swift? appeared first on MBPower Tools.

Performance

Apple’s IDE is getting slower. On the 2014 Macbook Air, Xcode (2017 version) sometimes slowed down in large projects. The 2018 version was already slowing down significantly on the 2017 Macbook Pro.

For example, Playground, which is positioned as a sandbox for quick experiments with code, took several minutes to load. For which you can find a web compiler for Swift on the Internet and do whatever you need on a machine with any operating system.

Limitations

• Xcode only works on Mac OS, and updates to the IDE is strictly tied to versions of the operating system.
• Xcode must be updated to support new devices.
• The ability to use plugins has been disabled.
• You cannot just put a new version of an application into the Appstore from another computer (the owner of the computer from which the application was originally installed must provide you with a certificate file for this purpose).
• Xcode takes up a lot of space, which is especially noticeable on laptops. Xcode 12 requires at least 49 gigabytes of free space to install. To upgrade to a major version of the program, the same amount of space will be required.

Bugs

Here are the most annoying bugs, most of which appeared in Xcode 10 and have not yet been fixed:

• Debugging over WiFi is extremely unstable.
• Debugging over the wire works better, but there is often a situation where Xcode suddenly stops seeing the device.
• Storyboard crashes. No matter how busy your Storyboard is, it can stop rendering. And then you only have to look for the element that broke everything.
• Tying interface elements to code doesn’t work the first time 100% of the time.
• The larger the project, the more likely it is that autocomplete code will start to fail.
• The file tree lives its own life. After each program restart, the file tree often unfolds completely. There are no buttons to control it.
• As of version 11, the file tree may not react spontaneously to file moves. That is, visually changes will occur, but nothing will change in the project folder.
• Sometimes you just can not create a folder.

The post What’s wrong with Xcode: bugs and performance issues appeared first on MBPower Tools.