ios设置包中的简单标题输出 [英] Simple title output in ios settings bundle

问题描述

我只想在设置文件中输出我的ios应用程序的版本号。

I just want to output the version number of my ios application in a settings file.

我知道我必须将设置文件添加到应用程序文件夹中。

I understand that I have to add the settings file to the application folder.

当我构建并运行时，我可以看到标准设置包附带的4个设置。

When I build and run I can see the 4 settings which come with the standard settings-bundle.

为了获得一个简单的只读字符串，我将第二个值更改为以下

In order to get a simple read-only string I change the second value to the following

在代码中（didFinishLaunchingWithOptions :)我调用以下内容：

In code (didFinishLaunchingWithOptions:) I call the following:

NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
[[NSUserDefaults standardUserDefaults] setValue:version forKey:@"version_number"];
[[NSUserDefaults standardUserDefaults] synchronize];

令我惊讶的是一切都没有发生。我只看到了Group元素和toogle开关以及滑块但没有标题行。有谁知道我错过了什么？

To my surprise nothing happens at all. I just see the Group element and the toogle switch and the slider but no title line. Anybody knows what I am missing?

非常感谢！

推荐答案

<好的，我也有这个问题。解决方案（类型）是提供默认值字段并给出一个值。这实际上是在文档中明确说明的 - 默认值是Title属性的必填字段，因此如果您不指定它，标题将不会显示在设置窗格中。不幸的是，我似乎无法在设置后更改值，也可能是设计的 - 文档还声明它是一个只读属性。我要尝试的解决方案是每次进行新构建时都将版本号明确地放在我的Root.plist文件中。我觉得超级不理想，但会起作用。

Ok, I had this problem too. The solution (sort of) was to provide a default value field and give that a value. This is actually explicitly stated in the documentation -- Default Value is a required field for the Title property, so if you don't specify it the title won't show in the settings pane. Unfortunately, I can't seem to CHANGE the value once it's set, possibly also as designed -- the documentation also states that it's a read only property. The solution I'm going to try is to just explicitly put the version number in my Root.plist file each time I make a new build. SUPER not ideal, but will work, I think.

编辑：查看这篇关于更新设置包中的版本号的帖子

编辑：好的，我得到了这个工作（感谢上面的帖子，以及有点黑客攻击bash脚本，我很少有经验。）这是脚本（我刚刚在'运行脚本'构建阶段内联编写）：

Ok, I got this working (thanks to that post, above, and a little hacking around with bash scripts, which I had very little experience with.) Here's the script (which I just wrote inline in a 'Run Script' build phase):

#!/bin/bash

builtInfoPlistPath=${TARGET_BUILD_DIR}/${INFOPLIST_PATH}

#increment the build number
buildNumber=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$builtInfoPlistPath")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$builtInfoPlistPath"

#compose the version number string
versionString=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "$builtInfoPlistPath")
versionString+=" ("
versionString+=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$builtInfoPlistPath")
versionString+=")"

#write the version number string to the settings bundle
#IMPORTANT: this assumes the version number is the first property in the settings bundle!
/usr/libexec/PlistBuddy -c "Set :PreferenceSpecifiers:0:DefaultValue $versionString" "Settings.bundle/Root.plist"

......就是这样！奇迹般有效！希望这有助于你的问题，因为它解决了我的问题。现在唯一的问题是与内部版本号略有差异......

... and that's it! Works like a charm! Hope that helps with your problem, because it solved mine. Only problem now is a slight discrepancy with the build number ...

编辑：...我用 vakio对这篇文章的第二条评论，它将info.plist的路径设置为已处理的路径（在Run Script阶段之前！）

... which I fixed with vakio's second comment on this post, which instead sets the path to the info.plist to the one which is already processed (before the Run Script phase!)

编辑：这是我的更新版本，它位于外部文件中，并在增加内部版本号之前验证某些源文件是否已更改：

Here's my more up-to-date version, which is in an external file and verifies that some source files have changed before incrementing the build number:

 #!/bin/bash

 #note: for simplicity, it's assumed that there's already a bundle version (which is an integer) and a version string. set them in the Summary pane!

 #get path to the BUILT .plist, NOT the packaged one! this fixes the off-by-one bug
 builtInfoPlistPath=${TARGET_BUILD_DIR}/${INFOPLIST_PATH}
 echo "using plist at $builtInfoPlistPath"

 modifiedFilesExist=false
 #this is the modification date to compare to -- there's a possible bug here, if you edit the built plist directly, for some reason. probably you shouldn't do that anyways.
 compModDate=$(stat -f "%m" "$builtInfoPlistPath")

 for filename in *
 do
     modDate=$(stat -f "%m" "$filename")
     if [ "$modDate" -gt "$compModDate" ]
     then
         modifiedFilesExist=true;
         echo "found newly modified file: $filename"
         break
     fi
 done

 if $modifiedFilesExist
 then
     echo "A file is new, bumping version"

     #increment the build number
     buildNumber=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$builtInfoPlistPath")
     echo "retrieved current build number: $buildNumber"
     buildNumber=$(($buildNumber + 1))
     /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$builtInfoPlistPath"
     /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

     #compose the version number string
     versionString=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "$builtInfoPlistPath")
     versionString+=" ("
     versionString+=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$builtInfoPlistPath")
     versionString+=")"

     #write the version number string to the settings bundle
     #IMPORTANT: this assumes the version number is the second property in the settings bundle!
     /usr/libexec/PlistBuddy -c "Set :PreferenceSpecifiers:1:DefaultValue $versionString" "Settings.bundle/Root.plist"
 else
     echo "Version not incremented -- no newly modified files"
 fi 

这篇关于ios设置包中的简单标题输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！