• RxJava в Android - все таки "мода" или "острая необходимость"?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    ГЛАВНЫЙ КОЗЫРЬ RxJava: УДОБСТВО КОДИРОВАНИЯ и ЭКОНОМИЯ ВРЕМЕНИ НА РАЗРАБОТКУ и как следствие чуть ли ни мгновенный выпуск продукта в паблик.
    МИНУС: доп. время на исполнение, т.к. это "прослойка".

    А теперь, про остальное:
    Если кратко: почему для простых операций ГРАМОТНЫЕ КОДЕРЫ не подключают jquery, а пишут на нативном javascript'e? Чтобы обеспечить приложению более высокую производительность.

    RxJava - это как бы тот же jquery (или фреймворк), т.е. еще одна "прослойка" уменьшающая время разработки и упрощающая процесс написания кода для кодеров, НО!!! в разы увеличивающая время исполнения и требования к "железу".

    RxJava в Android — все таки «мода» или «острая необходимость»?
    это фреймворк-"времянка", PR-я который можно на какое-то время удержать мобильный рынок разработчиков (выиграть время для выпуска замены) на данной платформе.

    Действительно, Google понимает, что отношение показателя рынка разработчиков к производительности готовых приложений у него: 80/20, в то время как у других: 20/80 (Nokia та же) и что скоро Google скорее всего поменяет язык разработки на свой (и всю парадигму в целом), в ином случае - они будут не конкурентно способны. Но пока они это делают - они будут молчать. Скорее всего они перейдут на javascript с нативным "движком" на ядре ОС.

    Линки:
    1. В 4-х частях перевод о RxJava для разработки под A...
    2. Что ожидать от использования javascript в 2016 год...
    Ответ написан
  • RxJava в Android - все таки "мода" или "острая необходимость"?

    zagayevskiy
    @zagayevskiy Куратор тега Java
    Android developer at Yandex
    Это удобно. Причин множество, читайте в интернетах.
    Справлялись, например, лоадерами, асинктасками, и прочими велосипедами.
    Асинхронно сходить в базу, например.
    Гугл не молчит: https://github.com/google/agera
    Во многих смартфонах уже 4-8 ядер, а юзать их без Rx довольно неудобно.
    Rx не призван решать описанные вами проблемы.
    Поверх есть всяческие RxBindings, используя их, можно легко уходить от императивного к реактивному.
    В iOS, в общем, есть RxSwift. Но вообще-то сравнивать платформы так некорректно.
    Ответ написан
    8 комментариев
  • RxJava в Android - все таки "мода" или "острая необходимость"?

    Rou1997
    @Rou1997
    "1. Почему никто толком не может объяснить, зачем rx в Android-е?"
    Потому что им сказали - надо использовать, они используют, им не объясняли, и они не дошли до этого сами, поэтому не понимают, и вам объяснить не могут.
    Видимо, это одна из проблем "умных книжек", их авторы доносят до читателя мысль, но не заботятся об ее объяснении, вот и получаются "зомби", бездумно скандирующие лозунги.
    А вы - дойдите. Сравните с ним и без него, подумайте, для каких задач он хорошо подходит.
    Используйте это в своей работе, и другим потом объясняйте.

    "2. Неужели Android SDK так убог, что нет альтернатив?"
    Очень убог, был бы у вас шире кругозор, вы бы просто поражались с него.

    "Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть?"
    Как это не должно быть? Скорее - наоборот, любой качественный UI должен быть асинхронным, то есть все тяжелые операции - в потоке, отдельном от UI.

    "классические проблемы Android разработки"
    По мне, основная проблема разработки под Android - это то, что пишешь много, а делаешь мало (как девиз jQuery, только наоборот). Библиотеки очень многословны, IDE - не заточены под Rapid Application Development.
    Может быть, Rx частично решает эту проблему в некоторых случаях?
    Ответ написан
    2 комментария
  • Как эффективнее всего передать объект из IntentService в Activity?

    MaxF
    @MaxF
    Андроид-разработчик
    Вообще уже наверное классика - это EventBus.
    Однако, если вы не хотите подключать лишние библиотеки, то рекомендую вам посмотреть в сторону AsyncLoader вместо сервиса. Вам ведь не нужно чтобы запрос шел, если приложение убито. Зато взамен получите удобное получение результатов асинхронного запроса.
    Ответ написан
    3 комментария
  • Зачем изучать java.util.concurrent, если пишешь под Android?

    @onepavel
    Консультация и разработка мобильных приложений
    1 BlockingQueue музыкальный плеер, есть очередь откуда проигрываются треки, плеер снизу забирает трек, сверху пользователь накидывает в очередь новые треки. работа с очередью идет из разных потоков.
    2 качалка файлов, очередь файлов для закачки, настройками могу регулировать кол-во одновременно качающих потоков
    3 CountDownLatch отличный инструмент для отсчета оставшегося времени
    4 CyclicBarrier чумовой механизм ожидания завершения работы нескольких потоков, парсинг сайта,
    закачка файлов, обработка текстов, подсчет данных или игр
    5 Executors и ExecutorService быстрая организация пула потоков использую для работы с sqlite,
    а также ScheduledExecutorService для организации таймера для проверки изменения чего либо у пользователя на девайсе
    6 полезная штука Exchanger, моментальная реализация задачи producer - consumer
    7 ConcurrentHashMap вообще классика для организации хешей, это сейчас есть LRU, а раньше не было. А было WeakReference и эксперементы с очередями и хешами WeakHashMap
    8 Atomic, легко позволяют создавать потоко-безопасные переменные, использовал AtomicBoolean, как межпотоковый стейт
    Я знаю, что есть конторы, как крупные так и мелкие не используют Retrofitы robospicы DI фреймвори и так далее.
    Учитывая проблемы с 65к dex, из-за тучи либ сторонних и особенно play services, собрать уже сложно.
    И для мелкой задачи стоит ли с собой тащить либу, вопрос холиваный
    И стоит знать java.util.concurrent потому что, это используется в либах. Тот же volley, там три чистых потока Thread для выполнения http, а в ui пробрасывается через хендлер и Executor
    Ответ написан
    5 комментариев