MVVM SwiftUI вопрос про классы


#1

Привет Всем, хочу спросить, делаю мввм в сфитюай, ViemModal всегда должен быть классом, у меня вопрос например есть дата товаров, дата категорий, итп другие даты, у них у все должен быть один класс для передачи к вием или для каждой структуры даты имеется всегда свои класс? просто где то видел тип делал один класс а где то тип делал для каждой отдельный класс. Надеюсь это не особо влияет если будет три класса для каждой даты например. Надеюсь я понятно объяснил, я на сфивте 6 месяцев, новичок


#2

Сразу же ответ: рано вам за SwiftUI браться!

  1. Трудности возникнут именно с архитектурами и много с чем ещё! Если до этого не программировали вообще, то MVVM не самое простое начало.
  2. В основе SwiftUI лежит UIKit - его учить в любом случае надо. Он и для начинающего намного проще и дружелюбнее.
  3. И самое главное, SwiftUI выглядит просто только на обучающих видео, когда надо сверстать интерфейс. Но этот Фреймворк ещё очень ограничен, яркий пример - действия в списках: хотите кастомизировать экшен “удаление” - нельзя, нет такой возможности пока. Хотите добавить других экшенов - фигушки, вам доступен всего один экшен!!! Хотите сделать вложенные кастомные классы в моделях: пожалуйста, но SwiftUI не видит свойства вложенных вьюмоделей, без костылей и Combine(тут конечно имеется ввиду доступность уведомления от паблишеров. С прямой видимостью проблем нет. При этом если видимость паблишеров вниз иерархии вложенности вьюмоделей решается через перезаписывание параметров модели отдельно во вью модель, то видимость паблишера наверх всё ещё проблема без танцев с бубном, которого я пока не нашёл или понял). Хотите кастомизировать любой элемент - только с костылями… И такого там много. Это фреймворк на будущие, но точно не для начала учёбы!

SwiftUI от части вырос из Combine. Почитайте вот эту статью - там описано применение Combine для конкретной задачи. Грубо, вот это всё надо именно понимать, чтобы эффективно работать с SwiftUI. Если вы даже не дочитали до конца - бегите скорее за UIKit, чтобы зря не терять время :wink:

Под капотом места на движок для Мустанга или Камаро, но стоит пока от Оки ))) Ждём WWDC2020 и надеемся, что все проблемы решат.

По существу:

Абсолютно необязательно. Применительно же к SwiftUI, вьюмодель можно (а иногда полезно) делать структурой, если нет вложенного кастомного класса. Тогда как раз к такой вью модели, если она вложена в другую, можно добраться через AnyCancellable от Combine.

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

Ещё раз: это хорошо, когда вы интересуетесь архитектурами, паттернами и прочими инструментами. Но всему своё время! Если вы не понимаете зачем вам MVVM, то и в SwiftUI вам рано. Максимум вы быстро что-то сверстаете, а потом в тупике встанете из-за недофункциональности фреймворка и всё, и это при условии безусловного понимания зачем там MVVM. Когда вы начнёте понимать, что вам нужен какой-то инструмент (MVVM, фабрика или координатор, например), то настало время для его применения. До этого вам это будет только мешать и тормозить. Делайте сначала как можно проще, чтобы было удобно вам. Пусть этот код вам покажется жутким через полгода, но главное на первых парах хоть что-то сделать, а не гнаться за идеалом.

Настоятельно рекомендую сначала выпустить хотя бы одно боевое приложение в стор на UIKit, а там и годик пройдёт, опыта поднаберётесь :slight_smile:


#3

Это всегда так удручает :sob:


#4

а что делать, опыт сам не появится у человека )))
Это тут в ответах все профи и за день выпускают и кажется сейчас я с налёту эээх. А пока релиз первого приложения готовишь - полгода прошло. Пока баги устраняешь и функции добавляешь - ещё пол. А там новая ось - блин! :rofl:


#5

Это вы еще переписывания не учли, после “осинений”)


#6

Учёл ))) Я так три раза начинал прогу полностью занового за полгода, когда видно было, что проще с нуля всё переписать, чем ковыряться в своём старом коде :slight_smile:
Для новичка, который только учится и не состоит ни в каких командах или не работает по направлению, значит кодит в свободное время, для небольших приложений 3-6 месяцев реальное время выпуска первого боевого приложения, которое чем-то отличается от тонн других :slight_smile:


#7

Ахахахахах))
Таже история))


#8

Кстати, как раз её начал месяц назад опять с нуля в 4й раз, теперь на SwiftUI - ещё вернусь на UIKit в пятый раз, если на WWDC2020 ничего не изменится )))


#9

не знаю, не могу согласится, мне не нравиться UIKit, я купил мак как хобби программировать именно на новом Фреймворк. Смотрел много видосов, сегодня пересмотрел, понял что большинство делаю много классов, а что касается комбайн и костыли, не могу ничего сказать) все работает) хочу купить аккаунт разработчика, пока не удается, оплату отклоняют, друг пытался с США оплатить, тоже отказ, и я так понял заработать можно в маленьких фирма и на фрилансе типа апворк, ну и собственное приложение. В любом случае на новый фреймворков будущее и когда нибудь пригодится)


#10

В рамках простых моделей или простых свойств в виде @State (как в обучающих видео) вообще проблем нет :slight_smile: но один экшен в списках и прочее никуда не делось.

И всё же обучающие видео и боевое применение два полюса, достаточно далеко расположенных друг от друга. На фрилансе вам ни кто не закажет на SwiftUI еще года 2. :slight_smile:

Удачи.


#11

MVVM – рано. А с чего тогда посоветуете начинать и в каком порядке двигаться?


#12

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


#13
  1. В основе SwiftUI лежит UIKit - его учить в любом случае надо. Он и для начинающего намного проще и дружелюбнее.

Ага проще и дружелюбнее с его констрейнтами и делегатами и датасорсами для таблиц. В SwiftUI для создания таблицы достаточно написать List {Text(“строка таблицы”) } и все таблица готова, а сколько кода нужно чтобы сделать таблицу в UIKit, я думаю минимум 20-30 строк. Это с учетом того что констрейнты вы зададите в интерфейс билдере, а если их кодом привязывать, то вообще тушите свет.


#14

А чем так плох MVC? в случае swift-а? Я swiftUI еще не трогаль, только мельком видел, там да, наверно vm необходим

ну вообще это + 8 строк


#15

Конечно можно и штангенциркулем гвоздь забить, но зачем, когда молотком быстрее, удобнее и эффективнее. MVC+UIKit - это всё, что надо. Остальное по организации файлов, хардкода и прочего всё сами поймёте. Главное делать то, что сейчас получается, чтобы выпускать что-то боевое. Далее сами будете постепенно переходить выше по инструментам - и сами чётко поймёте, что вам надо, когда это случится. Если чёткого понимания нет, то скорее всего это пока ещё сложный инструмент для вас.

Я же из добрых побуждений пытаюсь до вас донести, чтобы новичок не очаровывался кажущейся простотой SwiftUI. Я через это прохожу сейчас, и честно - это не самое простое, с чем я сталкивался за 2,5 года. Всё отлично выглядит на видео и на простых примерах. А когда дело доходит до банального ту-ду листа с бесконечной вложенностью, который на Ките делается элементарно - вот тогда мы с вами обсудим ваш List {Text(“строка таблицы”) }.

И ещё раз вам напомню, что List и другие объекты в ЮАй это структуры-обёртки для элементов ЮАйКита. Внутри которых те же элементы Кита с датасорсами и те же контсрейнты, именно поэтому всё равно Кит знать необходимо.

Ничего там сложного нет, зато ими управлять элементарно. В ЮАй вы мало чем можете управлять - используете, что дали и всё.

Мне, как заказчику, главное результат - хоть на Обжективе пишите, всё равно - нужно же приложение. И вот я вам говорю, что мне надо в таблице по свайпу налево было два экшена “редактировать” и “удалить” и вы идёте мимо со своим ЮАй, так там это пока сделать нельзя ))) Даже иконку на удалить поставить нельзя :wink: Про свайпы направо вообще молчим, а на Ките СвайпЭкшены элементарны. Да на Ките всё элементарно!

ЮАй определённо фреймворк будущего, но через минимум год, скорее 3.

Начинать учить продакшн с реактивщины ну такое себе.

Я всего лишь пытаюсь сэкономить ваше время, а остальное ваше дело :slight_smile:


#16

я понял, это на стеке есть, там тип через протоколы, классы из юайкит так замутил, он говорит что пока да это нельзя делать но будет большое обновление и возможно в 2020 презентации, ждем) если будет какая то крутая обнова, то юайкит может рухнуть и стать древним, по поводу того что кто то тут пишет что сфитюай тяжелой, не знаю я сидел по 6 часов в среднем почти каждый день, особенно на карантине и делал разные юа интерфейсы. я скажу так сначала было геморройное, сейчас я много разного читаю, делаю, я хочу именно достичь уровня когда с 0 можешь сам написать без там посмотреть куда то, гуглить итп. Я всего 6 месяцев, самое большое что я делал это файрбейс заказ пиццы, категорий, доставки, итп, взял просто додопицца и начал делать. Файрбейс кстати нравиться тема, я так понял лучше файрбейс использовать если маленький проекты, вепоры и другие беки это когда проекты типа Баду сбербанк итп


#17

кстати сфитюай со своим комбайн, враперами это и есть мввм. Мой вопрос был только использовать один класс, типа Файнал класс или несколько, так вот посмотрев разных типов, всякие гитхабы проекты, я понял что большинство делают 4-6 классов, каждый из которых имею функции и передает вьюшке что то, как она должна там выглядит. хороший уроки преподаватель из Стэнфорда. посмотрите статьи переведи в инете


#18

Этого не будет ))) Спросите ребят от сюда из реального продакшена - у заказчиков в подавляющем большинстве сейчас в ходу поддержка 8-9 ОС. Какой там ЮАй…

SwiftUI - фреймворк, Combine - фрейворк, папа ЮАйя. Wrapper - свойство. MVVM - архитектура.

Ну а по остальному я ничего не понял: знаки препинания и согласованность слов на уровне - уж извините, мне нечего ответить.


#19

откуда ты знаешь что этого не будет?) ты же будущее не видишь) причем тут заказчики, мне они не интересны, я изучаю для себя и свои приложений, мой заработок не они) Кстати нормальные курсы еще не встречал как и видосы у наших, много воды, притом что типы сидят на сфивте уже по 5 и более лет.

Я спрашивал о класса, а речь зашла о новом Фреймворке, я только говорю что новый удобнее, быстрее, лучшее, понятно что он сырой, но я думаю через год два норм будет.


#20

Есть неплохой курс от Отуса, там неплохо swiftUI затрагивается

О каких именно классах вы спрашиваете?

giphy

Ой боже, дошло))) Чет я нес того места вступил, прошу прощения

Чисто теоретически на один VC вам нет особой необходимости иметь много VM

У меня, при условии реактивщины, обычно используется один viewModel, задачей которого является биндинг View c различными сервисами, например, vm сам не умеет ходить в базу за товарами и/или категориями, он обращается к стору, говорит мне нужны категории, стор отдает категории, vm при необходимости мапит их в удобный для View формат, при всем этом View получается ну очень “глупый”

Логики как таковой VM не имеет, это лишь прослойка, между View и сервисами

Может знатоки поправят или в swiftUI все иначе)