Accessing Bundle Version in Unity iOS Runtime (2)

Accessing Bundle Version in Unity iOS Runtime (2)

In part 1 I introduced a solution how to get access to Unity’s PlayerSettings.bundleVersion at runtime. Now I want to improve the editor classes to get a smoother workflow and add some version tracking.

At the end of part (1) I diagnosed some drawbacks most of all the need to have a runtime class present when the editor class gets active the very first time. So the first thing to do is:

Get Rid of The Dummy Runtime Class CurrentBundleVersion at Start

When removing CurrentBundleVersion all type references in code have to be removed. At the very first time Unity Editor gets active after installation, there is no CurrentBundleVersion class at all. On the other hand after the first creation we have to refer to the last version. So let’s use reflection to tackle this problem:

Assembly assembly = Assembly.Load ("Assembly-CSharp");
Type type = assembly.GetType (ClassName);
if (type != null) {
    System.Object lastVersionObject = Activator.CreateInstance (type);
    FieldInfo fieldInfo = type.GetField ("version");
    string lastVersion = (string)fieldInfo.GetValue (lastVersionObject);
}

In order to use Activator.CreateInstance we need to have a non static class. So the code generation logic has to be changed in order to provide an instantiatable class. Version check at runtime now looks different, something like

if (new CurrentBundelVersion () == PlayerSettings.bundleVersion)

Now the initial dummy file CurrentBundleVersion.cs can be removed and the project can be integrated as git submodule.

Including some code to improve stability, I created a branch reflection_version for those who definitely doesn’t need history tracking.

Version Tracking – The Idea

In the simple solution from part (1) I just compared the version string from generated class with the one from PlayerSettings. If they are unequal, the class got replaced or from a semantic view the content of the version field. My vision was kind of feedback loop to preserve the old information and append the new version strings:

Versions Growing over Time
Version 1st Version 2nd Version 3rd Version 4th Version 5th Version 6th Version
Current 0.8.1 0.8.2 0.8.3 0.8.4 0.8.4a 0.8.4.1
Previous 0.8.1 0.8.2 0.8.3 0.8.4 0.8.4a
0.8.1 0.8.2 0.8.3 0.8.4
0.8.1 0.8.2 0.8.3
0.8.1 0.8.2
0.8.1

So if you just changed the version in player settings to be 0.8.4, a regeneration of TrackedBundleVersion is triggered. When recreating the file older versions 0.8.1, 0.8.2 and the previously active 0.8.3 are written to the new file so that they can be accessed from callers. Thus old code can rely on that they are available in future relases if not deleted manually.

Another important feature is transforming version strings into constants that can be referred from code so that potential problems are moved to compile time as much as possible. What I am thinking of is at least:

string versionFromPlayerPrefs = PlayerPrefs.GetString(myKey);
if (String.Compare (versionFromPlayerPrefs, TrackedBundleVersion.Version_0_8_3) < 0) {
    // migrate settings to comply with version 0.8.3
}

Depending on the compare method this could fail when “0.8.4a” is compared to “0.8.4.1” so even better would be to provide an internal compare method to avoid pitfalls like this one. Thus it would be better to encapsulate version strings within a class together with an index which acts as unique identifier for sequence of all tracked versions. So it would be easier to provide appropriate compare methods.

 

Version Tracking – The Implementation

The first requirement could be fulfilled by integrating the data read from current version into the generating process. If the history is stored in an ArrayList, it could be read and the new version from PlayerSettings.bundleVersion could be appended. A string constant is generated for all previous version to provide access from runtime classes.

In order to provide a smooth comparison the version strings are wrapped in separate class TrackedBundleVersionInfo which contains not only the version string but the index within the version history as well. Furthermore it defines a lot of convenience methods like overloaded comparison operators. It is read from a template located as text file in Editor/BundleVersionChecker directory so it is easy to maintain it.

To provide a simple version optionally I delegated code generation to exchangeable implementations of AbstractBundleVersionGenerator and left a SimpleBundleVersionGenerator.

The resulting version is available in the master branch of BundleVersionChecker on github

In Part (3) I will show you how to use BundleVersionChecker.

Comments are closed.

Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu Mehr
By continuing to use the site, you agree to the use of cookies. More

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close