И ещё есть вопрос. Есть ли какой нибудь аналог e Flow методов LiveData.onActive и LiveData.onInactive? Например я хочу сделать экстеншен для Viewval View.isAttachedToWindowFlow: Flow<Boolean>. И хотелось бы, что бы в момент подписки на этот Flow я мог подписаться на IsAttachedToWindow события View, а при отписке слушателей от Flow, отписаться от IsAttachedToWindow событий View. Или тут надо как то мышление менять?
Подскажите пожалуйста, как можно с помощью SharedFlow реализовать подписку на события в STARTED состоянии Activity? То есть обычно во всех примерах описывается ActivityScope, в котором мы подписываемся на Flow, это просто и удобно. Но мы остаемся подписанными на Flow в течении всего времени жизни Activity, даже когда приложение свернуто. А мне бы хотелось обрабатывать события только когда приложение видно пользователю.
Можно конечно подписаться на Flow в ActivityScope и при получении событий проверять находится ли Activity в состоянии STARTED, но это во-первых костыль, а во-вторых неуниверсальное решение.
То есть хотелось бы иметь возможность подписываться на Flow не в CoroutineScope, а в Flow<CoroutineScope?> или в Flow<Boolean>. То есть что бы была функция Flow<T>.launchIn(scopes: Flow<CoroutineScope>)
В те времена, когда компьютеры делали в клавиатурах, в качестве монитора использовался телевизор, который существовал автономно. Так что можно считать ноутбуки приемниками того формата, т.к. внешний телевизор просто заменился на встроенный экран
Да, конечно, я сам очень рад, что андройд разработка становится современной, код с использованием подобных инструментов более выразительным. Но новичку это все постичь все больше непросто.
А мне кажется, что это все случается, когда конкурс среду джунов вырастает до 250 человек на место. И уже можно, как в том анекдоте, выбросить половину резюме со словами "Неудачники нам не нужны"
А, я подумал, что это уже результат работы, раз большая часть статьи посвящена частичной декодировке изображения. Основной то функционал отображения лоскутов задача простая. Но за BitmapRegionDecoder спасибо, может вспомнится, когда пригодится
Я делал приложение с несколькими десятками экранов на самодельном стеке с версткой в коде. Да, это нестандартно, но если бы меня спросили, какой мне подход ближе, я бы сказал, что этот. Но проблема в том, что после меня это сложно будет поддерживать, так что приходится сдерживать свои велосипедные порывы и пользоваться стандартным инструментарием.
В те времена моя любовь к велосипедостроению не сдерживалась здравым смыслом. И я сделал свои фрагменты ещё до этого SDK, ну и использовать CustomView все таки удобнее, чем фрагмент. Да и вообще, так инкапсуляция куда более ярко выражена получается.
Я делал SDK, для ввода данных карт. Там тоже было несколько экранов: ввод данных карты, 3DS и некоторые другие. И это все замечательно лежало внутри одной View. Да, мне пришлось написать свой велосипед для стека экранов, но это, на мой взгляд, стоило того.
А почему бы просто не сделать Custom View? Программист просто добавляет ваш SDKView к себе в верстку и пользуется. Это создаст меньше ограничений для использования
А разве мне стоит что-то менять? Велосипедостроение по вечерам мне очень хорошо помогает понимать почему авторы библиотек, которыми я пользуюсь на работе, реализовали определенную функцию так, а не иначе, т.к. я прошел этот путь, пока писал свой велосипед.
Нет, я работаю программистом и использую в работе библиотеки. Я говорю про внутреннее стремление к велосипедостроению, а не про фактическое их применение в работе.
А я периодически хожу на собеседования. Там дают тестовые задания. И в них часто использование определенных библиотек обязательно, так что после выполнения тестового я этой библиотекой умею пользоваться, а значит, если библиотека и правда стоящая, то я буду ею и впредь пользоваться.
У Вас по большей части архитектурные вопросы подняты. В моем же случае это не так критично, т.к. в Android сообществе вопрос архитектуры в данный исторический момент почти всегда решается в пользу Clean Architecture, а в маленьких пет проектах архитектура не так важна.
В одной из Ваших статей столкнулся с близкой для меня проблемой строгой типизации и попыткой максимально полно отловить все ошибки ещё на этапе компиляции (одну из своих идей, связанных с этим вопросом описал в комментарии). В Android приложениях много что традиционно описывается через xml (верстка экранов, различные параметры, векторные изображения и многое другое), что часто приводит к падениям уже в Runtime. Использование xml было более-менее оправданно во времена многословной Java, в нынешние же Kotlin'овские времена плюсов в xml для этих целей вообще не вижу, т.к. Kotlin и более краток и типизирован и подсказки лучше работают.
Не в быстродействии (это не критично для пет проекта) и не в минности (не сталкивался с нестабильностью JSON) дело. А в том, что в Java использование рефлексии ограничено тем, что во время компиляции типы всех дженериков чистятся, и нет возможности без плясок с бубном раскодировать JSON в List<User>. Соответственно использование JSON'a накладывает определенные ограничения на передаваемые по сети данные.
Проблема обострилась ещё тем, что я решил использовать для валидации данных и наглядности кода обертки вокруг значений. То есть вместо того, что бы использовать в коде String в качестве логина пользователя, я решил сделать класс-обертку Login, который во-первых проверяет в конструкторе корректность строки логина и дает возможность в дальнейшем уже не переживать по этому поводу, а во-вторых позволяет писать более выразительный код (user: Login выглядит куда понятнее, чем user: String, ведь в этом случае можно подумать, что в поле user хранится не логин, а какой нибудь другой идентификатор пользователя). Такую же обертку я сделал и для пароля. А потом оказалось, что для параметра серверного метода login совершенно не нужно писать свой класс (Обычно такие POJO классы называются LoginParam и содержат два поля: login: String и password: String), а можно просто использовать Pair из Kotlin'а: Pair<Login, Password>. Но такая конструкция совсем уже была неудобна для JSON сериализации через рефлексию. А компактность Kotlin кода позволяет весьма аккуратно сделать бинарную сериализацию.
И ещё есть вопрос. Есть ли какой нибудь аналог e
FlowметодовLiveData.onActiveиLiveData.onInactive? Например я хочу сделать экстеншен дляViewval View.isAttachedToWindowFlow: Flow<Boolean>. И хотелось бы, что бы в момент подписки на этотFlowя мог подписаться наIsAttachedToWindowсобытияView, а при отписке слушателей отFlow, отписаться отIsAttachedToWindowсобытийView. Или тут надо как то мышление менять?Подскажите пожалуйста, как можно с помощью
SharedFlowреализовать подписку на события вSTARTEDсостоянии Activity? То есть обычно во всех примерах описываетсяActivityScope, в котором мы подписываемся наFlow, это просто и удобно. Но мы остаемся подписанными наFlowв течении всего времени жизниActivity, даже когда приложение свернуто. А мне бы хотелось обрабатывать события только когда приложение видно пользователю.Можно конечно подписаться на
FlowвActivityScopeи при получении событий проверять находится лиActivityв состоянииSTARTED, но это во-первых костыль, а во-вторых неуниверсальное решение.То есть хотелось бы иметь возможность подписываться на
Flowне вCoroutineScope, а вFlow<CoroutineScope?>или вFlow<Boolean>. То есть что бы была функцияFlow<T>.launchIn(scopes: Flow<CoroutineScope>)А как с таким цельнометаллическим корпусом работают WiFi и Bluetooth?
В те времена, когда компьютеры делали в клавиатурах, в качестве монитора использовался телевизор, который существовал автономно. Так что можно считать ноутбуки приемниками того формата, т.к. внешний телевизор просто заменился на встроенный экран
А почему Jailbreak ассоциируется с поломкой ракеты? Разве iOS становится хуже после него?
Да, конечно, я сам очень рад, что андройд разработка становится современной, код с использованием подобных инструментов более выразительным. Но новичку это все постичь все больше непросто.
Порог входа в андройд разработку неуклонно растет. Теперь что бы просто пользоваться Preferences уже нужно знать корутины.
А мне кажется, что это все случается, когда конкурс среду джунов вырастает до 250 человек на место. И уже можно, как в том анекдоте, выбросить половину резюме со словами "Неудачники нам не нужны"
А, я подумал, что это уже результат работы, раз большая часть статьи посвящена частичной декодировке изображения. Основной то функционал отображения лоскутов задача простая. Но за BitmapRegionDecoder спасибо, может вспомнится, когда пригодится
А почему бы не нарезать на лоскуты картинки уже на бакэнде, если вы его контролируете?
Я делал приложение с несколькими десятками экранов на самодельном стеке с версткой в коде. Да, это нестандартно, но если бы меня спросили, какой мне подход ближе, я бы сказал, что этот. Но проблема в том, что после меня это сложно будет поддерживать, так что приходится сдерживать свои велосипедные порывы и пользоваться стандартным инструментарием.
Ну снаружи это просто View, добавляется в верстку, а потом уже в коде добавляется колбэк на добавление карты
В те времена моя любовь к велосипедостроению не сдерживалась здравым смыслом. И я сделал свои фрагменты ещё до этого SDK, ну и использовать CustomView все таки удобнее, чем фрагмент. Да и вообще, так инкапсуляция куда более ярко выражена получается.
Я делал SDK, для ввода данных карт. Там тоже было несколько экранов: ввод данных карты, 3DS и некоторые другие. И это все замечательно лежало внутри одной View. Да, мне пришлось написать свой велосипед для стека экранов, но это, на мой взгляд, стоило того.
А почему бы просто не сделать Custom View? Программист просто добавляет ваш SDKView к себе в верстку и пользуется. Это создаст меньше ограничений для использования
А разве мне стоит что-то менять? Велосипедостроение по вечерам мне очень хорошо помогает понимать почему авторы библиотек, которыми я пользуюсь на работе, реализовали определенную функцию так, а не иначе, т.к. я прошел этот путь, пока писал свой велосипед.
Нет, я работаю программистом и использую в работе библиотеки. Я говорю про внутреннее стремление к велосипедостроению, а не про фактическое их применение в работе.
А я периодически хожу на собеседования. Там дают тестовые задания. И в них часто использование определенных библиотек обязательно, так что после выполнения тестового я этой библиотекой умею пользоваться, а значит, если библиотека и правда стоящая, то я буду ею и впредь пользоваться.
У Вас по большей части архитектурные вопросы подняты. В моем же случае это не так критично, т.к. в Android сообществе вопрос архитектуры в данный исторический момент почти всегда решается в пользу Clean Architecture, а в маленьких пет проектах архитектура не так важна.
В одной из Ваших статей столкнулся с близкой для меня проблемой строгой типизации и попыткой максимально полно отловить все ошибки ещё на этапе компиляции (одну из своих идей, связанных с этим вопросом описал в комментарии). В Android приложениях много что традиционно описывается через xml (верстка экранов, различные параметры, векторные изображения и многое другое), что часто приводит к падениям уже в Runtime. Использование xml было более-менее оправданно во времена многословной Java, в нынешние же Kotlin'овские времена плюсов в xml для этих целей вообще не вижу, т.к. Kotlin и более краток и типизирован и подсказки лучше работают.
Не в быстродействии (это не критично для пет проекта) и не в минности (не сталкивался с нестабильностью JSON) дело. А в том, что в Java использование рефлексии ограничено тем, что во время компиляции типы всех дженериков чистятся, и нет возможности без плясок с бубном раскодировать JSON в
List<User>. Соответственно использование JSON'a накладывает определенные ограничения на передаваемые по сети данные.Проблема обострилась ещё тем, что я решил использовать для валидации данных и наглядности кода обертки вокруг значений. То есть вместо того, что бы использовать в коде
Stringв качестве логина пользователя, я решил сделать класс-оберткуLogin, который во-первых проверяет в конструкторе корректность строки логина и дает возможность в дальнейшем уже не переживать по этому поводу, а во-вторых позволяет писать более выразительный код (user: Loginвыглядит куда понятнее, чемuser: String, ведь в этом случае можно подумать, что в полеuserхранится не логин, а какой нибудь другой идентификатор пользователя). Такую же обертку я сделал и для пароля. А потом оказалось, что для параметра серверного метода login совершенно не нужно писать свой класс (Обычно такие POJO классы называются LoginParam и содержат два поля:login: Stringиpassword: String), а можно просто использоватьPairиз Kotlin'а:Pair<Login, Password>. Но такая конструкция совсем уже была неудобна для JSON сериализации через рефлексию. А компактность Kotlin кода позволяет весьма аккуратно сделать бинарную сериализацию.