香料有什么作用?
想象一下情况:有一个带有分析功能的应用程序。有一个开发团队,测试人员和最终用户。这些和那些都使用该应用程序的一个版本。假设我们要分析功能A对用户的有趣程度,在这种情况下我们该怎么做?我们去分析,看看该功能有多少用途(例如,过渡到屏幕)。但是,我们看到的是:过渡数量之高,对于当前的受众来说绝对是不可能的,而且所有这些过渡都是在一定时期内进行的。我们走得更远,并且了解到此时已经对此功能进行了测试。以及它的发展。同时,还发送了分析数据。底线:分析是肮脏的和不合标准的。
在这里,您可以将Analytics(分析)一词替换为其他任何东西:推送通知,崩溃报告等。
在这种情况下,可以通过将应用程序划分为两个具有最小差异的版本来保存我们,例如Bundle ID(程序包名称)。开发人员和测试人员仅使用特殊的开发版本,而用户使用销售版本。
这只是调味品的任务之一。这里将使用味道,因为这是Flutter使用的名称。熟悉Android开发的人,我想立即意识到了这种机制。

风味扑扑?
好吧,我们找到了任务。但是如何实施呢?一切都像他们所说的那么简单吗?
让我们立即决定:风味的组织是纯天然的任务。Dart代码将无法提供有关它们的信息。因此,对于组织方式,我们将进行本机移动开发。
安卓系统
. android. : « buildType?», .
, , :
flavorDimensions "release-type"
productFlavors {
dev {
dimension "release-type"
applicationIdSuffix ".dev"
versionNameSuffix "-dev"
}
prod {
dimension "release-type"
}
}
, :
flutter run --flavor dev
android .
: « buildType?» : Flutter buildType . , .
.
, builtTypes. IOS.
:
— , ( ). flavor’ target’ — .
, , «»...
Runner — .
, target flavors iOS . , Flutter . , . . .
IOS
: (dev, prod, ).
:
- .
- .
- !
.
: dev, prod. :
#include "Pods/Target Support Files/Pods-Runner/Pods-Runner.debug-dev.xcconfig"
#include "Generated.xcconfig"
#include "common.xcconfig"
bundle_suffix=.dev
IDENTIFIER=$(identifier)$(bundle_suffix)
, bundle_suffix.
, Flutter Release Debug. bundle_suffix. , IDE.
IDENTIFIER — .
, :
ios/Flutter/dev.xcconfig
ios/Flutter/prod.xcconfig
XCode ( , ). Runner → New File → Configuration Settings File → .
Build Configurations. .
. Runner.xcworkspace Xcode Project.
«+» Configurations : Release Debug, .
:

, , IOS .
Scheme
, .

. : — Runner.
Edit Scheme .
Info.plist
(: ) — Bundle Identifier Info.plist
$(PRODUCT_BUNDLE_IDENTIFIER)$(bundle_suffix)
...
, , Android , fastlane gym iOS — . , IOS - … .
No Provisioning Profile
— . , .
, Info.plist , gym PRODUCT_BUNDLE_IDENTIFIER, .
common.xcconfig IDENTIFIER? .
, , , PRODUCT_BUNDLE_IDENTIFIER.
:
identifier=your.bundle.identifier
include User Defined
IDENTIFIER:
#include "common.xcconfig"
IDENTIFIER=$(identifier)$(bundle_suffix)
Xcode. Build Settings:

Product Bundle Identifier ( Packaging):

:
$(IDENTIFIER)

Info.plist bundle suffix, :
$(PRODUCT_BUNFLE_IDENTIFIER)
. .
bundle id
. Firebase, ( ).
— google-services.json(Google-Services.Info.plist). Android : flavor’ .
IOS - .
, . :

: XCode. . XCode — IDE, Add to target.
.
, . - , .
Run Script (setup firebase ):

, !
, :
# Name of the resource we're selectively copying
GOOGLESERVICE_INFO_PLIST=GoogleService-Info.plist
# Get references to dev and prod versions of the GoogleService-Info.plist
# NOTE: These should only live on the file system and should NOT be part of the target (since we'll be adding them to the target manually)
GOOGLESERVICE_INFO_DEV=${PROJECT_DIR}/${TARGET_NAME}/Firebase/dev/${GOOGLESERVICE_INFO_PLIST}
GOOGLESERVICE_INFO_PROD=${PROJECT_DIR}/${TARGET_NAME}/Firebase/prod/${GOOGLESERVICE_INFO_PLIST}
# Make sure the dev version of GoogleService-Info.plist exists
echo "Looking for ${GOOGLESERVICE_INFO_PLIST} in ${GOOGLESERVICE_INFO_DEV}"
if [ ! -f $GOOGLESERVICE_INFO_DEV ]
then
echo "No Development GoogleService-Info.plist found. Please ensure it's in the proper directory."
exit 1 # 1
fi
# Make sure the prod version of GoogleService-Info.plist exists
echo "Looking for ${GOOGLESERVICE_INFO_PLIST} in ${GOOGLESERVICE_INFO_PROD}"
if [ ! -f $GOOGLESERVICE_INFO_PROD ]
then
echo "No Production GoogleService-Info.plist found. Please ensure it's in the proper directory."
exit 1 # 1
fi
# Get a reference to the destination location for the GoogleService-Info.plist
PLIST_DESTINATION=${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app
echo "Will copy ${GOOGLESERVICE_INFO_PLIST} to final destination: ${PLIST_DESTINATION}"
# Copy over the prod GoogleService-Info.plist for Release builds
if [[ "${CONFIGURATION}" == *-prod ]]
then
echo "Using ${GOOGLESERVICE_INFO_PROD}"
cp "${GOOGLESERVICE_INFO_PROD}" "${PLIST_DESTINATION}"
else
echo "Using ${GOOGLESERVICE_INFO_DEV}"
cp "${GOOGLESERVICE_INFO_DEV}" "${PLIST_DESTINATION}"
fi
. , , Flutter ( ). , . .