Size: a a a

2021 October 22

А

Алексей Зубков... in SwiftBook
Ну в таких ситуациях, конечно, нужно разговаривать с тимлидом насчет целесообразности таких отбраковок вариантов, но в данном случае я и сам вижу, что как-то не очень хорошо я сделал
источник

А

Алексей Зубков... in SwiftBook
В любом случае всем спасибо за помощь)
источник

S

Sasha_A in SwiftBook
просто это довольно странная “экономия” на таблицах, намного чище был бы код с двумя таблицами, пускай в них инициалищируются один и те же ячейки
источник

А

Алексей Зубков... in SwiftBook
Но с другой стороны, кода меньше, контроллер один, таблица одна, никаких переходов нет и код не сказать что сложный
источник

S

Sasha_A in SwiftBook
главный контроллер один и останется, но в нем будет две таблицы, или два разных UIView в разных файлах в которых будет одна и вторая таблица, то что общее - останется в общем месте, разное - в разных. и если в регистрации, например, изменится дизайн, это не затронит логин
источник

А

Алексей Зубков... in SwiftBook
Но зачем, если делегат у них общий (футер меняется, а хэдер один)
Не приходится менять таблицы и держать две в памяти
Вобщем, мне вариант с изменением датасорса кажется более эффективным и понятным, но это дело вкуса, судя по всему
источник

S

Sasha_A in SwiftBook
если всё такое похожее, может есть смысл сделать подходящий view state, который накидывается на одну и ту же таблицу и формирует или регистрацию или логин?

тут нужно прямо конкретный пример, если всё прямо одинаковое, то не нужно разные датасорсы, если разное - то две разные таблицы, а то выходит ни то ни сё)
источник

S

Sasha_A in SwiftBook
view и view controller лолжны быть максимально простыми, ты накинул тайтлы, какую-то подпись и пара UITextField и ему должно быть не важно, регистрация это или логин
источник

А

Алексей Зубков... in SwiftBook
Это все простое, конечно. Тут самое главне при смене датасорса - смена валидации на проверку введенных данных на наличие в бд и обратно
Ну и набор ячеек немного другой, конечно
источник

S

Sasha_A in SwiftBook
так зачем смена датасорса, если датасорс сам может быть, например, enum, и в нем в каждом кейсе свой вью стейт
источник

N

Nocto in SwiftBook
глупый вопрос - я понимаю, что делает task.resume() в URLSession, но как resume правильно переводится в этом контексте? получить ответ? возобновить?
источник

А

Алексей Зубков... in SwiftBook
Запускает таск
источник

А

Алексей Зубков... in SwiftBook
Я пока вряд ли компетентен рассматривать такие архитектурные вещи))
Но вообще я стараюсь, чтобы код был проще, понятнее и более тестируемым
Насчет твоего варианта я подумаю и, возможно, когда такой выбор будет зависеть от меня, задумаюсь
Спасибо)
источник

im

it's me in SwiftBook
привет, гайс. правильно понимаю что тут есть общий horizontal stack view, где слева один лейбл, а справа vertical stack view, где размещен знак цельсия и мин+макс температура?
источник

K

Kapitoshka438 in SwiftBook
Если бы я делал такой компонент, я бы не использовал stackView
источник

im

it's me in SwiftBook
а как можно? недавно со сторибордами, да и с ui начал разбираться, пока не знаю как по другому
источник

K

Kapitoshka438 in SwiftBook
Просто вьюшка и в ней лейблы. И разместить все через autolayout. Не важно сторибордом или кодом.
источник

im

it's me in SwiftBook
понял, спасибо
источник

S

Sasha_A in SwiftBook
так под капотом тот же самый автолейаут
источник

K

Kapitoshka438 in SwiftBook
Под капотом stackview тот же самый autolayout, который там реализован через задницу.
источник