#ios #xcode #swift
Не имею четкого представления и понимания о правильных подходах к реализации/программированию
именно UI-части приложения, с так скажем "backend" частью пока особых проблем нет.
Приведу пример:
Когда понял, что приложение нуждается в подчинении чему-то более продвинутому и современному
чем простой MVC, изучил вопрос архитектурных паттернов, выбрал подходящую(VIPER), изучил
более подробно и реализовал.
Однако следующие задачи:
Сделать переиспользуемую сетку с элементами вида "иконка - подпись", причем
на маленьком экране показывать в три столбца, на больших в четыре, плюс слегка увеличивать-уменьшать
размер самих этих иконок и подписей. В итоге создал xib-файл для одного такого элемента
сетки, и класс-наследник UIView, в который передается массив картинок/подписей и он
там у себя все высчитывает и строит
Два блока(верхний и нижний) могут изменяться в размерах относительно контента,
а блок между ними(label) занимать все оставшееся место. При этом текст в UILabel не
должен уходить половиной строки под frame. Пришлось в коде слегка обрезать высоту label
чтобы длина была кратна высоте одной строки
Переиспользовать таблицу, убрав некоторые кнопки из tab-bar. Например есть основная
лента элементов, а есть такая же лента, только с избранными
вызвали у меня намного больше проблем и гуглить их реализацию было намного сложнее.
В итоге все сделал сам, однако уверен что есть более правильные и элегантные подходы
к решению тех задач с UI, которые появляются с каждым днем. Также есть вопрос: Storyboard
или UI в коде? Или часть там, часть - там? Пока что у меня второй вариант с отдельным
сторибордом для каждого контроллера и вкраплениями xib-файлов для каких-нибудь переиспользуемых
вьюшек вроде круглая иконка и подпись. Однако есть подозрения что лучше делать это
в коде (задание размеров, позиций, constraint-ов), с использованием сторонних библиотек
для layout-а, т.к. быстрее с точки зрения работы приложения , удобнее и легче с точки
зрения контроля версий.
Вопрос не по конкретно вышеперечисленным моментам, а по общей теоретической подготовке
и хорошим практикам по работе с UIKit. Ибо просто накидать нужный не-адаптивный интерфейс,
связать аутлетами и заполнить view нужным контентом я могу уже давно, даже 70 процентов
задач autolayout удается реализовать вполне себе хорошо. Однако в процессе разрастания
и усложнения ui и возможностей приложения, все сильнее нуждаюсь в теории и практикам
по UIKit уровня выше junior. Подскажите пожалуйста, какие на данный момент bad/best
practices, что считается хорошим тоном, а что нет? Может есть какие-нибудь сайты/туториалы,
где показывают как создавать переиспользуемые UI-компоненты, как строить сложный autolayout(как
правило все туториалы очень простые и в реальной жизни приходится делать что-то в разы
сложнее, а правильной теоретической базы по решению тех или инных более менее сложных
и реальных задач UI нет).
Ответы
Ответ 1
Тут вопрос зависит от ваших ресурсов, если не требуется детальная обработка UIView, то лучше использовать XIB или Storyboard, это сэкономит вам уму времени. Если нужно нарисовать сложный UI то лучше сдлетаь это кодом в кастомном классе наследуемом от UIView, с добавлением Core Graphics и Core Animation. Вот тут более детально описываются плюсы и минусы. Статья довольно старая, но концепция не изменилась. Ручная верстка vs Storyboard/Nib По воду практики могу посоветовать только платные курсы. С свое время они мне очень сильно помогли. Custom Controls in iOS, Drawing in iOS Предпочтительнее пройти второй курс, так-как он написан на swift 4. Так-ж если собираетесь создавать UIView кодом. Эта библиотека очень упростит вам жизнь. SnapKit
Комментариев нет:
Отправить комментарий