Картографические данные сами по себе являются объектом авторского права ( у карты есть автор ), содержимое каталога условного леруа объектом авторского права не является
Ребят, а сделайте пожалуйста выбор языка независимо от языка страны. Для примера, живу в Эстонии и хотелось бы пользоваться приложением на русском / английском
Такие письма мы отправляем только текущим пользователям. Нам важно собирать обратную связь, особенно, в странах, где мы только запустились. Если вы получили такое письмо и не пользовались нашим сервисом, вероятно кто-то использовал ваш email при поездке. Напишите нам в поддержку или в личные сообщения, выясним детали.
Сейчас у нас синхронные мажорные и минорные релизы. Хотфиксы тоже обычно синхронно выкатываем. Пару раз были независимые хотфиксы только одного приложения. Так что сейчас для упрощения жизни у нас есть жесткий маппинг версий между приложениями и версии синхронно поднимаются.
Как-то помечаете коммиты в гите, когда изменения затрагивают отдельные приложения/когда сразу оба/когда только общий код?
Спецпометок нет, но для двух приложений у нас отдельные проекты в трекере задач и по названию ветки видно "приложение-инициатор" изменений.
вот модули junior feature и adult feature находятся рядом в корневой папке вместе с остальными общими модулями или каждый из этих модулей находятся внутри «модулей» приложение junior и adult?
В "корневой" папке проекта можно создать дерево папок и хранить модули там.
Примерно так
root
— application (легаси — монолит)
— adult (модуль)
— junior (модуль)
— sources
— — features
— — — feature-A (модуль фичи А)
— — — feature-B (модуль фичи Б)
— — — feature-C (модуль фичи С)
могут ли быть у junior и adult свои собственные flavors/build variants?
Да, могут.
Как в рамках CI происходит сборка разных приложений?
Все просто, запускаем отдельно две таски) :adult:assembleDebug :junior:assembleDebug
В данном случае таски имеют одинаковое имя, так что можно просто assembleDebug
У нас есть несколько модулей junior feature, несколько модулей common feature и несколько модулей adult feature. В каждом модуле описана 1 фича.
Модуль application(library) — это остатки нашего монолита, который мы продолжаем разносить на фиче-модули.
Ну так никто же не заставляет подключать support-библиотеки. Вполне можно писать и без них. Другой вопрос когда мы пытаемся дизайн из 2018 натянуть на устройство выпущенное в 2015 с Android 5 на борту.
ЗЫ. изначально support появился как средство борьбы с фрагментацией. Не будет фрагментации — не нужен будет и support.
>А на мой взгляд правильным и логичным шагом в развитии support-библиотек было бы вынесение всех support-библиотек в отдельные .apk, которые можно устанавливать и обновлять независимо друг от друга, и которыми смогли бы пользоваться все установленные в системе приложения.
Ну примерно так сейчас работают play services.
Play services общаются с приложениями через IPC (inter-process communication) на уровне простых комманд («покажи диалог логина», «покажи экран покупки», «дай список покупок»). Использовать UI-компоненты из play-services достаточно сложно (а support-библиотеки в основном состоят из UI-компонентов). Единственный пример, который я сейчас вспомнил — это youtube-плеер. Кстати, для использования play services в своем приложении тоже нужно использовать библиотеки.
>А то, что произошло сейчас ничем принципиально от того, что было не отличается, к сожалению — всё больше кусочков OS втаскивается внутрь приложения.
Внутрь КАЖДОГО приложения.
С точки зрения разработчика изменения есть. Теперь не нужно синхронизировать версии всех support-библиотек.
>И это, к сожалению, приводит к безудержному росту размера .apk и используемой памяти (как дисковой, так и оперативной).
Тут вы немного сгущаете. Субъективно размер средней apk-шки за последние 4 года вырос раза в 2-3. Потребление оперативной памяти выросло примерно так же.
Картографические данные сами по себе являются объектом авторского права ( у карты есть автор ),
содержимое каталога условного леруа объектом авторского права не является
Все уже придумано: https://en.wikipedia.org/wiki/Master_Password_(algorithm)
https://gitlab.com/spectre.app
На самом деле прочитать ингридиенты на местном - это меньшая проблема. А вот всякие "Ой, что-то пошло не так" - это прям сложно.
Телефон на русском
Ребят, а сделайте пожалуйста выбор языка независимо от языка страны. Для примера, живу в Эстонии и хотелось бы пользоваться приложением на русском / английском
Ребят, а сделайте пожалуйста выбор языка. Приезжаешь в другую страну, переключаешь приложение на новую страну, а языка не знаешь.
Он еще со временем дорожает/дешевеет. За последний год заправлялся как по 1.25 так и за 1.1
Такие письма мы отправляем только текущим пользователям. Нам важно собирать обратную связь, особенно, в странах, где мы только запустились. Если вы получили такое письмо и не пользовались нашим сервисом, вероятно кто-то использовал ваш email при поездке. Напишите нам в поддержку или в личные сообщения, выясним детали.
Нашли ваше обращение, ответим в ближайшее время. Заодно разберемся, почему не ответили раньше
Спасибо за идею и фидбэк, мы как раз работаем сейчас над похожими задачами
Нашли ваше обращение, ответим в ближайшее время. Заодно разберемся, почему не ответили раньше
Сейчас у нас синхронные мажорные и минорные релизы. Хотфиксы тоже обычно синхронно выкатываем. Пару раз были независимые хотфиксы только одного приложения. Так что сейчас для упрощения жизни у нас есть жесткий маппинг версий между приложениями и версии синхронно поднимаются.
Спецпометок нет, но для двух приложений у нас отдельные проекты в трекере задач и по названию ветки видно "приложение-инициатор" изменений.
Конечно да, а, к примеру, таска
installDebugустановит дебажные версии двух приложений.В "корневой" папке проекта можно создать дерево папок и хранить модули там.
Примерно так
root
— application (легаси — монолит)
— adult (модуль)
— junior (модуль)
— sources
— — features
— — — feature-A (модуль фичи А)
— — — feature-B (модуль фичи Б)
— — — feature-C (модуль фичи С)
Да, могут.
Все просто, запускаем отдельно две таски)
:adult:assembleDebug :junior:assembleDebugВ данном случае таски имеют одинаковое имя, так что можно просто
assembleDebugУ нас есть несколько модулей junior feature, несколько модулей common feature и несколько модулей adult feature. В каждом модуле описана 1 фича.
Модуль application(library) — это остатки нашего монолита, который мы продолжаем разносить на фиче-модули.
Kotlin User Group SPB — несколько раз в год про котлин
Google Developers Group SPB — периодически собираются поговорить про гугловые технологии + организация трансляций Google I/O
Яндекс.Встречи бывают в Питере
ЗЫ. изначально support появился как средство борьбы с фрагментацией. Не будет фрагментации — не нужен будет и support.
Ну примерно так сейчас работают play services.
Play services общаются с приложениями через IPC (inter-process communication) на уровне простых комманд («покажи диалог логина», «покажи экран покупки», «дай список покупок»). Использовать UI-компоненты из play-services достаточно сложно (а support-библиотеки в основном состоят из UI-компонентов). Единственный пример, который я сейчас вспомнил — это youtube-плеер. Кстати, для использования play services в своем приложении тоже нужно использовать библиотеки.
>А то, что произошло сейчас ничем принципиально от того, что было не отличается, к сожалению — всё больше кусочков OS втаскивается внутрь приложения.
Внутрь КАЖДОГО приложения.
С точки зрения разработчика изменения есть. Теперь не нужно синхронизировать версии всех support-библиотек.
>И это, к сожалению, приводит к безудержному росту размера .apk и используемой памяти (как дисковой, так и оперативной).
Тут вы немного сгущаете. Субъективно размер средней apk-шки за последние 4 года вырос раза в 2-3. Потребление оперативной памяти выросло примерно так же.