Как стать автором
Обновить

Комментарии 9

Когда уже будет хоть один нормальный пост на эту тему… Пичаль
Имхо, главная проблема MVVM — без хорошего редактора он ничего не стоит. Так что я не уверен, что попытки использовать этот паттерн в Obj-C/Swift принесут ожидаемый результат.
Одна из главных проблем при разработке под iOS это Massive View Controllers, вот для борьбы с таким и используют MVVM, что бы по максимум разгрузить ViewController. Если я ошибаюсь, то поправьте меня.
Проблема в том, что вы замучаетесь писать биндинги и конвертеры вручную, если у вас нет достаточно мощного инструмента.
С другой стороны — вопрос быстродействия. Первый кандидат на роль биндингов — KVO, но чаще всего — это плохая идея с точки зрения быстродействия. Значит нам нужны свои собственные dependency property. А ещё нужна реализация двухсторонних биндингов для пользовательского ввода.

В другой стороны, можно (и нужно) просто скинуть всю визуальную логику в потомок от UIView и сделать его вьюхой контроллера, оставив в UIViewController только делегаты и обновление данных.

В общем, я не уверен, что оно того стоит. Как баловство в каком-то своём проекте — почему бы и нет? А вот для чего-то серьёзного — я бы не стал использовать этот подход напрямую.
а о каком редакторе идет речь?
В данном случае я имел ввиду редактор XAML в Visual Studio: помимо функционала визуального редактора он так же умеет делать автозавершение и автоматическую генерацию методов. В основном это вызвано тем, что концепция MVVM для WPF родная.
Спасибо за такой краткий пример приложения с rx!

Для тех, кто будет следовать туториалу описанному в статье, хочу заметить, что в ViewModel в конструкторе код в блоке subscribeNext вызывается, только при успешном ответе на запрос. То есть, например, если Вы сформируете не правильно URL без AppID, то на запрос прийдет ошибка, а Вы об этом не узнаете и будете ругать RX.
Примечание: SwiftyJSON является обязательным для разбора JSON в Swift.


Он же слишком generic и очень медленный? Вчера например парсил json в котором массив из 490 объектов, парс одного объекта занимал 0.2 секунды(iPhone 6+), т.е. на парс всего объекта ушло бы ~100 секунд, но к сожалению не хватило оперативы. Может я конечно что-то делал не так :)

Пример кода и замеры на симуляторе iPhone 7+, чтоб хватило оперативы на парс:

Код
func parse(data: Data?) -> [Shop] {
var shops = [Shop]()
let date = Date()
if let data = data,
let jsonS = try? JSONSerialization.jsonObject(with: data, options: JSONSerialization.ReadingOptions(rawValue: 0)) as? [String: Any],
let dataz = jsonS?["dataz"] as? [String: [String: Any]] {
shops = dataz.flatMap({Shop(json: $1)})
}
print("simple parse \(date.timeIntervalSinceNow)")
print(shops.count)
return shops;
}

func parse(swiftyData: Data?) -> [Shop] {
var shops = [Shop]()
let date = Date()
if let data = swiftyData {
let json = JSON(data: data)
let dataz = json["dataz"]
shops = dataz.flatMap({Shop(switfyJSON: $1)})
}
print("swifty parse \(date.timeIntervalSinceNow)")
print(shops.count)
return shops;
}


Вывод
simple parse -0.099996030330658
490
swifty parse -28.3243499994278
490
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.