Последнее время стало модно использовать всеми горячо любимый фреймворк Swinject для внедрения зависимостей , о чем не стесняются писать в резюме. Для чего? Если коротко, то ваш код не должен быть сильно связным, все зависимости каждого компонента должны зависеть лишь от абстракций, а не от конкретной реализации. По крайней мере этого просит буква D из принципов SOLID. А внедрять эти зависимости можно из так называемого контейнера для внедрения зависимостей, напоминающий фабрику. Этот контейнер возвращает определенный инстанс определенного класса, отвечающему заданному протоколу, в том числе и с другими вложенными зависимостями. Получается, что пользователь не знает, каким образом и какой конкретный объект ему был возвращен контейнером, т.к. работает с объектом строго через заданный протокол. Таким образом можно еще и удобно протестировать работу отдельного компонента, сделав контейнер с заданной конфигурацией, в которой будут отдаваться классы-заглушки с законсервированными данными для зависимостей тестируемого компонента. Еще прикольно, что Swinject умеет задавать стратегию создания объекта, например, либо каждый раз новый объект, либо один раз в виде синглтона (+ это еще не все)
Наверняка у каждого iOS-разработчика про запас лежит свой кастомный контрол, который умеет получать и отображать картинку из интернетика по URL. Некоторые любители зависимостей cocoapods также используют сторонний SDWebImage. Впрочем, я решил поиспражняться поупражняться и сделать свой велосипед. Ведь всяко может обновиться iOS SDK, пацаны могут выкатить новый Swift, и тут выяснится, что все пропало, а контрибьютер стороннего компонента уже срубил кучу бабла и где-нибудь чиллит на Мальдивах с безлимитным куба-либре в руке, а релиз у вас уже завтра, и что делать - хз.
Кстати, сама идея использовать URL для UIImageView породила вот этот доклад, в котором ребята из ВКонтакте в сам урл запихивают допустим GPS-координаты - а в ответ получают картинку с местоположением в Google Maps, либо накладывать локально фильтры на изображение из галереи, очень гибко переопределив работу URLProtocol
Мой велосипед умеет:
- Async load of images from the given url
- Save already loaded images in NSCache
- Persist already loaded images in app caches directory and restore it back after app relaunch
- Ability to set placeholder while image is loading
- Create only one network request when trying to load 1000 images with the same URL at the same time. Other copies are waiting the network request result
А пользоваться еще проще.
Листинг кода можно посмотреть на гитхабе, особенно может быть интересным, как сделано ожидание загрузки у остальных картинок с одинаковым урлом, пока первая не скачается, а остальным нотифицирует, что пора бы обновить картинку локально
Существует довольно-таки распространенная необходимость сигнализировать о каких-либо событиях от одного к нескольким объектам. В Swift это решается двумя способами из коробки:
KVO, которое тянет за собой обязательство наследоваться отNSObjectNotificationCenter, который до iOS 11 SDK хранил сильную ссылку на объект-наблюдатель, что приводило к утечке памяти, если вовремя не отписаться. Еще он неудобен тем, что необходимо отписываться явным образом от конкретной сигнатуры нотификации, чтобы случайно не отписать от других важных событий текущий объект, если использоватьremoveObserver(self)
Еще один годный вариант - сделать свой Observable, который будет:
- Работать на кложурах, без использования
NSObject-based классов или@objc-методов - Самостоятельно больше не трекать умерших наблюдателей и не слать нотификации мертвому объекту
Идея не нова, в С++ уже давно используется boost::signal, примерно похожее и удобное будем делать на Swift
Недавно затащил в проект SwiftLint, чтобы код как можно ближе соответствовал Swift Style Guide, ну чтобы в общем был по всем канонам. Куча ворнингов, и довольно часто встречается вот такой:
Line Length Violation: Line should be 120 characters or less: currently 139 characters (line_length)
Вылазит для куска кода, где в wireframe инстанциируется View-слой для VIPER-модуля. Аналогично и для получения ячейки по идентификатору из UICollectionView / UITableView
Казалось бы, куда уж короче, ведь строчку некуда сокращать. Нашлась достаточно удобная оптимизация, позволяющая сделать код более читаемым, а также избавиться от строковых констант, для которых автокомплит не сработает. Кроме повышения читаемости кода, исключаем риск опечататься в строковом идентификаторе, который задан в Storyboard
Ранее я уже писал, как собирать Qt 4.8 для OS X Sierra и Linux. Осталось уточнить некоторые моменты для Windows. Основное отличие от ранее описанных инструкций таится в том, что мы будем все собирать под Visual Studio 2010 в отличие от GCC. Стоит отметить, что 2010 студия - последняя, которая поддерживается со стороны Qt 4.8.
Простой скрипт, который может пригодиться для периодического дампа всех MySQL баз данных на вашем сервере + заархивировать по отдельности каждую папку с сайтом. Код под катом
В общем, задача такая, сделать почти как в андроиде, чтобы плейсхолдер в UITextField в момент фокуса улетал наверх, а также само поле ввода было подчеркнуто и линия становилась полупрозрачной при потере фокуса.
Реализовано, конечно, не совсем как в гайдлайне материал дизайна, но задача была сформулирована именно таким образом. В реализации используется CoreGraphics Affine Transform для плавной анимации UILabel для плейсхолдера. Также переопределено само свойство placeholder со своими сеттерами и геттерами для текста нового UILabel. Можно задавать текст прямо из storyboard и, внимание, менять цвет текста плейсхолдера, ведь раньше приходилось хачить в рантайме через attributedPlaceholder. Исходный код лежит на гитхабе.
Если вдруг в гите понадобилось безболезненно переменовать текущую ветку как локально так и удаленно, то помогают такие команды:
git branch -m new_branch
git push origin :old_branch
git push --set-upstream origin new_branch
Начиная с iOS 8 появилась удобная возможность использовать поповеры не только в iPad, но и в iPhone. Для этого сделал удобный extension:
Для начала нужно установить программку на свой телефон - Packet Capture. Программа является прокси-сервером, в котором для мониторинг SSL-траффика используется аттака "Man in the Middle". В программу добавляется подставной сертификат, который для клиента считается доверенным. А сам прокси-сервер устанавливает две независимсые SSL-сессии, анализируя дешифрованные данные. А рут не нужен потому, что приложуха использует VPNService, доступный с Android 4.0. С помощью такого прокси можно анализировать работу различных REST API, которые ходят по https протоколу. Например, мне понадобилось починить музыкальное API ВКонтакте для VkAudioSaver.
Пожалуй, самым трудоемким шагом во всей этой истории будет генерация подставного сертификата. Для этого используются утилита openssl.