Бесплатно только посмотреть видео можно. Все практические задания только при оплате.
Заходите на страницу отдельного курса, а не специализации. При нажатии на кнопку «зарегистрироваться» в попапе большими буквами будут рассказывать про триал 7 дней и 49 долларов в месяц после него (кстати раньше была цена за курс а не месяц), но в самом низу мелкими буквами написано «или прослушать».
Меня в свое время очень увлекла игра Kula World на Playstation 1. Суть в том что нужно катить мяч до выхода не просто в плоскости, а во всем 3д пространстве. Нужно хорошо представлять что случится если все перевернется вверх ногами или станет на бок. Пространственное мышление хорошо развивает. www.youtube.com/watch?v=NnBffhECImo
Возможно аналогия не совсем уместная, но мне вспомнилась история с уничтожением воробьев в Китае. При нарушении пищевой цепочки могут быть абсолютно не прогнозируемые человеком последствия.
По итогу я получил то что у меня разные приложения используют один и тот же функционал и мне не нужно следить в каком приложении более актуальная версия кода. И большая часть приложений содержит build.gradle в котором все настройки заменены на использование плагинов. Что так же не мало важно для меня, потому то они однотипные и вся их базовая функциональность реализована в отдельной библиотеке.
Если интересует что я выносил в компоненты, то это работа с внутренним API, работа с хардварными устройствами (принтеры, сканеры и т.д.) ну и действительно пакет util, с разными вспомогательными классами.
На сколько я понял вы предлагаете работать в одном проекте, и использовать разные модули, т.е. в таком случае предполагается модуль util и зависимость на него compile ':util'? Но это не рабочий вариант если есть много приложений (в моем случае > 10). Я даже не представляю как будет тормозить у меня студия собирая приложение.
А по поводу зависимостей самих компонентов, то никто не мешает создать pom.xml с правильным dependencies.
А можно поподробней про антипаттерны? Мне кажется вы сами себе противоречите в первом и втором пункте. В моих примерах предполагается что модули независимы. Если необходимо подключить какой-то свой модуль, который зависит от чего то еще это всегда можно дописать в pom.xml, придется немного поправить проект.
А по поводу пункта 3, то каждый отдельный модуль можно релизить независимо. Для каждого автоматически создается отдельная задача, я это все описал в статье.
Это сделано как пример. В моем случае есть больше пяти приложений, с одинаковыми версиями, поэтому я вынес общие параметры в плагин. Если у вас всего два приложения с разными параметрами, то смысла использовать плагины конечно нет.
Можно еще как вариант немного переписать плагин и добавить возможность переопределять параметры, в примере с плагином для публикации я добавил несколько таких параметров.
А если еще вспомнить статью про использование на орбите 3d принтеров. Взять бы этот мусор и «переплавить» его на материал для печати. Не отходя от кассы так сказать.
Подскажите новичку, для чего служит дополнительная верхняя плата? И еще каким образом можно увеличить количество входов/выходов? Просто имеется плата Arduino Uno и при подключении, например, 4х-секционного цифрового блока все цифровые входы заняты, а хочется еще что то подключить.
По своему опыту могу сказать что кроме необходимости запретить пользователю влазить в какие либо настройки или закрывать приложение, есть еще необходимость в автоматическом обновлении. Вначале разработки я надеялся что можно обойтись без рута, но в итоге пришел к выводу что без рута полноценное kiosk-приложение не получится.
Учитывая что устройства одинаковые, то получение рута не такая уж и проблема. Клиент не может купить, например, какой то планшет и поставить на него наше приложение, т.е. по факту мы выбираем устройство.
Я так же переписывался с одним разработчиком, тоже занимающимся kioskMode приложениями (кстати там есть толковые статьи по этому вопросу). Так вот они разрабатывали kiosk-приложение для такси (я так понял в Индии), в каждое такси вставлялся какой то китайский планшет и пассажиры могли что то там делать с их приложением. Опять таки учитывая что устройства везде одинаковое, они получали рут на каждом планшете и спокойно могли делать все что хотели. Только в их случае они для заказчика сделали скрипт, который получает рут на планшете, чтобы он сам мог без участия разработчиков устанавливать новые планшеты.
Так что я склоняюсь к такому подходу. Если же устройств много и пользователи сами могут установить себе приложение, тогда такой вариант не пройдет конечно.
1. Спасибо, не знал.
2. Да, действительно использовать wrapper гораздо проще и удобней, спасибо за подсказку. Не стал описывать как настроить, просто добавил в статью ссылку на видео, поясняющее его настройку, там все просто.
3. На сколько я понял flavors позволяет указать другой пакет приложения, т.е. это отлично подходит для различных версий приложений, например, платная и бесплатная версии. Либо, я так понимаю, необходимо использовать gradle структуру проекта, где у каждого варианта будет своя папка res, я пока не готов перейти к этому, ждем stable версию AndroidStudio.
Вот интересно что они будут делать с распознаванием лиц? Google всячески блокирует такое ПО для google glass, а тут в ролике прям как достоинство показывают.
Если открыть изображения, которые вы используете для фона, в программе draw9patch и выбрать show bad patches, можно увидеть что они (bad patches) присутствуют. Чтобы от них избавится, достаточно слева и сверху указать всего по одному пикселю, вместо полоски на всю ширину/высоту. Вот у меня вопрос, на сколько плохо когда в используемых 9 patch изображениях есть эти bad patches и влияет ли это на скорость отрисовки?
Заходите на страницу отдельного курса, а не специализации. При нажатии на кнопку «зарегистрироваться» в попапе большими буквами будут рассказывать про триал 7 дней и 49 долларов в месяц после него (кстати раньше была цена за курс а не месяц), но в самом низу мелкими буквами написано «или прослушать».
www.youtube.com/watch?v=NnBffhECImo
(тут больше подробностей, но на английском)
Если интересует что я выносил в компоненты, то это работа с внутренним API, работа с хардварными устройствами (принтеры, сканеры и т.д.) ну и действительно пакет util, с разными вспомогательными классами.
На сколько я понял вы предлагаете работать в одном проекте, и использовать разные модули, т.е. в таком случае предполагается модуль util и зависимость на него compile ':util'? Но это не рабочий вариант если есть много приложений (в моем случае > 10). Я даже не представляю как будет тормозить у меня студия собирая приложение.
А по поводу зависимостей самих компонентов, то никто не мешает создать pom.xml с правильным dependencies.
А по поводу пункта 3, то каждый отдельный модуль можно релизить независимо. Для каждого автоматически создается отдельная задача, я это все описал в статье.
Можно еще как вариант немного переписать плагин и добавить возможность переопределять параметры, в примере с плагином для публикации я добавил несколько таких параметров.
Учитывая что устройства одинаковые, то получение рута не такая уж и проблема. Клиент не может купить, например, какой то планшет и поставить на него наше приложение, т.е. по факту мы выбираем устройство.
Я так же переписывался с одним разработчиком, тоже занимающимся kioskMode приложениями (кстати там есть толковые статьи по этому вопросу). Так вот они разрабатывали kiosk-приложение для такси (я так понял в Индии), в каждое такси вставлялся какой то китайский планшет и пассажиры могли что то там делать с их приложением. Опять таки учитывая что устройства везде одинаковое, они получали рут на каждом планшете и спокойно могли делать все что хотели. Только в их случае они для заказчика сделали скрипт, который получает рут на планшете, чтобы он сам мог без участия разработчиков устанавливать новые планшеты.
Так что я склоняюсь к такому подходу. Если же устройств много и пользователи сами могут установить себе приложение, тогда такой вариант не пройдет конечно.
2. Да, действительно использовать wrapper гораздо проще и удобней, спасибо за подсказку. Не стал описывать как настроить, просто добавил в статью ссылку на видео, поясняющее его настройку, там все просто.
3. На сколько я понял flavors позволяет указать другой пакет приложения, т.е. это отлично подходит для различных версий приложений, например, платная и бесплатная версии. Либо, я так понимаю, необходимо использовать gradle структуру проекта, где у каждого варианта будет своя папка res, я пока не готов перейти к этому, ждем stable версию AndroidStudio.