Спасибо!
А как были выбраны победители? Это самые первые несколько человек?
Было бы интересно за сколько они прошли весь тест?
ЗЫ: тест прошел в течении часа после публикации
Вы привязались к примеру со скидкой.
Он не абсолютно удачный, так как можно сказать, что скидка на печеньки — особенность мобильного приложения одного конкретного магазина, при таком взгляде скидка будет в юзкейсе. Так как при переносе Entity на другую платформу, скидку переносить не нужно.
Но если взять пример Jeevuz, в котором скидка на печеньки — некоторая базовая штука (представьте, что это правило всех землян — делать скидку на несколько печенек), то это правило описывается, например, прямо в классе печеньки — и тогда все будет как описано
Я кажется понимаю, что именно у всех вызвало "несварение". Смотрите: Ентити = список полей с данными + набор функций над этими полями.
Там не может быть методов, которые затрагивают другие поля или Ентити.
Никто же не будет выносить метод toString или hashcode в UseCase? В Entity только методы самого объекта, которые одинаковые в независимости от платформы, где используется этот объект.
Например представим метод getShortDescription, который возьмет только первый 20 символов из поля description.
Если эта логика обусловлена бизнесом, то такому методу самое место в Entity.
Если это особенность какой-то логики обединения description из разных Entity — то это будет в интеракторе.
Если это только особенность UI, то это будет в презентере
если открыть третье активити с возможностью закрытия свайпом, то и первое и второе и третье будут активными. и так далее.
Активити создаются заметно дольше фрагментов. Никаких тяжелых операций в них запускать для этого не надо, достаточно взять не самый топовый девайс и можно определять на глаз, где фрагменты, а где активити.
А вообще хорошая статья, кому-то точно поможет разобраться)
Но активити сама по себе как системный класс — тяжелее фрагмента. совсем не здорово, когда в приложении все активити остаются висеть в памяти в активном состоянии.
Плюс при повороте будет создаваться весь стек активити, и это заметно.
Плюс отсутствие вызова онСтоп не позволяет впрямую обработать переход на новый экран (остановить какой-нибудь поллинг) — можно конечно свои методы для этого нагородить.
Я понимаю, что сама задача требует активного предыдущего экрана под текущим, но в хорошей реализации должно быть учтено, что оставаться должен только ОДИН предыдущий экран.
Есть компромиссное решение — делать скриншот экрана, но тут проблем еще больше, ибо довольно часто при переходе назад экран будет уже не соответствовать скриншоту
Инстанс Активити запустился, он отобразил фрагменты.
Активити свернулось, оно теперь не доступно пользователю.
Активити получила данные, она способна их обработать.
Все варианты не вызывают особого диссонанса. Но проголосовал за "Оно"
Игра проходится на одном дыхании! Очень хорошо продуманная атмосфера, которая создается музыкой + картинкой + сюжетом. Будто смотришь или читаешь качественную Научную Фантастику.
Погрешности в разрешении изображения оставляют простор для фантазии.
А наличие нескольких концовок!
Надо еще раз ее пройти!
В итоге имеем статью с завязкой без развязки.
Да и вообще без каких-либо технических подробностей. Только скриншоты с текстом из пейнта.
Сплошное разочарование.
Автор — не молодец
Будет ли у этого приложения длительный жизненный цикл?
Довольно частая ситуация, когда планируется сдать проект и забыть. А потом через пол года заказчик возвращается с новыми фичами.
Достаточно ли стабильны требования? В противном случае вы столкнетесь с бесконечным рефакторингом даже при внесении мелких изменений.
Тут какраз хорошая модульная архитектура очень поможет.
Вы действительно тестируете свои приложения? Будьте честны с собой.
Тестировать надо, то что надо тестировать. Пробросы вызовов тестировать можно только для галочки покрытия тестами. Но в любом, даже очень простом приложении есть немного бизнес логики — вот именно ее и надо проверить и зафиксировать тестами.
Такое впечатление, что автор статьи забыл зачем нужна архитектура.
Еще я бы избавился от неявных зависимостей и вынес весь класс CellType наружу.
А еще вы используете в качестве ViewType id соответствующего лейаута, но тогда теоретически для каждой сборки приложения id будет отличаться. В некоторых случаях это может быть проблемой.
Если кому-то хочется красоты как в Elementary OS, но не нравится их окружение Pantheon, то рекомендую Ubuntu Gnome (либо Fedora, но deb пакеты для убунты проще искать). Gnome Shell очень продуманный в плане консистентного UI. Недавно перешел с Xubuntu, так теперь даже есть желание под GTK, что-то сделать полезное для людей!
Спасибо!
А как были выбраны победители? Это самые первые несколько человек?
Было бы интересно за сколько они прошли весь тест?
ЗЫ: тест прошел в течении часа после публикации
Помню-помню я этот виджет "который позволял поставить на рабочий стол смайлик и подпись" :)
А особенно его запуск со скамейки в ЦПКиО!
Вы привязались к примеру со скидкой.
Он не абсолютно удачный, так как можно сказать, что скидка на печеньки — особенность мобильного приложения одного конкретного магазина, при таком взгляде скидка будет в юзкейсе. Так как при переносе Entity на другую платформу, скидку переносить не нужно.
Но если взять пример Jeevuz, в котором скидка на печеньки — некоторая базовая штука (представьте, что это правило всех землян — делать скидку на несколько печенек), то это правило описывается, например, прямо в классе печеньки — и тогда все будет как описано
ответил ниже
Я кажется понимаю, что именно у всех вызвало "несварение". Смотрите: Ентити = список полей с данными + набор функций над этими полями.
Там не может быть методов, которые затрагивают другие поля или Ентити.
Никто же не будет выносить метод toString или hashcode в UseCase? В Entity только методы самого объекта, которые одинаковые в независимости от платформы, где используется этот объект.
Например представим метод getShortDescription, который возьмет только первый 20 символов из поля description.
если открыть третье активити с возможностью закрытия свайпом, то и первое и второе и третье будут активными. и так далее.
Активити создаются заметно дольше фрагментов. Никаких тяжелых операций в них запускать для этого не надо, достаточно взять не самый топовый девайс и можно определять на глаз, где фрагменты, а где активити.
А вообще хорошая статья, кому-то точно поможет разобраться)
Но активити сама по себе как системный класс — тяжелее фрагмента. совсем не здорово, когда в приложении все активити остаются висеть в памяти в активном состоянии.
Плюс при повороте будет создаваться весь стек активити, и это заметно.
Плюс отсутствие вызова онСтоп не позволяет впрямую обработать переход на новый экран (остановить какой-нибудь поллинг) — можно конечно свои методы для этого нагородить.
Я понимаю, что сама задача требует активного предыдущего экрана под текущим, но в хорошей реализации должно быть учтено, что оставаться должен только ОДИН предыдущий экран.
Есть компромиссное решение — делать скриншот экрана, но тут проблем еще больше, ибо довольно часто при переходе назад экран будет уже не соответствовать скриншоту
Извините, вы о чем?
Да, это была больше шутка, чем серьезный довод.
А статья, я считаю, выше всяких похвал
Инстанс Активити запустился, он отобразил фрагменты.
Активити свернулось, оно теперь не доступно пользователю.
Активити получила данные, она способна их обработать.
Все варианты не вызывают особого диссонанса. Но проголосовал за "Оно"
Так-то он детище компании Arello Mobile в первую очередь в лице senneco и комьюнити, а блог красного_робота запутает любого!
Не надо так :)
Вот тут, кстати, автор говорит об этом:
Видимо запамятовал. Действительно, интернет молчит об альтернативных концовках. Извините)
Для меня это было плюсом! Сам не понимал, почему умираю и все, а когда догадался, то радовался и это было круто
Игра проходится на одном дыхании! Очень хорошо продуманная атмосфера, которая создается музыкой + картинкой + сюжетом. Будто смотришь или читаешь качественную Научную Фантастику.
Погрешности в разрешении изображения оставляют простор для фантазии.
А наличие нескольких концовок!
Надо еще раз ее пройти!
В итоге имеем статью с завязкой без развязки.
Да и вообще без каких-либо технических подробностей. Только скриншоты с текстом из пейнта.
Сплошное разочарование.
Автор — не молодец
Довольно частая ситуация, когда планируется сдать проект и забыть. А потом через пол года заказчик возвращается с новыми фичами.
Тут какраз хорошая модульная архитектура очень поможет.
Тестировать надо, то что надо тестировать. Пробросы вызовов тестировать можно только для галочки покрытия тестами. Но в любом, даже очень простом приложении есть немного бизнес логики — вот именно ее и надо проверить и зафиксировать тестами.
Такое впечатление, что автор статьи забыл зачем нужна архитектура.
Спасибо за статью.
Подход выглядит неплохо.
Смутило, что метод
создает новый холдер, а из названия это совсем неясно. Лучше
Еще я бы избавился от неявных зависимостей и вынес весь класс CellType наружу.
А еще вы используете в качестве ViewType id соответствующего лейаута, но тогда теоретически для каждой сборки приложения id будет отличаться. В некоторых случаях это может быть проблемой.
Если кому-то хочется красоты как в Elementary OS, но не нравится их окружение Pantheon, то рекомендую Ubuntu Gnome (либо Fedora, но deb пакеты для убунты проще искать). Gnome Shell очень продуманный в плане консистентного UI. Недавно перешел с Xubuntu, так теперь даже есть желание под GTK, что-то сделать полезное для людей!