Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin fails to work if CountlyManager.Init is called from an Awake #1

Closed
cakeus opened this issue Jun 30, 2014 · 4 comments
Closed

Comments

@cakeus
Copy link

cakeus commented Jun 30, 2014

Because the order of the CountlyManager awake and any other awake is undefined. The result is the already initialized CountlyManager getting destroyed by it's own Awake.

@imkira
Copy link
Owner

imkira commented Jun 30, 2014

Hi @cakeus thanks for spotting that one!

b9bcaff

I released this under v0.0.2. Does this solve the problem you mentioned?

Best regards

@cakeus
Copy link
Author

cakeus commented Jun 30, 2014

Looks good, I think you want to move the DontDestroyOnLoad outside the check you added, otherwise the bug originally reported will still occur if the user calls LoadLevel later on.

@imkira
Copy link
Owner

imkira commented Jul 1, 2014

Wow, missed that one! Thanks for pointing it out.

2e58a9a

I think the best would be to call an initializer method both from the Instance property and from the Awake method for the case where a user calls LoadLevel during overall Awake and before CountlyManager's own Awake gets fired.

SomeObject.Awake()
{
  CountlyManager.Instance.Emit(....);
  Application.LoadLevel(...);
}

if SomeObject's Awake gets fired before CountlyManager's, In theory LoadLevel is synchronous so _instance exists for a while (due to the cal to CountlyManager.Instance) but then I guess since I don't do any DontDestroy when I call the Instance property the Awake doesn't get to run and therefore the manager object doesn't manager to survive.

Anyway, I don't think many people would do such kind of thing so it looks good enough to me.
Let me know if you think it would be best to protect against that case too.

@cakeus
Copy link
Author

cakeus commented Jul 2, 2014

I think your completely correct that the initializer needs to be called on the Instance property (when it creates a new instance lazily ). I'm going to close this issue though.

@cakeus cakeus closed this as completed Jul 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants