Супер, спасибо за крутой инструмент!
Мы в Райффайзен Банке как раз планируем на него подсесть. Как раз переводим тесты с Appium на нативные, по этому сложно было проголосовать в первом вопросе опросника)
Спасибо, мы отлично знаем Flutter, например, я один из первых в России кто рассказывал что такое Flutter и почему на него стоит смотреть.
Но, вся наша мобильная разработка нативная и на данный момент мы не планируем что-то менять, поэтому планируем учить разработчиков мейнстриму)
Особенности реализации модели безопастности Android, доступ к информации о устройстве входит в группу разрешений звонков. Видимо спецом сделали что бы пугало пользователей и особо не юзал никто этот permission.
Вообщем звонить и смотреть историю звонков (скорее всего) никто не будет, а разрешение нужно тупо что бы идентифицировать ваше устройство и проверить что оно безопасно.
Если эти не самый умные личности, таки надумают закрыть полностью доступ к апи обращайтесь – зареверсим официальное приложение и сделаем 100% работоспособность версии дневника от вас.
Есть вакансии в банках где программисты только на xml пишут логику преобразования данных под выдачу из БД. Естественно используя возможности других программных продуктов.
Google Assistant странно сравнивать с Apple Siri, его есть смысл сравнивать с Amazon Echo.
Более того если сравнивать даже текущие, стандартные помощники, доступные конечному пользователю то Apple Siri явно не лидер. А из альтернативных решений Viv выглядит просто замечательно.
Ваше мнение не лишено логики, и не так давно сообщество обсуждало как раз этот вопрос.
Дескать в чём отличия то?
Ежели сильно угодно залезть в полу холивары, лучше всё же загуглить. Например Alex Russell неплохо ответитл на подобный вопрос в статье `Mmmmmmm….Carrots!`
Если мега кратко то моё мнение что основное нововведение это появление App Install банеров. Благодаря манифесту и правильной конфигурации браузер сможет самостоятельно определить что у вас PWA приложение и предложить пользователю добавить приложение на главный экран.
Также возможно маркетинговый ребрендинг итеративных улучшений веб приложений с целью сделать веб приложения более популярными.
На самом деле я сходу не смогу привести хорошую ссылку с примерами что и как, но встречал это утверждение в нескольких статьях + по моему предыдущему опыту использования нативной разработки: WebView всегда медленнее стандартного браузера, а если использовать что-то оптимизированное например Chrome Custom Tabs то сможем получить даже двойной прирост скорости.
Да Android Instant Apps это мега крутая штука которую мы все давно ждём, но во первых она пока что не публична + из того что мне известно большинство переоценивает её возможности. Но это уже другая история которую я расскажу немного позже.
В целом различий очень много, самыми весомыми я бы назвал то, что Кордова работает намного медленнее чем PWA из-за использования Web View + с Кордовой вы не сможете предоставить пользователю возможность использовать ваше приложения без установки. С PWA сможете.
В gradle намного лучше устроена паралелизация процессов для модулей + включенный демон творит чудеса. Поэтому сборка на gradle всегда быстрее, особенно если всё настроить.
Этот комментарий при детальном ответе мог бы перейти в небольшую статью, но буду краток.
Ключевой точкой любой системы сборки является Execution Units(Gradle: task, Maven: goal && lifecycle) + Execution Dependencies (Gradle: dependsOn, Maven: goal dependencies && lifecycle).
Собственно Control Flow (порядок выполнения) состоит из Execution Units + Executuin Dependencies. Ни одна система сборки не может существовать без Control Flow. И в императивной системе сборки Build Author полностью определяет Control Flow т.е. определяем абсолютно все значения и всегда весь порядок. Чистейшим примером императивной системы сборки является Ant.
Декларативная система сборки отличается тем что Build Author может не определять Control Flow, например когда вы подключаете в Gradle плагин вы автоматически получите Control Flow и необходимые таски плагина будут выполнены. В Gradle это называется декларативными элементами верхнего уровня.
apply plugin: 'com.android.application'
В Maven так же есть возможность подключить плагин, но это делается на императивном уровне т.е. всё равно происходит привязка плагина к фазе сборки проекта. Например возьмем кусок настройки подключения плагина из статьи Borz
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<useSubDirectoryPerScope>true</useSubDirectoryPerScope>
<excludeGroupIds>исключаем некоторые группы, попадающие в war-архив</excludeGroupIds>
</configuration>
</execution>
</executions>
</plugin>
Кроме этого концепция плагинов в Gradle и Maven абсолютно отличается.
Кроме того в Gradle есть декларативные элементы нижнего уровня, которых в Maven просто нет.
Как-то я сразу не заметил часть вашего комментария, дополню:
> Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
Я не скажу когда конкретно началась alpha разработка Gradle(насколько помню в 2008), но первый релиз был в 2012. Maven 1 релиз был в 2002/2004 (честно не помню), Maven 2 в 2005.
Уже прошло года 3-4 с тех пор как я открывал Eclipse. Возможно сейчас всё изменилось (тот же Gradle плагин написали для Eclipse), но тогда всё было очень плохо во многих местах, если говорить про Android разработку естественно.
«Если в том же Eclipse я хочу, чтобы проект собрался один-в-один, как на билд-сервере, я создам run configuration типа maven build и буду использовать его.»
А тут даже делать ничего не нужно.
Так плагин вы подключаете к build system или к IDE? С тем же checkstyle я не вижу проблемы т.к. у вас есть возможность как установить плагин к IDE отдельно, так и установить плагин к Gradle и интеграцию к IDE.
Да, фактически большинство из того что вы описали или вкусовщина, или то что будет допилено (NDK например).
Скорость больное место, но с выходом давнишней 2.4 уже не настолько, да и существенно быстрее времён Eclipse/Ant.
+ из того что я нагуглил Gradle 2 годичной давности якобы быстрее Maven.
Документация на самом деле отличнейшая, другое дело что она огромна)
В целом я не могу с вам согласится, но безусловно вы можете быть правы и хорошо оно есть)
Да, вам будет необходимо использовать другой packageName, кроме уникальности packageName может быть уникальность packageGroup. Т.е. возможна ситуация когда вам понадобится публиковать «com.artemexample.library:foo:1.2.3».
По теме публикации библиотек в jCenter недавно на habrahabr была хорошая статья, советую почитать при необходимости.
Мы в Райффайзен Банке как раз планируем на него подсесть. Как раз переводим тесты с Appium на нативные, по этому сложно было проголосовать в первом вопросе опросника)
Но, вся наша мобильная разработка нативная и на данный момент мы не планируем что-то менять, поэтому планируем учить разработчиков мейнстриму)
Вообщем звонить и смотреть историю звонков (скорее всего) никто не будет, а разрешение нужно тупо что бы идентифицировать ваше устройство и проверить что оно безопасно.
Более того если сравнивать даже текущие, стандартные помощники, доступные конечному пользователю то Apple Siri явно не лидер. А из альтернативных решений Viv выглядит просто замечательно.
Дескать в чём отличия то?
Ежели сильно угодно залезть в полу холивары, лучше всё же загуглить. Например Alex Russell неплохо ответитл на подобный вопрос в статье `Mmmmmmm….Carrots!`
Если мега кратко то моё мнение что основное нововведение это появление App Install банеров. Благодаря манифесту и правильной конфигурации браузер сможет самостоятельно определить что у вас PWA приложение и предложить пользователю добавить приложение на главный экран.
Также возможно маркетинговый ребрендинг итеративных улучшений веб приложений с целью сделать веб приложения более популярными.
Да Android Instant Apps это мега крутая штука которую мы все давно ждём, но во первых она пока что не публична + из того что мне известно большинство переоценивает её возможности. Но это уже другая история которую я расскажу немного позже.
Сейчас стало лучше?
«Кроме того, Jack по умолчанию используется в Android M» – а есть где прочитать об этом детальней и что именно подразумевается?
Ключевой точкой любой системы сборки является Execution Units(Gradle: task, Maven: goal && lifecycle) + Execution Dependencies (Gradle: dependsOn, Maven: goal dependencies && lifecycle).
Собственно Control Flow (порядок выполнения) состоит из Execution Units + Executuin Dependencies. Ни одна система сборки не может существовать без Control Flow. И в императивной системе сборки Build Author полностью определяет Control Flow т.е. определяем абсолютно все значения и всегда весь порядок. Чистейшим примером императивной системы сборки является Ant.
Декларативная система сборки отличается тем что Build Author может не определять Control Flow, например когда вы подключаете в Gradle плагин вы автоматически получите Control Flow и необходимые таски плагина будут выполнены. В Gradle это называется декларативными элементами верхнего уровня.
В Maven так же есть возможность подключить плагин, но это делается на императивном уровне т.е. всё равно происходит привязка плагина к фазе сборки проекта. Например возьмем кусок настройки подключения плагина из статьи Borz
Кроме этого концепция плагинов в Gradle и Maven абсолютно отличается.
Кроме того в Gradle есть декларативные элементы нижнего уровня, которых в Maven просто нет.
Т.е. для того что бы переопределить какой-то конкретный элемент для конкретного варианта сборки нам не нужно определять/переопределять Control Flow.
> Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
Я не скажу когда конкретно началась alpha разработка Gradle(насколько помню в 2008), но первый релиз был в 2012. Maven 1 релиз был в 2002/2004 (честно не помню), Maven 2 в 2005.
«Если в том же Eclipse я хочу, чтобы проект собрался один-в-один, как на билд-сервере, я создам run configuration типа maven build и буду использовать его.»
А тут даже делать ничего не нужно.
Так плагин вы подключаете к build system или к IDE? С тем же checkstyle я не вижу проблемы т.к. у вас есть возможность как установить плагин к IDE отдельно, так и установить плагин к Gradle и интеграцию к IDE.
Скорость больное место, но с выходом давнишней 2.4 уже не настолько, да и существенно быстрее времён Eclipse/Ant.
+ из того что я нагуглил Gradle 2 годичной давности якобы быстрее Maven.
Документация на самом деле отличнейшая, другое дело что она огромна)
В целом я не могу с вам согласится, но безусловно вы можете быть правы и хорошо оно есть)
По теме публикации библиотек в jCenter недавно на habrahabr была хорошая статья, советую почитать при необходимости.