websockets вообще не про экономию батарей. Все что будет сэкономлено на трафике, будет с успехом потеряно на поддержании соединения. При использовании http/2 валидных кейсов для ws очень мало (stateful сервер только, наверное) - разрабатывать это дело тоже сложнее.
В коммерческих проектах чаще всего не ООП непреложная данность, а фантазии на тему - типа папка Controllers и условные IOrderService. Так и сейчас от фп используют условные лямбды да вариации на тему Future 🤷♂️
Цель этого урока — дать непрофессиональным программистам краткий обзор особенностей современного оборудования, которые нужно понимать, чтобы писать быстрый код.
да и многим «профессиональным» тоже не мешало бы прочитать…
1) субъективно легче использовать, больше функций из коробки, более легкая обработка слияний потоков (разные варианты — flatMap, switchMap, concatMap, предлагающие разные варианты на все случаи жизни)
2) сходное API в разных языках (ну и можно один и тот же код шарить между клиентом и сервером, например)
3) стримы как будто бы больше ориентированы на работу с потоками данных, всякие кодировки, буферы и т.д. Rx же — потоками событий/состояний системы (в качестве входного потока можно использовать например setInterval). Хорошо стакается, например, с Redux
Давайте на примере. У вас строка поиска, которая должна предлагать варианты автозаполнения, подгруженные с сервака. Наивная имплементация делается просто — при изменении строки делать запрос, возвращать результат через колбек/Promise/Task/что-там-awaitable-в-вашем-языке.
Теперь несколько моментов (допустим набираю habr):
не хочется дергать запрос на каждый новую букву, нужен какой-то debounce (искать по habr, не по h,ha,hab,habr)
не хочется дергать сервер совсем, если человек вбил букву, понял, что ошибся и удалил ее
порядок выполнения — что если я делаю два запроса и второй выполняется до того как выполнился первый
если хочется немного разгрузить сервис, можно добавить поддержку отмены запроса. Например, вбил 'h', запрос пошел, долго думает, вбил 'ha', abort первого запроса, второй запрос пошел, умный сервер может прибить первый запрос в базу и не отдавать ответ в никуда (CancellationToken в .NET).
ну вот некая западная компания en.wikipedia.org/wiki/Futurice рекламировала себя на .NEXT, что у них, дескать, прозрачность и у всех сотрудников полный доступ ко всей финансовой информации. Чисто для примера, за достоверность и работоспособность не отвечаю :)
синтаксис TS то не ужасен, это просто я криво выразился :) Ужасно различное количество доп. плясок вокруг всего этого для создания врапперов — http://docs.nativescript.org/plugins/ui-plugin
Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.
PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Вот знаете, абсолютно нет ощущения, что NativeScript в самом расцвете, скорее на стадии отчаянной альфы. Рассматривали тут месяца два назад — проблемы с документацией (точнее примерами на гитхабе — не все даже компилируется/работает, а Telerik и не в курсе). Проблемы с количеством существующих компонентов (ну вот карт, например, не было). Можно да, написать свою собственную обертку. И над iOS, и над Android. Ужасным синтаксисом. Только вот не вижу тут тогда никакой выгоды.
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
о, ComponentSpace, поделие крисумрачных гениев… требование наличия сессии (причем есть класс типа InMemoryStorage, который!!! все-равно зависит на модуль сессии потому что SessionId с базового класса у них на него зависит), привязка намертво к HttpContext, отсутсвие поддержки Owin, чего еще бы вспомнить — в общем, надеюсь, что откажемся скоро… — пока написан кастомный HttpModule, в котором вся логика работы.
PS: вам бы тоже не рекоммендовал заигрываться с фасадами и HttpContext'ами, не тестируемо же, да и на конкретный synchronization context завязываетесь.
из документации сложилось впечатление, что @a/b бесплатен, но кто угодно может @a/c создать, а так можно и права на @a раздавать, как на чтение, так и на запись. Сам не пробовал — у нас просто свой собственный registry. Гитхаб это все-таки немножко не то — разница, например, в версионности.
websockets вообще не про экономию батарей. Все что будет сэкономлено на трафике, будет с успехом потеряно на поддержании соединения. При использовании http/2 валидных кейсов для ws очень мало (stateful сервер только, наверное) - разрабатывать это дело тоже сложнее.
В коммерческих проектах чаще всего не ООП непреложная данность, а фантазии на тему - типа папка Controllers и условные IOrderService. Так и сейчас от фп используют условные лямбды да вариации на тему Future 🤷♂️
да и многим «профессиональным» тоже не мешало бы прочитать…
2) сходное API в разных языках (ну и можно один и тот же код шарить между клиентом и сервером, например)
3) стримы как будто бы больше ориентированы на работу с потоками данных, всякие кодировки, буферы и т.д. Rx же — потоками событий/состояний системы (в качестве входного потока можно использовать например setInterval). Хорошо стакается, например, с Redux
Давайте на примере. У вас строка поиска, которая должна предлагать варианты автозаполнения, подгруженные с сервака. Наивная имплементация делается просто — при изменении строки делать запрос, возвращать результат через колбек/Promise/Task/что-там-awaitable-в-вашем-языке.
Теперь несколько моментов (допустим набираю habr):
Решение на Rx (в JS):
Я плохо знаком с питоном, можеть быть у вас там еще красивее это решается. Пример скорее про async/await в JS или .NET
Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.
PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
крисумрачных гениев… требование наличия сессии (причем есть класс типа InMemoryStorage, который!!! все-равно зависит на модуль сессии потому что SessionId с базового класса у них на него зависит), привязка намертво к HttpContext, отсутсвие поддержки Owin, чего еще бы вспомнить — в общем, надеюсь, что откажемся скоро… — пока написан кастомный HttpModule, в котором вся логика работы.PS: вам бы тоже не рекоммендовал заигрываться с фасадами и HttpContext'ами, не тестируемо же, да и на конкретный synchronization context завязываетесь.