В сравнении реализации списков какая-то не полная картина:
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.
Мне почему-то кажется что прав kpcb.
subscribeOn указывает поток в котором будет происходить подписка. И во время подписки вы создаете слушатель.
Слушатель в UI потоке будет дергать subject.onNext(). и возвращаемый observable будет тоже получать событие в UI потоке.
Но дальше у вас идет метод debounce. Это особенный метод, который возвращает observable, события которого будут производиться в computation sheduler. (Scheduler можно изменить — посмотрите перегрузку метода debounce).
Код становится более тестируемым. В действительности, нам даже не нужны Instrumentation-тесты, т.к. достаточно протестировать презентер и убедиться, что после каждой операции наш LoginState имеет правильный набор данных
У вас в примере очень необычный тест: вы вызываете login(), а потом сами же в тесте processLoginResult.
Т.е. если вы забудете реализовать функцию login — то тест все равно будет проходить. Это нормально?
Поэтому у меня вопрос — так а как именно дождаться в тесте когда ваш стэйт обновится (если это обновление асинхронное)?
Как с LiveData обрабатывать и показывать ошибки? Заводить отдельный объект LiveData для хранения последних ошибок? И так для каждого действия на экране?
Тот же самый вопрос и про успешное выполнение какого-либо действия, например, сохранение данных.
Проблему с поворотом Activity более менее я понял как LiveData решает. А что с убийством Activity при сворачивании приложения?
В 13 пункте имеется ввиду все же фрагментация, а не фрагменты.
По поводу 1 пункта, выскажу, возможно, не популярное мнение, но по-моему оно имеет смысл. Если вы только начинаете программировать и пишете приложение «для себя», то, наоборот, постарайтесь не использовать библиотек. Используйте для запросов UrlConnection, парсите json стандартным api андроида, напишите свою «вьюху», вместо того, что бы спереть ее с Android Arsenal. Изобретите свой MVP, orm.
И только потом начинайте использовать библиотеки. В этом случае, при использовании библиотек будет намного проще найти причину, по которой что-то идет не так.
Да, пакет base.
Можно раскладывать так, что в одном пакете может быть только 1 view (+ его fragment, presenter). Если в каком-то фрагменте могут содержаться другие фрагменты, то каждый из дочерних фрагментов (+ его view, presenter) лежит в пакете одного уровня с первым фрагментом. Т.е. группировать не по «темам», а по конкретным вьюхам.
Так ли нужна концепция разнесения классов по пакетам в соответствии с тем, чем является тот или иной класс? Т.е. вот в вашем примере, не проще ли положить CarView, CarPresenter, CarActivity в один пакет car. Ведь чаще всего их редактировать нужно вместе. Я понимаю, что есть рекомендации гугла по именованию пакетов, да и вообще «всегда так было». Но если бы их не было, то как ответите на мой вопрос?
bugs.chromium.org/p/chromium/issues/detail?id=170880
Тестирования в двух компаниях где я работал стабильно находило этот баг:(
К сожалению, они могут быть достаточно популярны. Что делать в этом случае?
Про версию системы я не корректно выразился. Я хотел узнать про версию Android\ios. Слышал, что на 4 Android может лагать.
Сам я на эмуляторе с 8 Android, на ios симуляторах, на реальном устройстве с 8 Android лагов не встречал даже на дебажной сборке.
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.
subscribeOn указывает поток в котором будет происходить подписка. И во время подписки вы создаете слушатель.
Слушатель в UI потоке будет дергать subject.onNext(). и возвращаемый observable будет тоже получать событие в UI потоке.
Но дальше у вас идет метод debounce. Это особенный метод, который возвращает observable, события которого будут производиться в computation sheduler. (Scheduler можно изменить — посмотрите перегрузку метода debounce).
У вас в примере очень необычный тест: вы вызываете login(), а потом сами же в тесте processLoginResult.
Т.е. если вы забудете реализовать функцию login — то тест все равно будет проходить. Это нормально?
Поэтому у меня вопрос — так а как именно дождаться в тесте когда ваш стэйт обновится (если это обновление асинхронное)?
Тот же самый вопрос и про успешное выполнение какого-либо действия, например, сохранение данных.
Проблему с поворотом Activity более менее я понял как LiveData решает. А что с убийством Activity при сворачивании приложения?
По поводу 1 пункта, выскажу, возможно, не популярное мнение, но по-моему оно имеет смысл. Если вы только начинаете программировать и пишете приложение «для себя», то, наоборот, постарайтесь не использовать библиотек. Используйте для запросов UrlConnection, парсите json стандартным api андроида, напишите свою «вьюху», вместо того, что бы спереть ее с Android Arsenal. Изобретите свой MVP, orm.
И только потом начинайте использовать библиотеки. В этом случае, при использовании библиотек будет намного проще найти причину, по которой что-то идет не так.
it.extensions в данном примере действительно избыточен, он полезен тогда, когда необходимо указать тип добавляемого расширения.
Можно раскладывать так, что в одном пакете может быть только 1 view (+ его fragment, presenter). Если в каком-то фрагменте могут содержаться другие фрагменты, то каждый из дочерних фрагментов (+ его view, presenter) лежит в пакете одного уровня с первым фрагментом. Т.е. группировать не по «темам», а по конкретным вьюхам.