Да, вы правы, приложения в большинстве своем не продовые. Это экспериментирование ради создания чего-нибудь необычного. В «Утках» мы хотели соединить вместе Smart TV и мобильные устройства. В «Принцессах» «поженили» Smart TV, мобилы и VR.
Жаль, что вам не понравилось.
Да, это можно сделать, но надо попотеть, специальной реализации нет.
На телевизорах Samsung есть встроенная камера, есть и своя специализированная. У Samsung есть функционал, который позволяет к камере подцепиться и снимать с неё видеопоток.
Проблема в том, что это сработает только со специальными камерами от Samsung, обычную вебку подцепить можно, но приложение заблокирует всплывающее окно, в котором надо согласиться на его использование.
В общем случае платформы стараются блокировать всплывающие окна, но некоторые разрешают. Philips, например
Спасибо за Ваш комментарий. Много думал, для чего же нам в действительности может понадобиться сабкомпонент экрана.
На моей практике он пригождался в случае, когда две зависимости (например адаптер и vhFactory) нуждались в ссылке на друг друга (если adapter реализовывал listener для событий vh). До того, как познакомиться с Lazy, я использовал отложенную инъекцию именно ленивым вызовом inject из адаптера. Ну, а сейчас я, наверно, соглашусь с Вами, функциональной нагрузки хранение сабкомпонента не несёт.
Однако, я бы оставил такую реализацию в статье просто для того, чтобы читатель понял, что за время жизни он отвечает самостоятельно.
Если ваша архитектура подразумевает разделение ui от business-логики, отличным решением будет также разделить ваши Singletone-зависимости на два компонента — ui и business соответственно. С помощью Component dependency предоставляем из ui-компонента business-компоненту только необходимые общие зависимости (например Context) и интерфейсы для взаимодействия с вашими View (если, конечно, вы не используете фреймворки на типо Mosby).
Таким образом вы добьетесь независимости ваших слоёв друг от друга + разграничите их доступ к layer-специфичным зависимостям.
В общем-то, сочетание Dagger с различными архитектурами — это, наверно, тема для отдельной статьи. (Если, конечно, кому-то это будет интересно)
К ListComponent может обращаться не только сам фрагмент, но и другие «участники» уровня данного экрана.
Именно для такого совместного использования мы описали в классе App метод getListComponent().
Например, тому же Adapter'у может понадобиться собственный метод inject() вместо передачи зависимостей в конструктор. В таком случае его вызов будет App.getListComponent().inject(this);
Если же хранить ListComponent во фрагменте, появляется необходимость хранения instance фрагмента,
как статической переменной класса ListFragment, чтобы обеспечить общий доступ. И даже если не углубляться, в то, почему так категорически не стоит делать, наш компонент все равно не разрушится сам, т.к. появляется необходимость занулять instance фрагмента руками.
Цель использования Dagger в рамках данной статьи — это чистота и модульность кода. А уже из этих двух составляющих следуют такие преимущества, как тестируемость, переиспользуемость и т.д.
В немецком слово "Medien" является сокращением от слова "Massenmedien". Слово массмедиа существует даже в русском языке, как транслитерат. Я уверенна, Вы знаете значение слова массмедиа. А то, о чем Вы говорите, немцы называют «digitale Medien». Ну и да, автор считает VR новым СМИ. Вы можете подискутировать с ним на эту тему. Он всегда открыт к общению.
Статья «тыкает», так как автор статьи не хочет дистанцироваться от читателя, в немецком языке, есть разница между обращениями на «ты» и на «Вы», даже соответствующие глаголы есть. Например, "выкать".
Если Вы хотите побольше прочитать о реальных примерах, рекомендую ознакомиться с предыдущей статьей.
Да, это анонс. Прочитав его, Вы можете понять, интересно ли Вам будет тема и решить переходить ли дальше по ссылкам. А первая статья из серии и дополнение к ней уже опубликованы. В скором времени будет публиковать дальше, и все превратиться в полноценную серию.
Если Вы имеете ввиду такую ситуацию: при приближении к стене все становиться темным, а при удалении снова нормальное освещение, то, да, это, по моему мнению, тоже неплохое решение. Все зависит от дизайна и тематики игры/приложения. Вообще всегда можно придумать разные варианты.
Не упомянуты nullability annotations здесь потому, что imho к свойствам они относятся скорее «заодно», чем «в первую очередь». Да еще, рассказывая про них, надо бы и Swift приплетать. Думаю, хорошенько покопавшись, так можно к этой статье еще много чего привязать. Но я уверен, что не стоит все собирать в одном месте, как не стоит писать классы на 70к строк
Спасибо за комментарии. Действительно, сеттер был не примером для подражания. Поправил. С atomic тоже немного уточнил формулировку, но в целом, не совсем понятно, что именно, по Вашему мнению, там неправда. Добавьте и сюда конструктива, пожалуйста, — укажите, с чем именно Вы не согласны.
Если сервер DB хорошо изолирован от доступа откуда не надо, то само по себе хранение логина и пароля к нему в конфиге и затем в системе контроля версий большой проблемы не создаёт.
Но если условие из пункта 1 не выполняется, то чуть ли не любой элемент настроек из web.config можно вынести в отдельный файл через configSource, и этот файл держать локально там, где надо, не загружая его в репозиторий.
Ну, я примерно об этом и писал. Работать для данного проекта оказалось легче в одном русле. Т.е. SoapUI прекрасная программа, но исторически пересекался с ней редко. Отправляясь в экстренное путешествие, когда на сборы немного времени, лучше ориентироваться на конечный результат — качество продукта и время на исправление дефектов, а не на инструмент.
Я не мог точно сказать, сможет ли быстро SoapUI сделать всё, что мне нужно, и смогу ли я сделать это хорошо на нём сразу. А про Jmeter знал, что он мне даст всё, что нужно для данной задачи.
Бывали и обратные примеры в моей практике. Написал скриптик на чем-нибудь, протестировал, а потом подумал «а вот бы тоже самое, но в 50 потоков», и такая библиотечка находилась. А меня спрашивали «А почему не Jmeter для нагрузки?»
Один инструмент в качестве орудия основного предназначения, и он же на костылях для другого, это неправильное решение. Но целесообразное.
С одной стороны всё так. Jmeter инструмент совершенно для другого, но, как ни странно, я не почуствовал никакой тяжести в том, чтобы поддерживать это два месяца и оставить в таком виде, что могу без проблем к этому вернуться.
Jmeter поддерживает видимость значений и переменных в иерархическом виде. Если мне нужно было поменять цель для тестирования с dev на test окружение, я просто редактировал одну единственную переменную в самом корне теста. Были переменные ниже по дереву, были те, которые работали только на уровне тест-кейса или http request
В общей массе кейсы это модификации кейсов, которые уже были, поэтому в 70% случаев кейс за основу для кейса брался другой simple controller в котором уже были созданы пользователи, получены токены для авторизации, созданы какие-то сущности в базе и т.д.
копипаст assertions также не был проблемой. Assertion болванки были правильно настроены как получать из сообщения код ответа, выдрать необходимое значение JSON и т.д. редактирование болванки требовало только подставить значение, или даже оставить так как есть.
С другой стороны такой копипаст требует значительной доли внимания и сосредоточенности.
Наша команда состояла из 6 человек. Со стороны банка было много участников.
На реализацию ушло около года.
Жаль, что вам не понравилось.
На телевизорах Samsung есть встроенная камера, есть и своя специализированная. У Samsung есть функционал, который позволяет к камере подцепиться и снимать с неё видеопоток.
Проблема в том, что это сработает только со специальными камерами от Samsung, обычную вебку подцепить можно, но приложение заблокирует всплывающее окно, в котором надо согласиться на его использование.
В общем случае платформы стараются блокировать всплывающие окна, но некоторые разрешают. Philips, например
На моей практике он пригождался в случае, когда две зависимости (например адаптер и vhFactory) нуждались в ссылке на друг друга (если adapter реализовывал listener для событий vh). До того, как познакомиться с Lazy, я использовал отложенную инъекцию именно ленивым вызовом inject из адаптера. Ну, а сейчас я, наверно, соглашусь с Вами, функциональной нагрузки хранение сабкомпонента не несёт.
Однако, я бы оставил такую реализацию в статье просто для того, чтобы читатель понял, что за время жизни он отвечает самостоятельно.
Еще раз спасибо.
Таким образом вы добьетесь независимости ваших слоёв друг от друга + разграничите их доступ к layer-специфичным зависимостям.
В общем-то, сочетание Dagger с различными архитектурами — это, наверно, тема для отдельной статьи. (Если, конечно, кому-то это будет интересно)
Именно для такого совместного использования мы описали в классе App метод getListComponent().
Например, тому же Adapter'у может понадобиться собственный метод inject() вместо передачи зависимостей в конструктор. В таком случае его вызов будет App.getListComponent().inject(this);
Если же хранить ListComponent во фрагменте, появляется необходимость хранения instance фрагмента,
как статической переменной класса ListFragment, чтобы обеспечить общий доступ. И даже если не углубляться, в то, почему так категорически не стоит делать, наш компонент все равно не разрушится сам, т.к. появляется необходимость занулять instance фрагмента руками.
Статья «тыкает», так как автор статьи не хочет дистанцироваться от читателя, в немецком языке, есть разница между обращениями на «ты» и на «Вы», даже соответствующие глаголы есть. Например, "выкать".
Если Вы хотите побольше прочитать о реальных примерах, рекомендую ознакомиться с предыдущей статьей.
Я не мог точно сказать, сможет ли быстро SoapUI сделать всё, что мне нужно, и смогу ли я сделать это хорошо на нём сразу. А про Jmeter знал, что он мне даст всё, что нужно для данной задачи.
Бывали и обратные примеры в моей практике. Написал скриптик на чем-нибудь, протестировал, а потом подумал «а вот бы тоже самое, но в 50 потоков», и такая библиотечка находилась. А меня спрашивали «А почему не Jmeter для нагрузки?»
Один инструмент в качестве орудия основного предназначения, и он же на костылях для другого, это неправильное решение. Но целесообразное.
С одной стороны всё так. Jmeter инструмент совершенно для другого, но, как ни странно, я не почуствовал никакой тяжести в том, чтобы поддерживать это два месяца и оставить в таком виде, что могу без проблем к этому вернуться.
Jmeter поддерживает видимость значений и переменных в иерархическом виде. Если мне нужно было поменять цель для тестирования с dev на test окружение, я просто редактировал одну единственную переменную в самом корне теста. Были переменные ниже по дереву, были те, которые работали только на уровне тест-кейса или http request
В общей массе кейсы это модификации кейсов, которые уже были, поэтому в 70% случаев кейс за основу для кейса брался другой simple controller в котором уже были созданы пользователи, получены токены для авторизации, созданы какие-то сущности в базе и т.д.
копипаст assertions также не был проблемой. Assertion болванки были правильно настроены как получать из сообщения код ответа, выдрать необходимое значение JSON и т.д. редактирование болванки требовало только подставить значение, или даже оставить так как есть.
С другой стороны такой копипаст требует значительной доли внимания и сосредоточенности.