Pull to refresh

Comments 25

Поздравляю с отличным результатам! Очень мотивирующая статья. В коде увидел несколько приятных мест: склонение слова (можно сделать через регулярку), прокидывание сервиса в UITableViewCell с поясняющим комментарием, и круглое изображение через UIGraphicsContext.
Поздравляю! Мне показалось, что на ios задание было посложнее, чем на android.
Спасибо! К своему стыду даже не знал, что задания различались :-)
Единственное знаю, что работ по iOS было сдано больше чем по Android.
Вот как в вк появляется новый дизайн и новые фичи)
круто! я по android участвовал, понравились задачи 1 и 2 этапа, но не понравился подход к фидбеку по сданным работам.
Hourly, кстати, прикольно выглядит, на Android не планируете выпустить?
Спасибо. В ближайших планах нет, но если есть желающие Android-разработчики – то можем обсудить :-)
Поздравляю вас!
Пару моментов хочу прояснить по реализации.
Имхо для плавной анимации раскрытия ячейки можно просто поменять соответствующий state в модели на «раскрыть» и вызвать метод tableView.reloadRowsAtIndexPathWithAnimation(название метода по памяти пишу). Вроде должно прокатить и намного меньше кода.
И если для таблицы важна скорость работы, то лучше значения модели в ячейку сетить в willDisplayCell, а не cellForRow.
Еще интересно было ли ограничение на использование сторонних библиотек?
А вы показ видео не реализовывали? Интересно как разномастные источники (ютуб, рутуб, вк) лучше всего обрабатывать.
Поздравляю вас!
Спасибо.
Имхо для плавной анимации раскрытия ячейки можно просто поменять соответствующий state в модели на «раскрыть» и вызвать метод tableView.reloadRowsAtIndexPathWithAnimation(название метода по памяти пишу). Вроде должно прокатить и намного меньше кода.
Не пользовался, но выглядит подходящим. Попробую, спасибо за совет.
И если для таблицы важна скорость работы, то лучше значения модели в ячейку сетить в willDisplayCell, а не cellForRow.
И да, и нет. Можете попробовать – в моём случае прироста производительности заметного не наступит. Я пытался сконцентрировать 20% усилий на решение 80% проблем производительности. Но вы верно заметили, что правильнее сеттить данные в willDisplayCell.
Еще интересно было ли ограничение на использование сторонних библиотек?
Нельзя было использовать сторонние библиотеки кроме VKSDK исключительно для авторизации.
А вы показ видео не реализовывали? Интересно как разномастные источники (ютуб, рутуб, вк) лучше всего обрабатывать.
Неа, по заданию нужно было только текст, раскрытие текста, изображение и карусельки изображений.
Почему для парсинга джейсонов не использовался Codable?
Исключительно без причины. Нервная атмосфера, на скорость – местами идёшь в лоб. И спасибо за замечание :-)
Спросил исключительно из-за того, что, с Codable, кажется, было бы как раз быстрее :)

И да, забыл поздравить с достижением цели и отличной статьёй!
А можно где-нибудь узнать обоснование фикса от лага подгрузки снизу?
После обновления таблицы через reloadData у неё устанавливается contentOffset.y c учётом estimatedRowHeight, а не реальной высоты ячеек из heightForRow. estimatedRowHeight по умолчанию имеет константное и не нулевое значение automaticDimension. А ячейки с динамическим контентом имеют разную высоты. Вот и получается прыжок.

При установке estimatedRowHeight в ноль вообще отключаются estimated height и всё считается через heightForRow.

Из документации
Set the value to 0 to disable estimated heights.
Очень круто, спасибо за пост!

По поводу UIRefreshControl. Пофиксить его некоторые баги нельзя, особенно если хочется юзать спокойно с любыми наследниками UIScrollView без особенных UIViewController. Я навидался кривого поведения с ним (даже эпловых аппов), немного посмотрел как он устроен внутри через hopper и выкинул его нафиг. Так что совет всегда юзать его не самый лучший. Я бы сказал так, если пофиг на баги и хочется быстро поддержать рефреш — юзать, если хочется хорошо, то не стоит)
Спасибо! А не видел где-нибудь хороших собственных реализаций посмотреть?
Я свой велосипед сделал. Руки никак не дойдут опубликовать)
Я буду ждать :-) Расскажи потом на CocoaHeads

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

Привет! Можешь чуть подробнее раскрыть мысль?
Это просто добавить свои типы ячеек для карусельки и одиночной картинки, либо какой-то «кеш» отдельный UIView / CALayer?

я вижу 3 варианта (если не юзать всякое сторонее)
1 — сделать для каждого типа свою ячейку (чисто текст, текст с картинкой, картинка), и сразу зарегистрировать их в таблице
2 — сделать базовую ячейку которая подстраивается под контент(в принцыпе так как в твоем коде но большее унифицировано, чтоб не запутатся в куче переменных), как вариант — каждый тип контента на своей вьюхе, которая добавляется на ячейку если такой тип контента есть в посте. из таблицы в cellForRowAtIndexPath получать пытаться получить ячеqку под тип контента dequeueReusableCellWithIdentifier, и если такой нет — создать такую.
как результат, действий с addSubview/removeFromsuperview будет минимум, только при новом создании ячейки
ну и еще пул uiimageview для карусели картинок можно
3 — для самых изощренных — рендерить пост как картинку, и отображать чисто картинку) с каруселями нужно будет включать смекалку

Тут главное не упороться и не пойти в over-инжиниринг :-)
Насколько я знаю, CALayer умеют кешироваться. Т.е. и на уровне UIKit и на уровне GPU в каком-то виде.
Обычно проседают либо расчёт размеров, либо «тяжёлые» allocations (например, UIImage, NSAttributedString, NSCalendar и др.).
Only those users with full accounts are able to leave comments. Log in, please.