Я безусловно плюсанул, спасибо за статью! Но мне показалось на первый взгляд, что это попытка спрятать бойлер-плейт под другой бойлер-плейт.
Зачем выносить все в набор ActionView, когда лучше это сделать ввиде сборного паттерна, прикрутив к твоей концепции Компоновщик и строитель какой-нить, и пусть человек сам бахает нужные ему ActionView. А также, на самом деле, при кейсе, когда нужно в зависимости от внешнего стейта обновить ActionView, при вашей реализации мне показалось на первый взгляд, что реактивность может пропасть. Этим ActionView нужно наблюдаемое состояние, чего я не увидел(мож проглядел). В любом случае, я поизучаю исходники повнимательнее и выскажу свой более подробный фидбэк) Может даже пул-реквест кину)
Присоеднюсь к BFS, не стоит использовать Subject, он существует только для 1 цели: соединять императивный стиль с реактивным. По сути, он только для легаси подходит. Поэтому, да, лучше Observable.create(). Для подробностей посмотрите доклад Матвея Малькова — Art Of Rx, учитывая что вы андроид разработчик, вам это будет полезно)
И второй момент, поиск это ровно тот кейс, когда нужно думать о Backpressure, а поскольку практически все сегодня используют Rx2, то там эта проблема решена с помощью Flowable, и лучше этот кейс зарефакторить на него.
Да, спасибо) Я немного неверно описал этот раздел. Лучше вместо того чтобы по быстрому впихивать эту тему, которая получилась неверно раскрыта, написать отдельный материал. Спасибо большое за фидбек)
Ща внесу нотку пессимизма, ну или реализма(эт как расценивать), но был у меня в практике случай, когда у «не самых умных личностей», которые довольно «плохо» писали приложение, нашелся 1 умный товарищ и вынес защиту в нативную библиотеку. Это было конечно не ИДА, но все равно, попытка реверса оказалось провальной, хотя бы потому что никто не захотел лезть в дебри натива…
Спасибо за статью, комментарии честно признаюсь, не прочитал, может быть, кто-то что-то подобное уже высказал, поэтому выскажу субъективное пожелание.
Хотел бы увидеть более полную версию статьи, основанную на дополнительных данных, ввиде:
1. Дополнить данные схемы языками Ruby и Python, хотя бы потому-то что они тоже довольно популярны в виде бэкенда
2. И добавить еще одну ветку сравнений, в виде использования фреймворков. Т.е. как бы было на нативе и на ФВ. Не знаю как вы, но я ооочень редко встречал поддерживаемые велосипедные проекты)) Обычно(самые распрастранненые варианты)
when(lang) {
Java -> Spring
PHP -> Laravel
Python -> Django
Ruby -> Ruby on Rails
NodeJs -> Express.js
}
Было бы любопытно посмотреть на цифры и объективное исследование)
Возможно проглядел, и кто-то упомянул, но еще помимо всего прочего котлин может еще в и жабаскрипт фигачить =)
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
Kotlin + Anko хорош, но тоже не серебряная пуля. Пойдет для небольших «гуешных» элементов — кастомные вьюхи для диалогов, лейауты с 1-3 элементами. В андроиде сейчас constraint layout наконец-то релизнулась, и, на мой взгляд, обещает быть лучше, чем тот же strory board в xcode. Поэтому тут я за него всеми руками ))
Меня немного смущает… Довольно простой пример, и в нем уже такая простыня… а если задачи усложнятся по тем вариантам, которые вы привели?
Один сигнал к нескольким слотам
Несколько сигналов к нескольким слотам
Несколько сигналов к одному слоту
И как мне установить в одном соединении несколько ресиверов? К примеру я создал 3 класса Receiver1. Receiver2, Receiver3 и заимлиментился от Receiveable который реализовал slotReactOnSignal(). Далее, я хочу сделать так:
А если добавить в эту логику внутреннее общение между слотами…
Как мне видится, я полностью согласен с webmasterx все придет к тому, что нужен Rx.
Не хочу сказать, что она бесполезная, я просто не вижу область применений) А не можете дополнить статью еще какими-либо примерами? )) Чтобы ощутить полезность вашей библиотеки) Хотелось бы ее использовать, но где ее юзануть так, чтобы она была прям полезной…
Ну, тут я не согласен. Это попахивает каким-то, извините меня за сравнение, «фашизмом».
Если разделять людей на классы и касты, вешать на них ярлыки и оценивать по возможностям — можно прийти к гитлеровскому подходу — «оставить одних правильных, а всех остальных фтопку!!! ЗИГ ХАЙЛЬ!!!» ))
Все люди разные, у каждого разные возможности и разное мышление. Ровно как и направлений в разработке множество, так почему говорить, что те кто не знает C++ конченные?
Я бы согласился, если бы вы написали именно с таким мнением, что не все могут работать с С\С++, равно как и с ассемблером и вообще даже с аппараткой. Но это не делает их конченными программистами, они просто другие. У меня есть парочку примеров людей, которые виртуозно работают с C++, но как-то решились попробовать себя в веб-разработке и потерпели фиаско, только потому что тут подходы разные. И я думаю многие могут такие примеры привести. Так что называть людей псевдопрограммерами и тем более указывать им на то, что если они не разобрались в указаниях данного «майн кампфа» им надо выйти вон — очень не этично, я бы даже сказал бестактно.
А вот сказать им в таком ключе «Ну вот не получается у вас делать качественные приложения на C\C++, может стоить попробовать себя в другом? Есть много вариантов и альтернатив. И честно говоря, не каждый кто будет прилагать тонну усилий в течение 20 лет станет гуру.» — было бы намного тактичнее, и как сейчас модно говорить, толерантно. У всех разные возможности и способности. Но это не значит что один убогий и его надо сжечь на костре, а другой — опора мира разработки.
Вроде все сказал))
P.S. Извините, пожалуйста, за сравнение с фашизмом и за все, что с ним связано, но я просто не смог найти другого сравнения. Очень мне напомнило именно расистский подход.
Спасибо конечно за статью, но уж сильно жестко и абстрактно вы завернули )) Если целью было напугать юнных дарований, чтобы проверить их желание — думаю у вас получилось )) в остальном — очень абстрактно и субьективно. Больше примеров и полезных советов — и было бы норм ))) не учитывая провакиционный характер статьи, который так и тянет начать холивар ^_^
Что правда, то правда. В последнее время, Fl.ru знатно пополнился крохоборами. А в качестве исполнителей — школота, да голодные студенты. 5 лет назад еще было сносно, хотя тож не особо. Единственный плюс от него был — это периодически относительно нормальные заказы от заков, которые находили меня по каталогу и напрямую выходили на разговор. А по основным заявкам — предложения за доширак.
Ну даже и без конфигов, представим что они все ложные, изучив исходники можно спокойно найти кучу дыр, и повторно положить этот сервис. Так что по логике, необходимо было бы переписать этот сервис с нуля, ИМХО))
Угу. Но есть конфиги, которые я ради праздного любопытства поизучал)) Много интересного) Например «Настройки сервиса бекапа файлов в облачное зранилище», Ключи API, даже логин и пароль к БД, правда без адреса сервера, но это и не суть… в общем, я думаю не особо скоро он заработает, особенно с такой утечкой…
Да пожалуй, такого практически нигде нет. Вообще, идея замечательная, хотя бы потому, что человек, которого ты обучил и дал работу, более лоялен и не задирает нос. Жаль, что такая практика мало применяется. но направление очент правильно.
Ммм… а не подскажите, любезнейший, что вы имели в виду под словосочетанием «тихий ужас»? Я люблю конструктивную критику, и если в ней будет ряд прекрасных замечаний, я соглашусь и поблагодарю. Очень интересно было бы услышать. Заранее спасибо.
Редирект в данном случае случае проще, как мне кажется. Просто при помощи аякса мы получим статус авторизации, и потом нужно проводить какие-то лишние манипуляции с возвращаемым ответом. Просто, как по мне, проще вызвать редирект виджета, и после редиректа произойдет проверка условий, и данные обновятся. Конечно, мне интересно услышать ваше мнение. Может я и вправду ужасно ошибаюсь)
Зачем выносить все в набор ActionView, когда лучше это сделать ввиде сборного паттерна, прикрутив к твоей концепции Компоновщик и строитель какой-нить, и пусть человек сам бахает нужные ему ActionView. А также, на самом деле, при кейсе, когда нужно в зависимости от внешнего стейта обновить ActionView, при вашей реализации мне показалось на первый взгляд, что реактивность может пропасть. Этим ActionView нужно наблюдаемое состояние, чего я не увидел(мож проглядел). В любом случае, я поизучаю исходники повнимательнее и выскажу свой более подробный фидбэк) Может даже пул-реквест кину)
И второй момент, поиск это ровно тот кейс, когда нужно думать о Backpressure, а поскольку практически все сегодня используют Rx2, то там эта проблема решена с помощью Flowable, и лучше этот кейс зарефакторить на него.
Хотел бы увидеть более полную версию статьи, основанную на дополнительных данных, ввиде:
1. Дополнить данные схемы языками Ruby и Python, хотя бы потому-то что они тоже довольно популярны в виде бэкенда
2. И добавить еще одну ветку сравнений, в виде использования фреймворков. Т.е. как бы было на нативе и на ФВ. Не знаю как вы, но я ооочень редко встречал поддерживаемые велосипедные проекты)) Обычно(самые распрастранненые варианты)
Было бы любопытно посмотреть на цифры и объективное исследование)
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
Меня немного смущает… Довольно простой пример, и в нем уже такая простыня… а если задачи усложнятся по тем вариантам, которые вы привели?
И как мне установить в одном соединении несколько ресиверов? К примеру я создал 3 класса Receiver1. Receiver2, Receiver3 и заимлиментился от Receiveable который реализовал slotReactOnSignal(). Далее, я хочу сделать так:
А если добавить в эту логику внутреннее общение между слотами…
Как мне видится, я полностью согласен с webmasterx все придет к тому, что нужен Rx.
Не хочу сказать, что она бесполезная, я просто не вижу область применений) А не можете дополнить статью еще какими-либо примерами? )) Чтобы ощутить полезность вашей библиотеки) Хотелось бы ее использовать, но где ее юзануть так, чтобы она была прям полезной…
Если разделять людей на классы и касты, вешать на них ярлыки и оценивать по возможностям — можно прийти к гитлеровскому подходу — «оставить одних правильных, а всех остальных фтопку!!! ЗИГ ХАЙЛЬ!!!» ))
Все люди разные, у каждого разные возможности и разное мышление. Ровно как и направлений в разработке множество, так почему говорить, что те кто не знает C++ конченные?
Я бы согласился, если бы вы написали именно с таким мнением, что не все могут работать с С\С++, равно как и с ассемблером и вообще даже с аппараткой. Но это не делает их конченными программистами, они просто другие. У меня есть парочку примеров людей, которые виртуозно работают с C++, но как-то решились попробовать себя в веб-разработке и потерпели фиаско, только потому что тут подходы разные. И я думаю многие могут такие примеры привести. Так что называть людей псевдопрограммерами и тем более указывать им на то, что если они не разобрались в указаниях данного «майн кампфа» им надо выйти вон — очень не этично, я бы даже сказал бестактно.
А вот сказать им в таком ключе «Ну вот не получается у вас делать качественные приложения на C\C++, может стоить попробовать себя в другом? Есть много вариантов и альтернатив. И честно говоря, не каждый кто будет прилагать тонну усилий в течение 20 лет станет гуру.» — было бы намного тактичнее, и как сейчас модно говорить, толерантно. У всех разные возможности и способности. Но это не значит что один убогий и его надо сжечь на костре, а другой — опора мира разработки.
Вроде все сказал))
P.S. Извините, пожалуйста, за сравнение с фашизмом и за все, что с ним связано, но я просто не смог найти другого сравнения. Очень мне напомнило именно расистский подход.
Какой-то чудак уже успел загрузить на гитхаб)) Думаю долго там оно не продержится — скоро забанят))