Готовьте свои варианты сборки!
Если у вас есть промежуточная и производственная среда на стороне сервера, и вы сейчас разрабатываете мобильное приложение, этот пост будет вам очень полезен!
Во время разработки вы можете столкнуться с некоторыми проблемами:
- Как заставить мобильное приложение работать с обеими средами.
- Как легко переключаться между ними и повышать производительность.
- И, что наиболее важно, как сохранить код чистым и без этой логики, встроенной в него.
Gradle и Android Studio - мощная комбинация, предлагающая варианты продукта как способ преодолеть эти препятствия.
Начните с типов сборки!
Типы сборки определяют способы сборки и упаковки вашего приложения. По умолчанию создаются два типа сборки: отладка и выпуск. .
Основное отличие состоит в том, что первый включает флаг debuggable и позволяет вам отлаживать ваше приложение, тогда как второй поставляется с включенным proGuard. ProGuard запутывает код вашего приложения, чтобы сделать реверс-инжиниринг сложной задачей для любопытных.
Вы можете оставить эту конфигурацию по умолчанию. Также обратите внимание, что у некоторых библиотек могут быть проблемы с ProGuard или с конкретными инструкциями, чтобы заставить их работать с ним.
Основные ингредиенты: конфигурации подписи
Вы, вероятно, будете использовать как минимум два разных ключа для подписи своего приложения: один для разработки, а другой для версии PlayStore.
Вы можете включить конфиденциальную информацию непосредственно в основной файл Gradle (что означает, что он также будет в вашем репозитории) или извлечь ее в отдельный файл, который не попадет в ваш репозиторий. Назовем его keystore.gradle:
Затем вам нужно получить переменные в свой скрипт сборки gradle. Для этого вам просто нужно применить файл в начале вашего скрипта gradle:
Ароматизаторы продукта: глазурь на торте
Ароматизаторы полезны для создания разных версий вашего приложения. Все они могут различаться активами, ресурсами, конфигурацией или кодом. Мы будем использовать их для создания версии приложения, используемой для разработки, для достижения конечной точки staging API и другой финальной версии, которая вызывает production API.
Сначала мы связываем каждый вариант с конфигурацией подписи. Это полезно, когда вы используете сторонние службы, которые используют keyhash для идентификации приложения, например Facebook. Это также предотвратит случайную загрузку промежуточной версии приложения в Google Play, поскольку ключ, используемый для подписи приложения, всегда должен быть одним и тем же (производственным).
Затем нам нужно изменить applicationId во вкусе сцены, объединив значение по умолчанию с идентификатором «stage». Вы должны сделать это, потому что это позволит вам установить на ваших устройствах как производственную, так и промежуточную версию, что полезно при разработке.
Вы должны сделать то же самое с versionName, поскольку некоторые службы отображают информацию на основе имени версии (например, Analytics).
Как отличить оба приложения друг от друга при установке на вашем устройстве? Вы можете сделать другой значок лаунчера. Например, версия в оттенках серого или добавьте на нее водяной знак.
Для этого необходимо воссоздать структуру папки res в другой папке, названной в честь разновидности продукта (в в данном случае «этап»). Затем вам нужно будет сохранить там новый значок запуска:
Чтобы вкус сцены достиг конечной точки промежуточного API, мы могли бы создать класс BaseConfiguration внутри папок stage и production с разными конфигурациями. .
Теперь расширите этот класс с помощью Configuration class в main папке, которая содержит общую конфигурацию, которая не будет меняться между вариантами.
В оставшемся коде приложения мы можем вызвать класс Configuration напрямую, так как он унаследует конфигурацию от класса аромата. Окончательная структура папки будет выглядеть следующим образом:
См. также: Хорошие, плохие и неприятные вещи в новом RecyclerView
Варианты свежеиспеченных продуктов!
Теперь, когда все готово, мы можем легко переключаться между различными вариантами продукта из пользовательского интерфейса Android Studio. Каждый вариант создается путем сочетания типа сборки и разновидности.
В этом случае это даст вам четыре различных комбинации. Вы, вероятно, найдете только три из них полезными:
- productionRelease: окончательная версия, которую можно загрузить в Google Play Store. Эта версия должна быть протестирована QA.
- productionDebug: используется для отладки версии производственного приложения, которая могла быть загружена в Google Play Store. Также полезно отлаживать ошибки с помощью сторонних сервисов, которые требуют, чтобы приложение было подписано рабочим ключом.
- stageDebug: основной вариант, используемый для разработки. Он вызовет промежуточный API и будет готов к отладке.
Теперь вы готовы продолжать разрабатывать потрясающие приложения, не беспокоясь об изменении кода для тестирования вашего приложения на тестовых и производственных серверах!
Автор: Федерико Рамундо ([email protected])
