Примеры хорошие, но как по мне, лучше сразу объявлять вью-модели ячеек, с мапперами моделей уровня сервисов во вьюмодели. Вью-модели ячеек будут как раз таки содержать все необходимые свойства (высота, цвет, тип ячейки и т.д.), а таблица только подписывать на датасорс таких ячеек.
Во-первых не все. github.com/facebook/facebook-swift-sdk и github.com/BoltsFramework/Bolts-Swift
Во-вторых предупреждения «Block implicitly retains 'self'; explicitly mention 'self' to indicate this is intended behavior» же вообще выдаёт фэйсбуковская objective-c библиотека Bolts, которая является зависимостью objective-c библиотеки FBSDKCoreKit.
Ещё есть «прекрасный» инструмент KVC. И поменяв названия свойства, к которому, кто-нибудь обратится через KVC, мы словим очень «приятное» поведение в проде. А чего стоит эта самая диспетчеризация через посылку сообщений — отдельный разговор. Крч, простите но мне лично этот самый динамизм, ни капли не доставляет.
С пунктом «прост в освоении», можно поспорить хотя-бы с позиции свизлинга. Этот ваш самый динамизм, крайне противная штука в отладке. Можно столкнуться с тем, что уважаемый тов. разработчик потусторонней библиотеки, услужливо засвизлит вам метод, который свизлите вы или разработчик другой библиотеки. Чсх — это может произойти в какой-нибудь крайне важной для вас библиотеке(например, статистике) и вот ваша прекрасная библиотека проверки утечки не работает так, как вы того ожидали.
Использование кучи вырвиглазных вложенных макросов, тоже не прибавляет к порогу входа. Воспользуется какой-нибудь товарищ макросной магией, и в pch файле объявит макрос, который будет иметь тоже название, как и функция стандартной библиотеки (например, NSLog), которую вы, не подозревая надвигающегося краха, используете, начнёт вести себя не так. И вот макросы уже не кажутся таким прекрасным инструментом. А логи, которые пишут вам матерное слово, вместо того, чтобы логировать (это ещё хорошо, если все обойдется этим, а не записью на диск в главном потоке).
1) Менее строгая типизация из коробки без танцев с бубнами (а то, чем вы занимаетесь в статье — это танцы с бубнами).
2) Приходится писать больше кода, код менее читаем.
3) Много новых библиотек написаны на swift (например всякие аналитики от facebook). Там куча предупреждений от компилятора, которые разработчики не сильно то хотят и фиксить. Директивы игнорирования предупреждений периодически ломаются, причем на ровном месте, что мешает использовать флаг — treat warnings as errors.
4) Обобщения кастрированные.
5) Синтаксис замыканий вырвиглазный, приходится лазить на сайт fuckingblocksyntax.com
6) Количество файлов в проекте x2
Я могу ещё что-нибудь выделить, но пожалуй мне уже хватит.
Чего не хватает таким статьям — это бенчмарков произовдительности замеренной профайлерами. Да удобно, да быстро, но насколько это оптимизируемо.
Простой пример — таблица с большим количеством элементов, которой прилетает большое количество сигналов по обновление состояния. Сделайте бенчмарк и покажите насколько флаттер эффективен. С анимациями, с многопоточностью и т.д.
Есть такая концепци, как протекающая абстракция, которую ввёл Спольски. Суть в том, что на сколько бы не был прекрасна ваша абстракция, вы всё равно столкнётесь с проблемами, которые заложены в архитектуре нижних слоёв. Что-то мне подсказывает, что нативная разработка не будет заменена подобными фрейморками, только лишь из-за того, что существует это фундаментальная проблема.
Мне очень нравится frp. Но есть проблема высокого порога входа. Если вы пишите проект и нужно масштабировать команду, то люди не имевшие дело с ним будут долго учиться, пока смогут начать писать в истинно frp стиле. Как решать такую проблему?
Я с вами не соглашусь. Это прямая обязанность разработчиков и тестировщиков проверить то, как будет вести себя приложение в крайних ситуациях(на маленьких устройствах). Также разработчик обязан знать, как ведёт себя библиотека графических компонентов, которыми он пользуется каждый день. Про деньги можно долго рассуждать — но деньги это не задача программиста. Задача программиста качественный продукт. В последнее время почему-то любят путать и подменять понятия. Не надо так делать.
Добавлю:
1) Youtube. Зачастую лейбл в коментах не помещается на экране (iPhone SE). Видимо используют frame вместо autolayout, при это делая что-то не правильно(может тупо выключили autoresizing mask).
2) Vk. При открытии комментария к видео, фото, посту, автоматически открывается клавиатура. Но при скролле вниз, она не закрывается. Нужно было тупо проставить UIScrollViewKeyboardDismissMode в interactive. Ну на крайняк onDrag.
Зато те, кто это писал, смогут в сортировку не O(n^2), или обойти дерево вширь.
В целом да, я больше про:
Многие на таком вопросе сыпятся:
- Сделай retain cycle из одного объекта.
Скорее всего SideTableMark, для каких-нибудь инструментов/анализаторов памяти.
* Objective-C — developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011210
* Жизненный цикл — developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007072-CH1-SW1
* Многопоточность 1 (Threads) — developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/Introduction/Introduction.html
* Многопоточность 2 (GCD, NSOperationQueue) — developer.apple.com/library/archive/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008091
* UIView и всё что с ними связано — developer.apple.com/library/archive/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/Introduction/Introduction.html
* Autolayout — developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/index.html
* Core Data — developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/PersistentStoreFeatures.html
Знания общего назначения:
* Шаблоны проектирования — www.ozon.ru/context/detail/id/31789305
* Git — git-scm.com/book/en/v2
Во-вторых предупреждения «Block implicitly retains 'self'; explicitly mention 'self' to indicate this is intended behavior» же вообще выдаёт фэйсбуковская objective-c библиотека Bolts, которая является зависимостью objective-c библиотеки FBSDKCoreKit.
Использование кучи вырвиглазных вложенных макросов, тоже не прибавляет к порогу входа. Воспользуется какой-нибудь товарищ макросной магией, и в pch файле объявит макрос, который будет иметь тоже название, как и функция стандартной библиотеки (например, NSLog), которую вы, не подозревая надвигающегося краха, используете, начнёт вести себя не так. И вот макросы уже не кажутся таким прекрасным инструментом. А логи, которые пишут вам матерное слово, вместо того, чтобы логировать (это ещё хорошо, если все обойдется этим, а не записью на диск в главном потоке).
2) Приходится писать больше кода, код менее читаем.
3) Много новых библиотек написаны на swift (например всякие аналитики от facebook). Там куча предупреждений от компилятора, которые разработчики не сильно то хотят и фиксить. Директивы игнорирования предупреждений периодически ломаются, причем на ровном месте, что мешает использовать флаг — treat warnings as errors.
4) Обобщения кастрированные.
5) Синтаксис замыканий вырвиглазный, приходится лазить на сайт fuckingblocksyntax.com
6) Количество файлов в проекте x2
Я могу ещё что-нибудь выделить, но пожалуй мне уже хватит.
Простой пример — таблица с большим количеством элементов, которой прилетает большое количество сигналов по обновление состояния. Сделайте бенчмарк и покажите насколько флаттер эффективен. С анимациями, с многопоточностью и т.д.
Есть такая концепци, как протекающая абстракция, которую ввёл Спольски. Суть в том, что на сколько бы не был прекрасна ваша абстракция, вы всё равно столкнётесь с проблемами, которые заложены в архитектуре нижних слоёв. Что-то мне подсказывает, что нативная разработка не будет заменена подобными фрейморками, только лишь из-за того, что существует это фундаментальная проблема.
Ну подобные статьи прекрасно описывают хорошие стороны. Однако, у всего есть недостатки и за них обычно не доплачивают.
Не сочтите за параноика, но по первой части статьи показалось, что она написана на заказ. Если я ошибся, то можно воспринимать как комплимент.
Мне очень нравится frp. Но есть проблема высокого порога входа. Если вы пишите проект и нужно масштабировать команду, то люди не имевшие дело с ним будут долго учиться, пока смогут начать писать в истинно frp стиле. Как решать такую проблему?
1) Youtube. Зачастую лейбл в коментах не помещается на экране (iPhone SE). Видимо используют frame вместо autolayout, при это делая что-то не правильно(может тупо выключили autoresizing mask).
2) Vk. При открытии комментария к видео, фото, посту, автоматически открывается клавиатура. Но при скролле вниз, она не закрывается. Нужно было тупо проставить UIScrollViewKeyboardDismissMode в interactive. Ну на крайняк onDrag.
Зато те, кто это писал, смогут в сортировку не O(n^2), или обойти дерево вширь.