Comments 28
Тренды какие-то… типа как понизить производительность ваших приложений, чтобы они на iPhone 6 лагали точно также, как и на iPhone 4. Единственное интересное — Realm.
Из другого интересного: в этом году FB выпустил такие библиотеки, как AsyncDisplayKit и pop, которые позволят нивелировать весь оверхэд от ReactiveCocoa.
Из другого интересного: в этом году FB выпустил такие библиотеки, как AsyncDisplayKit и pop
Это вы по опыту работы с UI с помощью ReactiveCocoa? А то присматриваюсь к ReactiveCocoa в качестве описания цепочек обработки/загрузки данных.
Кстати у FB была интересная презентация, в которой они рассказывали про опыт использования MVVM при разработке Paper.
К сожалению они там не рассказали технические детали. Возможно это был RAC, но скорее всего, запилили что-то свое.
К сожалению они там не рассказали технические детали. Возможно это был RAC, но скорее всего, запилили что-то свое.
Apple зашерлочил Reveal, а также приобрел TestFlight.
По-моему, встроенный view hierarchy убогий и, по сравнению с Reveal, совсем бесполезный. Он останавливает приложение и нет возможности изменять значения пропертей. Лично мне редко когда мог помочь просто факт наблюдения иерархии: когда что-то не так, то обязательно хочется что-нибудь подвигать или хотя бы перекрасить в другой цвет. С помощью Reveal я иногда подгоняю верстку под макет — кладу в бекграунд скриншот с макета, выставляю демо-данные и прикидываю, что и на какое расстояние не совпадает с макетом.
Futures все таки не замена сигналам это как сигнал с одним next. С помощью сигналов удобно связать компоненты интерфейса и вобще всей программы в единый поток информации. Так же из трендов я бы отметил уход в сторону immutable структур. Помню, на RACDC в этом году все офигели от доклада Jon Sterling vimeo.com/98100160. Это то куда стоит смотреть и развиваться.
P.S. State is the root of all evil.
P.S. State is the root of all evil.
Realm ещё очень сырой. Был негативный опыт использования. Например, за время разработки несколько раз была ситуация когда после падения приложения база Realm'а становилась полностью неработоспособной.
спасибо e-Legion. Попробую Reveal.
Очень надеюсь, что популярность ReactiveCocoa будет падать, ибо пока что этот фреймворк приносит только вред, а не пользу. Вместо loose coupling получаем на выходе бешеную колбасу из блоков и коллбэков, которая в определенный момент становится совершенно нечитабельной
Пример
На мой взгляд фреймворк не решает никакой проблемы в принципе, только их создает.
Пример
На мой взгляд фреймворк не решает никакой проблемы в принципе, только их создает.
Полностью поддерживаю, часто RAC внедряют не потому что оно надо для каких то целей, а потому что «в тренде», «модно» и т.д.
Без сомнения, RAC можно использовать в некоторых моментах, но, опять же, в тех же случаях можно обойтись делегатами или KVO.
Без сомнения, RAC можно использовать в некоторых моментах, но, опять же, в тех же случаях можно обойтись делегатами или KVO.
Если получается бешеная колбаса, это явный признак того, что разработчик не умеет RAC готовить.
А по ссылке — все еще разрабатываемое нестабилизированное Swift API.
А по ссылке — все еще разрабатываемое нестабилизированное Swift API.
Довольно приятными нововведениями в XCode6 для меня стали Live Rendering и IBInspectable параметры. Ну и конечно нормальная поддержка custom шрифтов.
IBInspectable + IBDesignable вместе со свифтом просто божественны, без фреймворков позволяют сразу видеть, как вьюха будет выглядеть на любом размере экрана.
Немного не хватает поддержки UIViewController для IBDesignable, надеюсь Apple допилят, все-таки prepareForInterfaceBuilder обьявлена в категории на NSObject, а не на UIView.
Немного не хватает поддержки UIViewController для IBDesignable, надеюсь Apple допилят, все-таки prepareForInterfaceBuilder обьявлена в категории на NSObject, а не на UIView.
а как по-вашему должен выглядеть IBDesignable контроллер?
Контроллер имплементит prepareForInterfaceBuilder, закидывает стабнутые значения для моделей, и выглядит так, как в живом приложении. Как вариант можно даже не стабать модели, если используете тот же OHHTTPStubs.
В данный момент сториборды могут рендерить вьюхи, но не могут рендерить UIViewController. Хотя метод prepareForInterfaceBuilder находится в категории на NSObject, что намекает на то, что рендерить можно не только UIView.
В данный момент сториборды могут рендерить вьюхи, но не могут рендерить UIViewController. Хотя метод prepareForInterfaceBuilder находится в категории на NSObject, что намекает на то, что рендерить можно не только UIView.
Просто я к тому, что, UIViewController никак не выглядит. У него есть аутлет на view, которой можно сделать кастомный класс, например.
Для 99% UIViewController используется стандартный UIView, заменять его на кастомный ради рендеринга — костыль. И как раз UIViewController очень даже нормально выглядит, и показывается в live preview на разных разрешениях экрана. В данный момент удобно открывать превью с 3.5, 4, 4.7, и 5.5 inch, чтобы сразу видеть, правильно ли настроены те же autolayout constraints.
И за исключением IBDesignable части, все статические элементы прекрасно видно. Если они допилят IBDesignable — будет потрясающе, необходимость запускать симулятор практически отпадет.
И за исключением IBDesignable части, все статические элементы прекрасно видно. Если они допилят IBDesignable — будет потрясающе, необходимость запускать симулятор практически отпадет.
Это его view показывается в live preview, а не viewController. View в контроллере совсем не наглухо вмонтирована, Ее можно просто взять и удалить, останется контроллер совсем без view. Что он тогда должен показывать?
По-моему, делать кастомный класс вьюхи в контроллере – совсем не костыль, а наоборот true way. Чтобы сама кастомная вьюха умела себя показывать в зависимости от своего состояния, а не контроллер бы знал как в обычную UIView напихать всего подряд и моргать на ней лампочками. Тогда эту вьюху можно будет переиспользовать в других местах, где не нужен контроллер (appear/disappear/отслеживание ориентации, связь с другими компонентами и др) и просто добавлять её как subview.
По-моему, делать кастомный класс вьюхи в контроллере – совсем не костыль, а наоборот true way. Чтобы сама кастомная вьюха умела себя показывать в зависимости от своего состояния, а не контроллер бы знал как в обычную UIView напихать всего подряд и моргать на ней лампочками. Тогда эту вьюху можно будет переиспользовать в других местах, где не нужен контроллер (appear/disappear/отслеживание ориентации, связь с другими компонентами и др) и просто добавлять её как subview.
Не согласен с вами. Кастомную вьюху имеет смысл делать, когда у нее есть функционал, которого нет в стандартной. Например — у меня в проекте есть UIButton, который через IBInspectable поддерживает borderColor, borderRadius, и так далее. Для использования достаточно подкинуть, и выставить значения в IB.
А что будет делать вьюха контроллера, если вы сделаете ее кастомной? Все равно за весь контент отвечает контроллер, а не UIView.
Любую UIView, которую можно реюзнуть, разумеется стоит делать кастомной, но вьюха UIViewController имхо не тот случай.
А что будет делать вьюха контроллера, если вы сделаете ее кастомной? Все равно за весь контент отвечает контроллер, а не UIView.
Любую UIView, которую можно реюзнуть, разумеется стоит делать кастомной, но вьюха UIViewController имхо не тот случай.
Но ведь у всех ваших вьюх в контроллерах функционал, которого нет в стандартной UIView. В ней куча каких-то сабвьюх, лейблов, кнопок и так далее.
В моем идеальном мире, все вьюхи имеют наружу только «примитивные» типы (NSInteger, NSString, NSDate), а все аутлеты скрыты в имплементации. ViewController лишь подписывается на разные экшены от этой вьюхи и манипулирует вьюхиными пропертями. То есть просто наполняет вьюху данными, но сам за отображение не отвечает. А у нас обычно что — куча аутлетов на всякие контролы, там же всё двигается, показывается, прячется и тд. Данные тоже прям в контроллере получаются (запросы в сеть, в бд, etc) – это же полная лапша
В моем идеальном мире, все вьюхи имеют наружу только «примитивные» типы (NSInteger, NSString, NSDate), а все аутлеты скрыты в имплементации. ViewController лишь подписывается на разные экшены от этой вьюхи и манипулирует вьюхиными пропертями. То есть просто наполняет вьюху данными, но сам за отображение не отвечает. А у нас обычно что — куча аутлетов на всякие контролы, там же всё двигается, показывается, прячется и тд. Данные тоже прям в контроллере получаются (запросы в сеть, в бд, etc) – это же полная лапша
Я и не говорил, что UIViewController должен отвечать за отображение. Это может быть иерархическая структура.
Делаем IBDesignable UIViewController, в нем IBDesignable UIView и так далее. Каждый из этих классов имплементит prepareForInterfaceBuilder. И мы сразу видим результат в preview. Прекрасно же было бы.
В вашем же случае, вам доступна только вторая часть с UIView, что режет полезность функционала в два раза.
Делаем IBDesignable UIViewController, в нем IBDesignable UIView и так далее. Каждый из этих классов имплементит prepareForInterfaceBuilder. И мы сразу видим результат в preview. Прекрасно же было бы.
В вашем же случае, вам доступна только вторая часть с UIView, что режет полезность функционала в два раза.
UIViewController не отображабельный, у него нет никакого интерфейса, чтобы тот был Designable. Это просто такой сабкласс NSObject, у которого есть проперти типа UIView. Всё, что он делает, так это заполняет эту проперти в loadView и вы там можете загружать всё что угодно (если сегодня четверг — то UIView, а если пятница — то UICollectionView) – как здесь понять, что должно загружаться в таком контроллере?
Допустим, UITableViewController в initWithStyle просто запоминал бы style и потом загружал бы или UITableViewPlain или UITableViewGrouped вьюху, обе UIView<UITableView> — какой здесь у контроллера должен быть «интерфейс»?
Интерфейс контроллера — это его View, которая IBDesignable, как и положено. Вот эту View и надо рендерить, ее и надо конкретизировать.
Допустим, UITableViewController в initWithStyle просто запоминал бы style и потом загружал бы или UITableViewPlain или UITableViewGrouped вьюху, обе UIView<UITableView> — какой здесь у контроллера должен быть «интерфейс»?
Интерфейс контроллера — это его View, которая IBDesignable, как и положено. Вот эту View и надо рендерить, ее и надо конкретизировать.
Sign up to leave a comment.
Тренды iOS–разработки 2014 года