jdee / settings-bundle Goto Github PK

When adding a settings bundle to a project, there is an option to call it something other than Settings. This doesn't seem to be a common use case, but it is possible. Rather than looking for a file in the project called Settings.bundle, it might be necessary to allow the name to be passed in or infer the location by looking for a directory called *.bundle (containing a file called Root.plist).

This would require further modifications to the built-in commit_version_bump action. If this becomes an issue for anyone, it can be addressed then.

The new target param added in the last release broke my update_settings_bundle fastlane plugin. Have already verified it works with 1.0 and fails after upgrading to 1.1. The issue is that the new param's key to fastlane is a duplicate of an existing key 'file':

FastlaneCore::ConfigItem.new(key: :file,
            env_name: "SETTINGS_BUNDLE_TARGET",
            description: "An optional target name from the project",
            optional: true,
            type: String)

I believe the key: should be key: :target instead of :file since :file is an existing param in 1.0

Any support for multi-value keys?

Root.plist:

  <dict>

    <key>Type</key>

    <string>PSMultiValueSpecifier</string>

    <key>Title</key>

    <string>Environments</string>

    <key>Key</key>

    <string>app_environment</string>

    <key>Titles</key>

    <array>

      <string>localhost</string>

      <string>prd</string>

    </array>

    <key>Values</key>

    <array>

      <string>localhost</string>

      <string>prd</string>

    </array>

  </dict>

Fastfile:

  lane :change_env_settings do |options|
    update_settings_bundle(
      key: "app_environment",
      value: options[:value]
    )
  end

Error:
[!] preference for key app_environment must be of type title

Since the inclusion of this pull request in Fastlane, the Fastlane::Actions.ignore_cocoapods_path has been removed in favour of Fastlane::Helper::XcodeprojHelper which detects Carthage and Cocoapod workspace project files.

My suggestion is that settings_bundle_helper.rb:143 needs changing to:
xcodeproj_paths = Fastlane::Helper::XcodeprojHelper.find(all_xcodeproj_paths)

And then the failing test in specs/settings_bundle_helper_spec.rb need their expectations changing to expect 2 calls to the Dir method.

This is probably due to the plist gem representing the keys as a Hash. When it writes out the updated file, it iterates through the keys in order. The only practical result is that a diff shows a lot of changes in the settings bundle the first time the action runs. If the settings bundle is only afterward updated by this action, the diffs will be simpler, since the keys will not be reordered each time. Still, it would be preferable to retain the original key order.

I have separate Settings.bundle at different paths and trying to use this plugin and it is failing to update it

New to Fastlane and Ruby, so apologies if I have done something stupid to cause my error.

I have the following in my fastfile:

      update_settings_bundle(
        xcodeproj: "appdemo.xcodeproj",
        key: "pref_env",
        value: "QA"
      )

When I run my fastfile, I get the following error:
undefined method []' for nil:NilClass`

Root.plist is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>StringsTable</key>
	<string>Root</string>
	<key>PreferenceSpecifiers</key>
	<array>
		<dict>
			<key>Type</key>
			<string>PSTitleValueSpecifier</string>
			<key>Title</key>
			<string>Version</string>
			<key>Key</key>
			<string>pref_version</string>
			<key>DefaultValue</key>
			<string>?????????</string>
		</dict>
		<dict>
			<key>Type</key>
			<string>PSTitleValueSpecifier</string>
			<key>Title</key>
			<string>Environment</string>
			<key>Key</key>
			<string>pref_env</string>
			<key>DefaultValue</key>
			<string>?????????</string>
		</dict>
	</array>
</dict>
</plist>

This is just a place for community comment and review before releasing this gem. Feel free to open other issues for specific things.

Some issues/questions:

• It seems silly to publish a gem for a single action, but I guess a lot of plugins do. I wonder if there are other settings-bundle-related actions that could be useful. I was thinking of adding a more general action like exposing, essentially, the SettingsBundleHelper::update_settings_plist_title_setting method. That could allow you to automatically update any constant, like your API domain or something like that. But since you can't have different settings bundles for different build configurations, whatever you add potentially goes to the App Store, so it's not clear what you would want to include. Update 2016-11-20: I think there is a case for adding support for content other than the version and build number, but this doesn't necessarily mean another action. See #2.
• I'd like to support customizing the format, but it's not obvious how to let the user specify it, or how important that is at first. You can must now specify non-default key content using a value: argument. See the README. This may become is now a required argument.
• I'm thinking of adding a target parameter to specify the target by name, though I'm not sure you can have multiple application targets in the same project. If so, they'll share the same Settings.bundle. Specifying the target may be pointless. The :target parameter was added in v1.1.0.
• I'd like to have the button in the sample app take the user to the settings bundle for the app in the Settings app. I'm not sure what the URI is to open the Settings app to the page for a specific app though. I appreciate any advice. Update 2016/11/20: I'm not sure any prefs: URI still works in iOS 10. Apple seems to have killed this URI scheme. This has been done.

Still to do:

• Tests
• CI

Original Fastlane issue/discussion: fastlane/fastlane#5758

I'd like to generate a whole settings bundle with your tool. Therefore i need to add other options aswell than just textual settings like entering a type (textual read/write, switch), a default value, a secure enter, ...

Will this be available soon?

I noticed an app that has not only a version number but also a build date and release date in the settings bundle. The release date is unspecific ("Nov 2016"), so it's probably not something this app would automate. Otherwise you'd have to have a repackaging job to alter the settings bundle after a release candidate passed QA.

At any rate, there are tons of things that this plugin could conceivably add to a settings bundle, like the current time in a specified format. This could indicate one or more additional actions, but now that the action takes a format, it would be possible to generalize the idea. You have to be able to specify an strftime format for times. It wouldn't be hard to support things like:

update_settings_bundle xcodeproj: "MyProject.xcodeproj", key: "BuildTime", format: ":time(%Y-%m-%d)"
update_settings_bundle xcodeproj: "MyProject.xcodeproj", key: "SDKVersion", format: "iOS SDK :sdk_version"
update_settings_bundle xcodeproj: "MyProject.xcodeproj", key: "APIHost", format: "api.example.com"

And so on. The last example is already possible, meaning the others are also possible if you obtain the information yourself, e.g.

update_settings_bundle xcodeproj: "MyProject.xcodeproj", key: "BuildTime", format: Time.now.strftime "%Y-%m-%d"

As long as the value specified doesn't contain :build or :version, it will be updated in the settings bundle plist specified.

Maybe it makes sense to change format: to value: with the understanding that certain symbols will result in substitutions in the value. The format: argument has been changed to value: in anticipation of this change. Additional content may wait until after the initial release, depending on interest.

It might also make sense to make the value: argument required so that for the current functionality, you would use:

The value: argument is now required:

update_settings_bundle xcodeproj: "MyProject.xcodeproj", key: "CurrentAppVersion", value: ":version (:build)"

WatchKit also supports settings bundles: https://developer.apple.com/library/content/documentation/General/Conceptual/WatchKitProgrammingGuide/Settings.html

It's not obvious if this would be a candidate for static settings like version numbers and build dates. It appears to be primarily used to display controls to the user. It would probably be easy enough to support these settings bundles in this plugin if there is a use case for it.

Many Fastlane actions automatically find a project without specifying an argument for the path. The update_settings_bundle action should as well.

Note that you can also set ENV["SETTINGS_BUNDLE_XCODEPROJ"] = "MyProject.xcodeproj" if you're invoking the action multiple times and want to avoid passing the parameter each time. This is done in the :library_test lane in the fastlane/Fastfile. It would be nice not to have to for simple or default behavior, however.

Hihi, I have a problem executing this.

In this line of the settings_bundle_helper.rb file, the release_info_plist_path contains the $(SRCROOT) text in the file path, so it is throwing a rb sysopen - file not found error.

This fix made it work
release_info_plist_path = File.join project_parent, release_info_plist_path.gsub("$(SRCROOT)/", "")
but its definitely not right to do it this way.

Am I missing something to make it work?

Many thanks! I looking forward to using this gem it will help me greatly. Thanks for it!