All posts by Admin

Merging Three Git Repositories Into One Repository Without Losing File History

Let’s assume that we have three separate git repos named uremont-client, uremont-service, uremont-sdk. We want to create a new repo, named uremont-ios, that contains all those repos in separate folders to have one single repo.

Why do we want to do this? In my case I had two apps and one sdk for them, and it was inconvenient for me to push changes to three separate repos while I was working with these projects and sdk at the same time.

Let’s start.

Terminal setup to allow git to move all folders except one. We will need this later.

Create a new folder uremont-ios and initialize git repo:

Add remote of first old project uremont-client that we want to merge to the new git repo and fetch it:

Merge first old project uremont-client to the new repo:

Move all folders and files of that old project to the separate folder inside of our new project:

Commit changes:

Similarly merge second old project uremont-service to the new repo:

And third:

Finally, add a new remote to our new repo and push it:

Chaining example on RxSwift

This is one of the reasons I love RxSwift. It allows to chain requests beautifully.

Here I authorize user by getting auth token, then I request userInfo, then I request profile.

Что нового в iOS 12

ARKit 2
Multiuser and Persistent AR. – сохранение данных из AR сессии в приложении, многопользовательский режим AR.
Object Detection. – распознавание объектов реального мира и добавление их в AR приложения.

Siri Shortcuts
Siri предсказывает быстрый доступ (shortcuts) для действий в приложении.

Health Records
Доступ к информации о здоровье в приложениях.

Показ стикеров и сообщений в iMessage в виде эффектов.

Interactive Controls in Notifications
Полная кастомизация уведомлений.

Authentication Services
Позволяет шарить логин-сессию между Safari и приложением, чтобы логинить пользователя проще.

CarPlay for Navigation Apps

Network Framework
Доступ к протоколам TLS, TCP, UDP.
URLSession, работающий с HTTP, построен поверх этого фреймворка.

Natural Language
Получение метаданных из текста.

Deprecation of OpenGL ES
OpenGL ES deprecated, необходимо использовать только Metal.

Получение строки, содержащей склонения дней дня день

Достаточно часто используемая штука, поэтому решил сохранить сниппет:


Результат: 11 дней

Swift build failed. No errors.

This happened to me while I was writing in Swift 4.1 in XCode 9.3. I use RxSwift also. It never happened while I was writing in Objective C. There were no any logs in Report Navigator too. Project just compiled without errors, then failed. Couldn’t figure out why.

In my case what I did and it helped:

1. Commit changes in Git and then discard changes in XCode if it shows “M” near files
2. Clear derived data: Xcode -> Preferences -> location
3. Clean build folder: Shift + Cmd + Alt + K
4. Restart XCode

After this project tried to compile and showed errors. The error was here:

I passed wrong variable name in observer.onNext(timing). It should have been pTiming.

Using RACCommand and creating custom RACSignals in Objective C

To bind some action to the button click one can use just a custom RACSignal. But then you have to add three more things in every case:
1. Disable button, while action is performing;
2. Show, that action is in progress;
3. Disable button, if input is incorrect and button should not be able to be tapped.

Instead, if you use RACCommand, you get all these things in a box.

Let’s say, we want to bind RACCommand verifyPhoneCommand to a button. We can create a command in a lazy property in a ViewModel:

Here phoneValidSignal is this signal, that is formed by observing a phone variable:

We pass a RACSignal verifyPhone to the RACCommand to do a job:

This is how we bind a RACCommand to a button:

To track execution of a RACCommand and show an activity indicator we can use executing property:

If errors happen during RACCommand execution we can process those errors:

Asynchronous requests chaining using FlatMap operator in RxSwift

One of the main features of using RxSwift and RxCocoa or FRP is the possibility to chain several asynchronous requests and avoid callback hell. It can be achieved by using FlatMap operator and creating your own Observables from your asynchronous jobs like network requests or heavy calculations. But sometimes it is not simple to understand, how to do it. In this post I would like to show an example from one of my projects. The same can be applied to Objective C + ReactiveCocoa, the idea is the same.

First of all we should create Observables from different asynchronous requests. Then we can chain them using FlatMap operator. My example concerns a classic case – login and profile fetching. In many apps after logging in a user you have to request his profile in a separate request.

Usually you use MVVM with RxSwift. In a ViewModel you can create observables. In my case login() method creates an Observable from Alamofire request. In loadProfile() method Observable is created from ProfileService.

This is how you chain login and loadProfile requests. When they finish, you can do some job with a result profile. In this case I check a trial period and navigate to one of the views depending on a result.

Note that error for both requests is handled in one place using SCLAlertView. FlatMap operator maps a result of a first request to a second request and also flattens Observables. If you use just Map instead of FlatMap, the result of chaining will be an Observable of Observables.

Loading a TableFooterView that uses Autolayout from XIB

You can use Autolayout and Xibs to create a footer view. But you have to put your custom view to the container view, that you assign to tableFooterView. If you use Autolayout and load Header or Footer View from xib, you should add constraints.

Как стать хорошим разработчиком

Полностью согласен с тем, что написано в этой статье.

Чтобы быть хорошим разработчиком нужно:

1. Писать код качественно и быстро. Именно в этом порядке приоритетов. Не работающий, но быстро написанный код не принесет компании хороших результатов. Если не хватает времени – это проблема планирования и менеджмента, а не проблема разработчика.

2. Код должен быть читаемым и простым. Другие разработчики должны в нем легко разбираться. Отсюда следует, что код нужно хорошо комментировать, давать правильные названия сущностям (классам, объектам, методам).

3. Тщательно тестировать свою работу до того, как отдавать ее на тестирование. Лучше самому найти 90% багов и сдать качественный продукт, чем потом вычищать сотни багов, найденные другими людьми в течение нескольких итераций. Нужно избегать переделок.

4. Не жаловаться на проблемы, а решать их. Не измерять свою производительность количеством строк кода, а измерять количеством решенных проблем.

5. Сначала решать проблему, а затем уже начинать писать код.