skillbox пожалуйста обновите статью. Решение задачи 4 содержит ошибку: если у вас решением задачи будут 2 последних элемента массива, то мы также как и в 1м случае получим O(N^2)
мнимая вещь? если разработчикам не важна стабильность и поддерживаемость решения то да, можно сказать мнимая. Но если вы серьезно относитесь к своей работе — то нет. Линтеры вас не особо спасут. Например, бывало что люди изобретают свой vtable вместо использования виртуальных функций. Как такое отловит линтер?
к слову, практически в любом более или менее успешном проекте код ревью очень затяжный процесс. Например, в сообществе разработчиков llvm: www.youtube.com/watch?v=jqAUxr-vDe0
Спасибо за Chatto всем его авторам! Спасибо, что выложили в open source! Вещь очень классная. Я погонял ChattoApp под хорошей нагрузкой. Отлично справляется. Другие, известные мне, движки далеко позади.
В комменте ниже, есть более адекватная замена:
> Для реиспльзуемых элементов можно использовать ContainerView + Embed Segue в storyboard.
> Этот вариант удобней тем, что прямо в storyboard вы настраиваете какой контрой в какое место вставлять, то есть не нужно писать дополнительный код как в случае с xib.
Честно говоря, при первом прочтении я неправильно как-то понял идею… В чем принципиальное отличие от того, чтоб хранить VIewController в самом Storyboard-е?
Не знаю правильно ли я все понял… но, в целом, описанная выше методология, оказалась в разы удобней, чем один роутер на все приложение. И передача параметров и все остальное.
Спасибо за доклады! На много лучше начал понимать КАК надо делать VIPER.
Я пытаюсь разобраться с тем как реализована передача данных из одного модуля в другой. Представим, что у нас есть два модуля: ItemList (UITableViewController со списком сущностей типа ItemEntity) и ItemForm (UIViewController, где можно отредактировать поля выбранного ItemEntity).
1. Пользователь тыкает по строчке с Item
2. tableView сообщает своему Presenter, что didSelectItemAtIndexPath
3. Presenter сообщает своему Router, что надо открыть форму ItemFormViewController (withSegueIdentifier: «to item form»)
4. по слайдам — у Router-а, есть ссылка на TransitionHandler, у которого есть метод openModule(segueIdentifier: String, block: (..) -> Void); этот метод ретранслируется в performSegue;
5. А вот тут начинаются трудности…
Во-первых, не понятно какой должен быть параметр у block: (… тут..) -> Void. Т.к. ожидаемо, что это будет ModuleBInputProtocol. Но мы тут как бы не должны завязываться на модуль B (мы же хотим, чтоб этот метод открывал и другие модули, или нет?). Можно сделать во ViewController такое:
func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject?) {
if segueIdentifier == "to item form" {
let configHolder = segue.destinationViewController as! ModuleBConfigurationHolder
let input = configHolder.moduleInput as! ModuleBInputProtocol
let configBlock = sender as! ((input: BaseModuleInput) -> Void)
configBlock(input)
} else if segueIdentifier == "to next page" {
.. то же самое что и выше, только другой модуль ..
} ..
}
Но это ж бред…
Т.е. по картинкам и слайдам кажется, что понятно, но когда пытаюсь реализовать (на swift-е), получается *** какая то.
Язык ruby я знаю достаточно хорошо, и с крутостью рантаймов ruby/objc (идеологических аналогов smalltalk) тоже знаком. Но такая гибкость часто выходит боком — слишком многое приходится хранить в своей голове. Тогда как при строгой типизации — компилятор очень часто спасает от запоминания типов функций, переменных и тд.
Есть такая штука protocol-oriented programming, которая мне очень нравится, особенно в swift 2. К тому же я не могу себе представить более или менее гибкую архитектуру без абстрактных интерфейсов (т.е. protocol).
Не буду разводить холивар, но мне комфортней работать со статической типизацией. Я никого к этом не призываю, просто мне так удобнее.
Просмотрел rubymotion по диагонали — вещь конечно интересная, но ruby лишен типизации, а это, на мой взгляд, очень серьезная беда. Там свои свой рантайм (не MRI), но есть ли там типизация я не понял. Не могли бы прояснить?
К тому же нет protocol-ов — это совсем плохо… Как вы без них живете? или они есть?
Хм, понятно. Дело в том, что при загрузке сториборды у нас, по не очевидной причине анимация дергалась. Я во всем винил процесс декодирования, видимо, зря…
Не могу согласиться с этим утверждением. Во-первых, появляются Base.lproj/en.lproj директории и наш Storyboard среди фалов находить становится трудней. Во-вторых, NSLocalizedString на много удобней. И наконец, если мы удалили View и добавили другую, скажем, с аналогичным содержанием (например, был toolbar решили сделать все в custom view) у нее будет другой идентификатор и, соответственно, ее нужно опять переводить.
Пока не тормозит — используем автолэйаут, когда начинает тормозить — переходим на ручной счет. Если еще нужно ускорить — переносим в бэкраунд поток, где все и рассчитываем.
Пост от Александра Орлова — habrahabr.ru/post/264817. Пока ничего более путного, чем то, что было в докладе — не встречал.
Пример, когда это необходимо: гипотетическое новостное приложением; скажем новости делятся на 4-5 видов и в них используется UITextView (не фиксированной высоты) + до 20 различных view. Соотвественно высота ячейки зависит от высоты TextView (может еще быть несколько Label-ов не фиксированной высоты и ширины). Тогда будет тормозить, знаю на своем опыте.
Можно кэшировать, но все равно будет много глюков; т.к. при первичной прорисовке ячейка будет дергаться пытаясь вычислить правильную высоту. А это очень неприятный юзер экспириенс. В итоге придется считать вручную.
Да, когда поменяется ориентация — вам придется заново все пересчитывать и если лэйауты отличаются, то возни будет достаточно. Никто и не обещал, что будет легко:)
к слову, практически в любом более или менее успешном проекте код ревью очень затяжный процесс. Например, в сообществе разработчиков llvm: www.youtube.com/watch?v=jqAUxr-vDe0
> Для реиспльзуемых элементов можно использовать ContainerView + Embed Segue в storyboard.
> Этот вариант удобней тем, что прямо в storyboard вы настраиваете какой контрой в какое место вставлять, то есть не нужно писать дополнительный код как в случае с xib.
Спасибо за доклады! На много лучше начал понимать КАК надо делать VIPER.
1. Пользователь тыкает по строчке с Item
2. tableView сообщает своему Presenter, что didSelectItemAtIndexPath
3. Presenter сообщает своему Router, что надо открыть форму ItemFormViewController (withSegueIdentifier: «to item form»)
4. по слайдам — у Router-а, есть ссылка на TransitionHandler, у которого есть метод openModule(segueIdentifier: String, block: (..) -> Void); этот метод ретранслируется в performSegue;
5. А вот тут начинаются трудности…
Во-первых, не понятно какой должен быть параметр у block: (… тут..) -> Void. Т.к. ожидаемо, что это будет ModuleBInputProtocol. Но мы тут как бы не должны завязываться на модуль B (мы же хотим, чтоб этот метод открывал и другие модули, или нет?). Можно сделать во ViewController такое:
Но это ж бред…
Т.е. по картинкам и слайдам кажется, что понятно, но когда пытаюсь реализовать (на swift-е), получается *** какая то.
Есть такая штука protocol-oriented programming, которая мне очень нравится, особенно в swift 2. К тому же я не могу себе представить более или менее гибкую архитектуру без абстрактных интерфейсов (т.е. protocol).
Не буду разводить холивар, но мне комфортней работать со статической типизацией. Я никого к этом не призываю, просто мне так удобнее.
Есть ли руби с типами?
К тому же нет protocol-ов — это совсем плохо… Как вы без них живете? или они есть?
Пост от Александра Орлова — habrahabr.ru/post/264817. Пока ничего более путного, чем то, что было в докладе — не встречал.
Также см. github.com/plasmLC/PPlayer (по рекомендации Алексндра).
По поводу, autolayouts — споры бесконечны. Но плюсов от них меньше чем минусов, судя по моему опыту.
Можно кэшировать, но все равно будет много глюков; т.к. при первичной прорисовке ячейка будет дергаться пытаясь вычислить правильную высоту. А это очень неприятный юзер экспириенс. В итоге придется считать вручную.
Да, когда поменяется ориентация — вам придется заново все пересчитывать и если лэйауты отличаются, то возни будет достаточно. Никто и не обещал, что будет легко:)