Расширяемые ячейки

UITableView часто применяется для вёрстки списков. Однако не все знают, что этот элемент не поддерживает автоматическое изменение размера ячейки.

Представим, что нам дали задание добавить в список на UITableView ячейку, высота которой будет:
🔹увеличиваться на 50 пунктов по нажатию,
🔹уменьшаться до исходного значения при повторном нажатии.

Добавим кнопку, привяжем её края к краям ячейки и вынесем constraint высоты для обработки изменений.

Менять высоту будем тривиальным кодом buttonHeightConstraint.constant += isSmall ? 50 : -50. Полный код ячейки — на картинке ExpandableTableCell-1.

Запускаем приложение: что получится, видно на первой картинке. Изменения к высоте заметны только после прокрутки списка, то есть при переиспользовании ячейки.

Как заставить UITableView реагировать на изменения constraint-высоты сразу же?

Нужно вызвать функцию UITableView.performBatchUpdates(nil) после изменения constraint. Это заставит UITableView пересчитать высоту ячеек и отобразить изменения анимировано.

Какой результат получим, видно на второй картинке. Высота будет меняться сразу же после нажатия.

Однако использование этого метода изнутри ячейки требует поиск инстанса UITableView, что возможно лишь через копирование или рекурсивный поиск. Пример рекурсивного поиска — на картинке ExpandableTableCell-2.

Чтобы не копировать код поиска UITableView, мы создали протокол ExpandableItem и спрятали необходимый вызов за абстрактным ивентом.

Просто добавьте ячейке реализацию этого протокола и вызовите onHeightChanged.invoke(with: nil) в момент изменения высоты. Остальное RDDM сделает за вас. Пример использования ExpandableItem — на картинке ExpandableTableCell-3.

Подобные расширяемые ячейки могут быть полезны при отображении:
🔹 ошибок под полями ввода,
🔹 вложенных списков,
🔹 других изменяющихся элементов.

Чтобы узнать больше про возможности RDDM, переходите в репозиторий проекта: там есть ExampleApp с примерами использования библиотеки и её фич, таких как ExpandableItem.

Ищем стажёра в нашу команду 🏄‍♂️

Стажировка в Surf — крутая возможность проявить скиллы в разработке и поработать на иностранных проектах. Мы за развитие и карьерный рост — трудоустроим лучших и будем прокачивать их грейд.

Что делают в Surf для стажёров:

• Платят стипендию;
• Строят гибкий график;
• Подключают опытного наставника;
• Обеспечивают современным железом.

Смотри требования к будущим iOS-стажёрам на карточках. Если твои скиллы подходят, то отправляй заявку на стажировку — вышлем тестовое задание, которое нужно выполнить до 12.02 включительно.

Собрали материалы, которые помогут при подготовке к стажировке:

→ Список полезной инфы для iOS-разработчиков.
→ Советы новичкам в iOS-разработке.
→ Как проходят стажировки в Surf.

Не проводите код-ревью на голодный желудок!
Или немного о том, как устроен процесс код-ревью в Surf

Процесс код-ревью в Surf есть! А если без шуток, в разных командах он проходит немного по-разному и зависит от разных факторов. О них и поговорим.

1️⃣ Размер команды
В небольшой команде из двух-трёх человек каждый разработчик проводит ревью каждого пул-реквеста.

Это:
✅ повышает качество проекта,
✅ помогает прокачать технически менее опытных разработчиков,
✅ даёт возможность познакомить участников команды с кодом друг друга,
❌ приводит к затратам ресурсов: отнимает довольно много времени.

В команде от четырёх человек и больше такое не сработает: как раз из-за временных затрат. Поэтому количество участников ревью ограничено: их может выбрать лид или создатель пул-реквеста.

2️⃣ Жизненный этап проекта
Иногда в жизнь вмешиваются обстоятельства в виде жёстких дедлайнов. Иногда в жизнь вмешиваются обстоятельства в виде жёстких дедлайнов. В этой ситуации можно воспользоваться таким понятием, как «технический долг» 😉

Если фичу надо отдать срочно и возможности перенести дедлайн нет, нужно запомнить то, что сделано «плохо»: зафиксировать это в техническом долге, а после релиза вернуться и исправить.

3️⃣ На что обращаем внимание в процессе код-ревью
🔹 общепринятые проектные договоренности,
🔹 соблюдение архитектурных правил,
🔹 грамотное разделение ответственностей,
🔹 соблюдение принципов программирования,
🔹 соблюдение code-style.

Проверять ли код на «правильность выполнения»? Об этом много споров. Наши техлиды проверяют.

Да, это отнимает много времени, но позволяет отсечь большинство багов ещё до попадания сборки к QA: это экономит время и QA, и разработчиков. Ведь чем раньше исправлен баг, тем меньше «стоимость» его исправления.