• Rx головного мозга
    0

    Хорошо, конечно, что вы все что-то свое написали, но мне бы просто открыть диалог реактивно)

  • Rx головного мозга
    0

    А какая именно механика переносится из view с таким подходом?

  • Rx головного мозга
    0

    Мне нравится подход реактивного UI начиная от пользовательского действия и заканчивая базой и сетью. На тот момент не было ничего похожего на CoroutinesBinding и они были в бете. Поддержка Flow в Room вроде появилась только под Новый год. Использовать сырой подход без понимания того, кто его будет поддерживать пока не хотелось. Но в общем мы вполне рассматриваем использование Flow как замена Rx на архитектурном уровне, хотя и Rx нас всем устраивает

  • Rx головного мозга
    0

    Да, понимание есть. На самом деле, на мой взгляд, это одна из проблем терминальных состояний в Rx и отличает корутины.
    Сетевые запросы мы делаем через ретрофит и оборачиваем все в ответы в подобный объект


    data class SafeResponse<T> (val data: T?, val exception: Throwable? = null)

    Оборачиваем на уровне интерфейса ретрофита через подобие RxJava2CallAdapter.
    Ошибка тоже пробрасывается в onNext и не приводит к завершению цепочки.
    Из интеракторов тоже частично возвращаем данные в подобном формате.
    И обрабатываем их следующим образом


    fun <T> Observable<SafeResponse<T>>.safeResponseSubscribe(onData: (data: T) -> Unit = {},
                                                              onError: (data: Throwable) -> Unit = {}): Disposable =
            this.subscribe({
                               if (it.data != null) {
                                   onData(it.requireData)
                               } else {
                                   onError(it.requireException)
                               }
                           }, { onError(it) })

    Для Observable<SafeResponse> у нас написаны экстеншены для упрощения работы в таком формате.
    За счет этого объекта и пробрасывания ошибок в onNext мы как раз избегаем такого.

  • Rx головного мозга
    0

    а что мешает в вашем примере использовать стандартный метод вместо кастомного?

  • Rx головного мозга
    0

    На данном подходе у нас приложение написанное с нуля где-то полтора года назад. Тогда еще Flow если и были, то не в стабильном релизе. Если бы сейчас писали с нуля, то возможно подумали бы и о Flow. Но опять же, не видел достойных примеров, в которых можно на архитектурном уровне их использовать. Кажется, что они решают больше локальные чёткие задачи и в принципе не конфликтуют в рамках одного приложения с Rx.

  • Эволюция планировщиков задач
    0

    Задач с такой частой периодичностью у нас нет, поэтому с такой проблемой пока не столкнулись. Вообще, странно, что через AlarmManager он работает как надо, а через WorkManager нет. Возможно, были какие-то баги (alpha все-таки) и в beta поправили? Багов связанных с периодическими задачами у них в issuetracker было достаточно)

  • Эволюция планировщиков задач
    0

    Хороший вопрос. В каких-то случаях у нас есть своя LiveData, которая висит на Appplication, через которую пробрасываются статусы прямо из Worker; в каких-то случаях это менеджеры самописные; бывает мы слушаем результат выполнения Worker через WorkManager.getInstance().getWorkInfoByIdLiveData()

  • Droidcon London. Как это было
    0

    Вроде все доклады есть вот здесь, но там нужно авторизоваться, чтобы смотреть их

  • Нестыдные вопросы про жизненный цикл
    0

    С ViewModel хорошее решение, добавлю его в статью. Спасибо

  • Нестыдные вопросы про жизненный цикл
    0

    Да, если говорить про страницы разного типа (как минимум табы или подобные ui-элементы), то, конечно, ViewPager более удобен. Я же говорил именно про списки в любых их проявлениях

  • Нестыдные вопросы про жизненный цикл
    0

    Да, вы правы про фрагмент. Ситуация именно про поведение с добавлением в бекстэк


    А насчет ViewPager по следующим причинам:
    1) RecycleView гибче — можно экспериментировать со свободным или постраничным скроллом, с вертикальной лентой или горизонтальной, с элементами, которые наезжают друг на друга контролами; экспериментировать с анимациями и расположением элементов.
    2) Иерархия вью в этих элементах очень сложная и хочется все это переиспользовать, настраивать пул для разных типов элементов, также можно прогревать RecycledPool еще до начала использования самой ленты
    3) Из-за наших особенностей хранения данных и структуры этих данных мы хотим очищать списки при уходе в глубину — с ViewPager с такой логикой возникает куча проблем, так как у него фрагменты жестко привязаны к элементам списка и логика восстановления фрагментов очень неочевидная и размазанная между нашей бизнес-логикой хранения данных, методами жизненного цикла и состояниями FragmentManager. Например у ViewPager после onDestroyView могут приходить запросы на создание фрагментов.
    4) Ну и просто лишний слой в виде фрагментов и их жизненного цикла нам показался лишним и без каких-либо преимуществ использования перед RecycleView

  • Есть ли жизнь без архитектуры?
    +2

    И про Сирию в статье тоже не слова. И, если бы не комментатор сверху (зачем вообще гуглить картинки из статей?), то никто бы и не стал так ассоциировать. Если это кому-то показалось лишним, то можно было в лс написать, а не разводить тут дискуссию про политкорректность выставляя это на показ.
    Напоминает серию из South Park "Сhef goes nanners"

  • Есть ли жизнь без архитектуры?
    0

    Activity слишком много умеет, чтобы быть просто View. Поэтому, в нашем случае, там с течением времени скапливалось слишком много логики. В правильном MVC да, так и есть, вы правы.


    А вообще, переиспользование View на других платформах, других приложениях и всем таком это миф. Нет других платформ, в новом приложении проще заново написать, даже в рамках одного приложения чаще проще заново написать, чем с самого начала заниматься оверинжинирингом или потом рефакторить ради пары отличающихся моментов

  • Как подружиться с Realm
    0

    1) При работе с отвязанными объектами теряется их свойство "живых обьектов", теряется возможность выборок удобных из Realm'а и нам показалось, что это дополнительные движения. Но вообще да, мы тоже думали о том, чтобы за пределами репозитория взаимодействовать с отвязанными объектами.


    2) Да там ведь и не БД уже, там прогретый кеш. А пулл потоков это не городить, это группировка по типу операции, вы ведь все равно там на каком-то Sheduler'е их запускаете.

  • Как подружиться с Realm
    0

    1) Как происходит изменение обьекта у вас? Например, есть таблица Parent и вам нужно добавить на него связь с новым Kid (внутри Parent список из Kid). И, если не трудно, расскажите, как вы делаете поиск по спискам. Например нужно достать Kid из Parent по имени.


    2) Закрывать Realm после каждой транзакции довольно расточительно. В вашем случае стоит сделать пулл потоков для работы с Realm'ом и закрывать инстанс после работы потока, а не после транзакции. Да и если делать все операции в фоновом потоке, то это либо callback hell, либо, как вы и сделали, использовать rx. Мы же специально перешли на Realm, чтобы перенести все операции на UI поток.


    3) Да, речь была про цепочку наследования. Но это мелочь.


    4) Тесты ломаются если в ваших модельках есть выборки рилмовские (например для работы со списками), то есть все это приходится уносить из моделей и, в придачу к репозиторию, мокать все классы, которые содержат логику этих выборок. Но да и это тоже решаемо. Только у вас полностью пропадает возможность протестировать вполне важную бизнес логику. В этом случае интеграционные тесты, поднимающие аппликейшен, не очень подходят.

  • Как подружиться с Realm
    0

    вместо Kotlin'а мы выбрали Scala)

  • Как подружиться с Realm
    0

    Возможно, он кидал предупреждения, если поток, на котором он был открыт, перестал работать. Смысла закрывать инстанс на UI потоке мы не увидели. После первого запроса за данными инстанс прогревается и следующие выборки уже в разы быстрее, поэтому мы вообще ушли от асинхронных выборок и все делаем синхронно блокирующим вызовом. А время запроса в другом потоке для нас чуть менее приоритетно, так как это не повлияет на пользователя и графический интерфейс. У нас нет блокирующих пользовательских операций, при любом изменении данных мы сразу же изменяем данные локально и асинхронно создаем джобу в очередь на изменение данных на сервере. Время выполнения этой работы никак не будет влиять на пользователя и заставлять его ждать.


    В своих примерах они закрывают его на Activity.onDestroy(), предполагая, что в рамках этого активити показываются специфичные данные, в меньшей степени используемые в других компонентах. У нас же два активити и пара сервисов, все используют одни и те же наборы данных.


    Насчет разделения на конфигурации. Это оправданно только если обьекты в этих конфигурациях будут независимыми, нам показалось это усложнением и мы отделили в отдельные конфигурации только логирование, статистику и прочую информацию не относящуюся непосредственно к пользователю.

  • Как подружиться с Realm
    0
    fgtmenow Точно сейчас не скажу на сколько увеличился размер апк от Realm'а, но если разбивать на разные архитектуры и тд и тп, то можно уложиться в 1 MB. И, на самом деле, насчет сгенерированного кода и DexCount — либо это заинлайнится, либо вырежется, либо мы бы это написали руками.
  • AOP или как написать свой велосипед для аналитики
    +1
    Картинка к статье намекает, что никаких бенчмарков к решению не прилагается:)
  • Элегантный Builder на Java
    +2
    Задач buider решает много, лично я создаю его для следующих целей
    • На вход конструктору подается большое количество объектов, порядок которых легко перепутать
    • Я хочу сделать все поля класса неизменяемыми, чтобы немного облегчить себе жизнь в многопоточный среде (в идеале это все поля final)
    • В конструкторе происходят какие то действия, которые могут вызвать исключения ( в builder это вынесется в set метод поля) — например на вход подается json и не факт что там есть нужное поле, да и вообще парсить его в конструкторе я считаю некрасиво
    • Еще можно придумать случай когда внутри конструктора меняются стратегиии инициализации полей, тогда можно это вынести в set методы builder'а и еще задавать стратегии


    И пример автора не одну из этих задач не решает
  • Глубокое разочарование или Первый хакатон Правительства Москвы
    –4
    Ну ты согласен с этими высказываниями или нет? Хотелось бы услышать мнение автора о чиновниках.
  • Глубокое разочарование или Первый хакатон Правительства Москвы
    –2
    Чиновники — гниль общества, интеллегенция — двигатель


    А насчёт чиновников — так исторически сложилось, что у нас в чиновники идут интеллектуальные и моральные отбросы общества. Чиновники, например, послевоенной Франции были совсем другими.


    Это одобряешь в комментариях под своей статьей?
  • Глубокое разочарование или Первый хакатон Правительства Москвы
    –1
    В начале статьи написано «субьективное мнение», с моей точки зрения все было нормально.
    И периферией к компу помогли, и в запросах помогли, и отвечали сразу, и призов было больше чем там было написано, те же грамоты от оракл не были запланированы вообще. да и кормили нормально… Может кому и не понравилось, что не было All inclusive, но мы ведь и не отдыхать в Турцию приехали.

    А если лично вы так задеты правительством Москвы, то как минимум IT-форум не то место, где нужно собирать соратников и говорить как все плохо.

  • Глубокое разочарование или Первый хакатон Правительства Москвы
    –5
    Смотрю на все это и не могу не написать.

    Во первых насчет организации. Среди этих организаторов были очень хорошие люди, Не буду перечислять по именам. Но среди жюри были люди, через которых прошли и «Соцкарточка» и «Мамнадзор» и остальные приложения, которыми пользуются тысячи Москвичей. Нам например на каждый вопрос по поводу API отвечали достаточно быстро.

    Во-вторых ну не стоит переходить на личности говоря «Первокурсники из ВШЭ ...».
    Парни в таком возрасте а уже участвуют в таких мероприятиях.

    Насчет доступа к API — можно было заранее подготовиться ко всему этому, получить доступ к API до мероприятия никто не запрещал, все же знали какие данные кому пригодятся.

    Насчет еды это конечно класс. На многих хакатонах и конференциях за участие в них как раз берут вступительный взнос, чтобы кормить участников это время. Грех жаловаться, что вот на бесплатном хакатоне меня видите ли плохо кормили.

    Чиновники — гниль общества, интеллегенция — двигатель

    Не понимаю этот хабр, плохая шутка — человека тут же минусуют, сказать какое все г… — держи кучи плюсов.
  • Новый набор в Школу анализа данных Яндекса и разбор вступительного экзамена
    +2
    Возможно ли узнать проходные баллы после онлайн теста и самого экзамена, для прохода в следующий этап отбора?
  • Умный дом от Samsung представлен на CES 2014
    0
    Ответил не в ту ветку.
  • Умный дом от Samsung представлен на CES 2014
    0
    Ну можно брать по мобильной сети, исходя из вышек связи или использовать Яндекс.Локатор
  • Умный дом от Samsung представлен на CES 2014
    0
    Если можно будет управлять работой бытовой техники удаленно, то по идее приделать ее включение и выключение по GPS координатам телефона — дело пары десятков строчек кода.
  • Умный дом от Samsung представлен на CES 2014
    0
    Гики, повернутые на таких вещах будут покупать подобные системы. Сам бы купил такую:)
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    Да. вы правы насчет единождого создания Random.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    если честно, вменяемый пример использования этого счетчика для сжатия данных я вам не приведу.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    Выбор последовательности и их анализ это я решил не описывать в этой статье, так как и так достаточно объемной она получилась и я хотел просто показать на примере простейших последовательностей, как работает такой вид счетчиков
    Если сообществу интересно то в свободное время могу подробнее рассказать о выборе последовательностей и их анализе.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    +1
    Да, тут с вами согласен, в 80-ые годы эта проблема была более актуальна и сейчас использование такого счетчика по назначению трудно представить.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    8 бит имелось ввиду, что отводится для постоянного хранения, остальное можно вычислить и хранить незачем, то есть, если у вас будет объект «счетчик», то он будет состоять из заголовка объекта и одного 8-битного счетчика.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    +3
    так у вас получается просто используется последовательность i*100, так ведь?
    выбирать последовательность нужно для того чтобы управлять зависимостью точности от максимальной границы счетчика и погрешностей счетчика на разных значениях счетчика( при малых значениях и при больших)
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    мы используем последовательность чтобы перемещать по ней наш счетчик, через 10 000 нам нужно что то близкое к количеству итераций. Через 10 000 нам нужно значение счетчика не 100 а желательно поближе бы к 10 000
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    извините, ответил на ваш комментарий не в ту ветку.
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    вызвать функцию getElementSequence с параметром counter — вернувшееся значение и будет значением самого счетчика
    8-битное значение хранит только номер элемента в последовательности, в которой и находятся наши аппроксимированные значения счетчика
  • Как Роберт Моррис на 8-ми битах до 10 000 считал
    0
    решил его не добавлять так как на самом деле значение counter не о чем не будет говорить, но раз нужно, то добавлю))