Lifecycle class

[originalfoo]

Currently the lifecycle for TM:PE is completely obfuscated across multiple classes, it's impossible to see at a glance what is going on through the various stages, and it's getting even more confusing now that we're supporting hot reloads, etc.

In #764 I suggested briefly this: #764 (comment)

I think at some point we should consider creating a Lifecycle.cs that contains some sort of state engine for the mod lifecycle management (enabed -> loading -> unloading -> disabled) but that's something for a later date.

Kian then added this: #764 (comment)

I have thought of that but I can't see how it would work.

the only thing I can think of is:

1. move all code from OnEnabled/OnDisabled, LoadingExtension.cs, and SerializeDataExtension.cs to lifecycle.cs
2. then all OnEnabled/OnDisabled, LoadingExtension.cs, and SerializeDataExtension.cs do is to call appropriate functions of lifecycle.cs at appropriate times.

So lifeCycle.cs acts as a wrapper for IUserMod, LoadingExtension, and SerializableDataExtension . A bit ugly if you ask me.

The best thing to do is a mod for hot reload to patch CS so that it does not do weird stuff.

Even if we have mod to patch CS to not do weird stuff, we should still have a more coherent way of managing TMPE lifecycle.

Building on Kian's ideas, I suggest:

1. Lifecycle class gets stub methods for the various states
2. TrafficManagerMod and LoadingExtension (and anything else relevant) simply calls the applicable lifecycle methods
3. Rather than filling lifecycle methods with bloated code, we should atomise funcitonality in to methods in some other class
4. The lifecycle would then just call those other methods

The result would be a very concise lifecycle class and you could just read it to see exactly what steps happen in each stage of the lifecycle without getting bogged down in reams of code.

For example, enabled/disabled stuff in Lifecycle.cs could look something like (rough mockup):

// comment would note all the ways enabled can be triggered, such as:
// * mod autoenabler mod when user subscribes TMPE
// * enabled via content manager > mods
// * already enabled when game starts
// * hot-reload (can happen in-game, main menu, etc)
public void OnEnabled() {
    if (!HotReload) {
        LogEnvironmentDetails();
        PerformCompatibiltyChecks();
    }
}

// comment...
public void OnDisabled() {
    RemoveEventListeners();
    if (HotReload) {
        Patches.Remove();
        ModUI.Remove();
        //...
    }
}

Basically, we should be able to see at a glance wtf is going on without having to wade through gargantuan amounts of code.

The TrafficManagerMod.cs would then be like (rough mockup):

public void OnEnabled() {
    Lifecycle.OnEnabled();
}

public void OnDisabled() {
    Lifecycle.OnDisabled();
}

[originalfoo]

Thanks for fixing the typos! There are too many devs whose name starts with k lol.

[kianzarrin]

Related #730 #731

[originalfoo]

Current progress (removed code comments for sake of brevity) - the stuff from IUserMod is done:

namespace TrafficManager {
    using CSUtil.Commons;
    using ICities;
    using TrafficManager.State;
    using TrafficManager.UI;

    public class Lifecycle { // will eventually be : ILifecycle

        private static Lifecycle instance_;

        public static Lifecycle Instance => instance_ ?? (instance_ = new Lifecycle());

        public void OnEnabled(bool hotLoad) {
            if (hotLoad) {
                Log.Info("HOT RELOAD");
            } else {
                Temp.LogEnvironmentDetails();
            }
        }

        public void OnLocaleChange(string locale) {
            Translation.HandleGameLocaleChange();
        }

        public void OnSettings(UIHelperBase helper) {
            Options.MakeSettings(helper);
        }

        public bool OnCompatibilityCheck() {
            return Temp.CheckCompatibility();
        }

        public void OnDisabled(bool hotUnload) {
            Log.Info("TM:PE disabled.");
        }

    }
}

Hopefully that clearly conveys what happens at those stages of lifecycle. Need to do some minor tidy up then will create draft PR.

The Temp class, as it's name suggests, is just temporary dumping ground for some bits of code (all of that will be replaced by new compatibility checker in #699).

The goal is that the Harmony/Lifecycle mod would call those "lifecycle event handlers", but for now I've got existing IUserMod calling them.