This question already has answers here:
Simple event system in Unity
(2 answers)
Closed 6 years ago.
I'm writing a game in Unity3D, and I'm wondering if I should be using events -- or some other construct entirely -- instead of delegates for my web requests.
At certain points in the game's lifecycle, we need to call out to a REST API and await its response. Consider a UI screen that retrieves a list of your friends, and displays the number of friends, along with an entry for each friend. Currently, the workflow looks something like this, using Action delegates as parameters to the various methods of my Server class:
class FriendsUI : MonoBehaviour
{
[SerializeField]
private Text friendCount; // A Unity Text component
private void OnStart()
{
Server.GetFriends(player, response => {
ShowFriendList(response.friends);
});
}
private void ShowFriendList(List<Friend> friends)
{
this.friendCount.text = friends.Count.ToString();
// Display friend entries...
}
}
The Server.GetFriends method does an HTTP request to our REST API, gets the response, and calls the delegate, returning the response and control to FriendsUI.
This usually works just fine. However, if I closed the friends UI screen before the delegate is called, the friendCount component -- and any other component in the class, for that matter -- has been destroyed, and an NPE is thrown trying to access it.
Knowing that, do you think C#'s event system be a better design for this? Server would expose something like a FriendsEvent event, and FriendsUI would subscribe to it. At the point when Server has validated/transformed the response, it would raise the event. FriendsUI would also clean up after itself and unregister the handler when the GameObject on which the script has been attached is destroyed/disabled. That way, at the point the event is raised in Server, if the event handler is no longer valid in FriendsUI, it just wouldn't get called.
I'm just trying to run this through in my head before implementing it, because it would end up becoming a somewhat large refactor. I'm looking for guidance as to whether or not people think it's a good route to go, if there are any other routes that might turn out better, and any pitfalls I might run into along the way.
Thanks, as ever, for your time.
Simply use C# delegate and event. Make each script that wants to be notified when friends list is received from the server to subscribe to the event.
public class FRIENDSAPI : MonoBehaviour
{
public delegate void friendListReceived(List<FRINDSINFO> _friends);
public static event friendListReceived onFriendListReceived;
//Function that gets friends from the network and notify subscribed functions with results
public void getFriends()
{
StartCoroutine(getFriendsCoroutine());
}
private IEnumerator getFriendsCoroutine()
{
List<FRINDSINFO> friendsFromNetwork = new List<FRINDSINFO>();
/*
NETWORK CODE
//FILL friendsFromNetwork with Result
friendsFromNetwork.Add();
*/
//Make sure a function is subscribed then Notify every subscribed function
if (onFriendListReceived != null)
{
onFriendListReceived(friendsFromNetwork);
}
yield return null;
}
}
Then in your FriendsUI class, subscribe in the Start() function and unsubscribe in the OnDisable() function. You usually subscribe in the OnEnable() function but sometimes it doesn't work because things don't initialize on time. Doing it in the Start() function is a fix for that.
public class FriendsUI: MonoBehaviour
{
void Start()
{
//Subscribe
FRIENDSAPI.onFriendListReceived += onFriendsReceived;
FRIENDSAPI friendAPI = gameObject.GetComponent<FRIENDSAPI>();
friendAPI.getFriends(); //Get friends
}
public void OnDisable()
{
//Un-Subscribe
FRIENDSAPI.onFriendListReceived -= onFriendsReceived;
}
//Call back function when friends are received
void onFriendsReceived(List<FRINDSINFO> _friends)
{
//Do Whatever you want with the result here(Display on the Screen)
}
}
Related
We have a script attached to an object that has a VideoPlayer and some video. We want to know (be subscribed to) when the video ends, so we can decide then to play another or do something else.
void Start()
{
videoPlayer.loopPointReached += Method();
}
VideoPlayer.EventHandler Method()
{
Debug.Log("it ended");
return null;
}
And the log is not coming out when the video ends.
The reference to videoPlayer exists, and the video plays, pauses and stops with no issues.
We find solutions that include counting frames and so on, but we're hoping for a more elegant solution.
Your code is written wrong. Actually this code is the same if you write videoPlayer.loopPointReached += null;. So you subscribe null for loopPointReached event. You messed up event handler delegate with its signature return type. Your code should look like this, I suppose:
void Start()
{
videoPlayer.loopPointReached += Method; // do not call method with '()', but just subscribe it for event
}
// here the signature of the method corresponds to VideoPlayer.EventHandler delegate,
// that is void(VideoPlayer)
private void Method(VideoPlayer source)
{
Debug.Log("it ended");
}
You can check signature of this delegate in Unity docs https://docs.unity3d.com/2017.2/Documentation/ScriptReference/Video.VideoPlayer.EventHandler.html
Also you can read move about events in this topic How to make a keypress form event in C#
I've been having trouble with using delegates and events in Unity. I am familiar with subscribing and unsubscribing.
The problem i have is a stack overflow exception. However my Console outputs another message while not even in playmode. I am confident this log is tied to the stackoverflow exception, because it happened at the same time.
What is also curious, is that the error just started happening, without me touching that part of the code for a while. I changed nothing in the subscribing of the event.
Note that i had this exact same problem earlier in another project and ended up ditching event subscription.
Do note, i am not talking about the UnityEvent. I'm talking about the scripting delegate & event.
Here is the definition of the delegate and event code:
public delegate void gameStart();
public event gameStart OnGameStart;
public delegate void gameEnd();
public event gameEnd OnGameEnd;
Here is a subscriber:
public override void OnInitialize()
{
GameManager.Instance.OnGameEnd += StopSound;
GameManager.Instance.OnGameStart += PlaySwipeClip;
}
public void PlaySound(AudioClip clip, bool doNotStopCurrent = false)
{
if (doNotStopCurrent)
{
popupAudioSource.clip = clip;
popupAudioSource.Play();
// AudioSource.PlayClipAtPoint(clip, Vector3.zero, 1f);
}
else
{
mainAudioSource.clip = clip;
mainAudioSource.Play();
}
}
public void PlaySwipeClip()
{
mainAudioSource.clip = SwipeClip;
mainAudioSource.Play();
}
I Only subscribe to the events once (I use the singleton pattern, OnInitialize() is called in Awake()).
I am positive that the subscription does not happen twice.
I never unsubscribe to the events. Reason for this is that I use the same scene and "Manager" objects for the entire app's lifecycle.
Is there something I am missing here? Should i unsubscribe in the OnDestroy?
Somehow i have a feeling that subscriptions are persistent between the lifecycles. The error goes away for a while when i rename the event variable.
Also I have tried setting all the events to null explicitly in the awake method, however this does not seem to resolve anything.
You have to unsubscribe otherwise you will leak memory. It is recommended to subscribe OnEnable() and unsubscribe OnDisable().
I am trying to understand events and delegates and after 2 days of studying, it looks like I am still lost in basic understanding.
I wrote following code - class UserControl contains event definition. It works well, although the program is stucked in Start() method.
How for example buttonClick event is implemented? Does button object running in some kind of different thread - on order to be able to call a method whenever the button is clicked?
Thanks
class UserControl
{
public delegate void methodsControlDelegate();
public event methodsControlDelegate methods;
public void Start()
{
while (true)
{
if (methods != null)
{
Thread.Sleep(1000);
this.methods();
}
}
}
}
class Program
{
static void Main()
{
UserControl uc = new UserControl();
uc.methods += eventMethod;
uc.Start();
}
public static void eventMethod()
{
Console.WriteLine("EVENT METHOD");
}
}
EDIT:
I have modified the code for Windows Forms.
class Writer
{
public string Text { get; set; }
public void writeMessage(object sender, EventArgs e)
{
MessageBox.Show(Text);
}
}
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
UserControl userControl = new UserControl();
Writer writer = new Writer();
userControl.WriteMessages += writer.writeMessage;
writer.Text = "HELLO, HOW ARE YOU";
}
}
class UserControl
{
public delegate void EventHandler(object sender, EventArgs e);
public event EventHandler WriteMessages;
}
I am trying to understand events and delegates and after 2 days of studying, it looks like I am still lost in basic understanding.
Take a step back.
class Customer
{
private string name;
public string Name { get { return this.name; } }
public Customer(string name)
{
this.name = name;
}
}
A property is logically a property of the class of things. Customers have a name, so Customers have a property Name.
A field is an implementation detail. It is a variable that can store a value.
A type is an implementation detail of a field or property; it gives you a restriction on what kind of data can be used as a value for this property.
The value -- say "Barbara Smith" -- is the value associated with that property for a particular customer: new Customer("Barbara Smith").
If that is not all clear then you need to take a step back and understand that. You won't get events and delegates if you haven't got properties, fields and values down.
An event is like a property. It is a logical feature of a class of things. Buttons can tell you that they are clicked, so Click is an event of Button. The button will call you when it is clicked.
A delegate type is a restriction on how the button may call you when it is clicked.
A delegate instance is a delegate to a particular function that will be called when the button is clicked.
Is that now clear?
How for example buttonClick event is implemented?
Understanding that requires you to understand how Windows works.
Every Windows program has a message queue which receives messages from the operating system. When the user clicks a button, Windows puts a message in the queue for that process that says the button was clicked. When the process handles that message, taking it out of the queue, it invokes the delegate associated with the click handler for the button.
Does button object running in some kind of different thread - on order to be able to call a method whenever the button is clicked?
Nope. If you hang the UI thread of your program so that it cannot remove the message from the queue then the button click handler is never invoked.
In fact it is illegal to call code in the button from any thread other than the UI thread.
Every time you've seen a Windows app hang, it's almost certainly because some badly-written code did not allow the message loop to take a message out of the queue in a timely manner.
You then go on to post some code with no explanation and no question. I don't know why you posted that code. Try asking a more clear question.
That said, looking at the code you seem to be trying to do event handling from a console application. Don't do that. Console applications are not event-driven. Write a WinForms or WPF application if you want to make an event-driven application.
delegate is an encapsulation on top of a method. It allows you to pass a method around, as a reference and execute it whenever you decide. The delegate defines a signature of a method and any method which is of the same signature can be used as that delegate.
events are one more level of encapsulation, this time on top of delegates. It allows adding and removing (subscribing and unsubscribing) methods to it. And when the event fires, it will invoke each one of the added to it methods (delegates). This encapsulation is necessary, so that one 'client' of the event cannot override another client to the same event.
I have a web service with two methods:
RetrieveFirstLevelOptions() and RetrieveSecondLevelOptions(int levelOneOption).
The GUI contains two comboBoxes: FirstLevelOptionsCombo and SecondLevelOptionsCombo.
I am having trouble with creating a control flow for the initialization stage when I have to make a request to RetrieveFirstLevelOptions() and then, once the results are in, call RetrieveSecondLevelOptions(default levelOneOption = 0).
The problem is that since everything happens asynchronously I don't know what the best approach is to allow this behaviour take place once and only once, at the beginning.
An option I would love to have is to attach a second event handler to the RetieveFirstLevelOptionsCompleted event and have it remove itself after running only once. But it looks like such a behaviour is impossible to get.
Another option would be to have a boolean flag to indicate whether in Initialization phase and if it is, then the handler for RetrieveFirstLevelOptionsCompleted would execute some additional logic. However this idea makes it look like all event handlers would have to check for state information and do different things depending on the current state. This seems to be bad design because the control flow seems to be descentralized.
I want to have a centralized control flow mechanism that will make the decisions in one spot. But how can this be done when everything is executed asynchronously?
"An option I would love to have is to attach a second event handler to the RetieveFirstLevelOptionsCompleted event and have it remove itself after running only once. But it looks like such a behaviour is impossible to get."
Is there some reason this isn't working:
class Example
{
SomeWebService myService;
Example()
{
// do stuff
myService.RetrieveFirstLevelOptionsCompleted += MyHandlerMethod;
}
void MyHandlerMethod(object sender, RetrieveFirstLevelOptionsCompletedEventArgs e)
{
// do stuff
myService.RetrieveFirstLevelOptionsCompleted -= MyHandlerMethod;
// potentially attach next event handler for all subsequent calls
myService.RetrieveFirstLevelOptionsCompleted += MyHandlerMethod2;
}
}
The pattern that I usually use in a situation like this is to create a wrapper around the Async web service proxy method that accepts a callback method. The callback method then gets passed to the RetrieveFirstLevelOptionsAsync() method like so:
public void RetrieveFirstLevelOptions(Action callback)
{
client.RetrieveFirstLevelOptionsAsync(callback);
}
void client_RetrieveFirstLevelOptionsCompleted(object sender, AsyncCompletedEventArgs e)
{
var callback = e.UserState as Action;
if (callback != null)
{
callback();
}
}
So when you call RetrieveFirstLevelOptions(), you just pass the callback that you want to run only once, and you don't ever have to worry about it getting called multiple times. Presumably you'd put your call to RetrieveSecondLevelOptions() within that callback.
What is the best design decision for a 'top-level' class to attach to an event to a class that may be '5+ layers down in the callstack?
For example, perhaps the MainForm has spawned an object, and that object has spawned a callstack of several other object calls. The most obvious way would be to chain the event up the object hierarchy, but this seems messy and requires a lot of work.
One other solution ive seen is to use the observer pattern by creating a publically accessible static object which exposes the event, and acts as a proxy between the bottom-level object, and the top-level 'form'.
Any recommendations?
Here's a pseudo-code example. In this example, the MainForm instantiates 'SomeObject', and attaches to an event. 'SomeObject' attaches to an object it instantiates, in an effort to carry the event up to the MainForm listener.
class Mainform
{
public void OnLoad()
{
SomeObject someObject = new SomeObject();
someObject.OnSomeEvent += MyHandler;
someObject.DoStuff();
}
public void MyHandler()
{
}
}
class SomeObject
{
public void DoStuff()
{
SomeOtherObject otherObject = new SomeOtherObject();
otherObject.OnSomeEvent += MyHandler;
otherObject.DoStuff();
}
public void MyHandler()
{
if( OnSomeEvent != null )
OnSomeEvent();
}
public event Action OnSomeEvent;
}
If your application isn't based on Composite UI Application Blocks, the easiest solution is to put a "listener" class between Main form and your other components which both classes can easily access. Conceptually, the classes are laid out as follows:
---------- ----------------
| MainForm | | Some Component |
--------- ----------------
| |
Hooks onto Notifies
| |
\ /
-----------------
| Proxy Notifier |
-----------------
Here's some example code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
FakeMainForm form = new FakeMainForm();
form.CreateComponentAndListenForMessage();
Console.ReadKey(true);
}
}
class FakeMainForm
{
public FakeMainForm()
{
Listener.AddListener(MessageRecieved);
}
void MessageRecieved(string msg)
{
Console.WriteLine("FakeMainForm.MessageRecieved: {0}", msg);
}
public void CreateComponentAndListenForMessage()
{
ComponentClass component = new ComponentClass();
component.PretendToProcessData();
}
}
class Listener
{
private static event Action<string> Notify;
public static void AddListener(Action<string> handler)
{
Notify += handler;
}
public static void InvokeListener(string msg)
{
if (Notify != null) { Notify(msg); }
}
}
class ComponentClass
{
public void PretendToProcessData()
{
Listener.InvokeListener("ComponentClass.PretendToProcessData() was called");
}
}
}
This program outputs the following:
FakeMainForm.MessageRecieved: ComponentClass.PretendToProcessData() was called
This code allows you to invoke methods directly on any listener, no matter how far apart they are in the call stack.
Its easy to rewrite your Listener class so that its a little more generic and works on different types, but you should get the idea.
My initial intention would be to try and avoid that, so that an object's scope has obvious boundaries. In the particular case of Forms, I would attempt to have the child's parent form manage all required communications withs its ancestors. Can you be more specific about your case?
My first thought is that from your MainForm's perspective, it should have no idea what is going on 5 levels down. It should only know about its interactions with the object that it spawned.
With that, if you main form wants to perform some action asynchronously, it should be able to do that by calling a method on the spawned object asynchronously.
Now from your spawned object's point of view, if you allowed your caller to perform some method asynchronously, there's no need to push the event model further down... just call the methods directly down the stack. You're already on another thread.
Hopefully that helps a little. Just remember the levels of your app should only be aware of what goes on in the level immediately below them.
WPF uses routed events. These are static and can bubble up or tunnel down the element tree. I don't know if you are using WPF, but the idea of static events might help you out.
I wouldn't say this is a design fault, there are valid reasons for the main form to want to listen to what an object is doing. One scenario I've encountered is displaying status messages to the user to indicate what background processes are doing, or what multiple controls are doing in a multi-threaded app that lets you have multiple screens/"pages" open at once.
In the Composite UI Application Block, the basic equivalent of a dependency injection container wires up events when its instantiating objects in the same work item (a work item is just an object container for a group of related user controls). It does this by scanning for special attributes such as [EventPublication("StatusChanged")] on events and [EventSubscription("StatusChanged")] on public methods. One of my applications uses this functionality so that a user control instantiated way down in the innards of the application can broadcast status information (such as "Loading customer data...45%") without knowing that that data is going to end up in the main form's status bar.
So a UserControl can do something like this:
public void DoSomethingInTheBackground()
{
using (StatusNotification sn = new StatusNotification(this.WorkItem))
{
sn.Message("Loading customer data...", 33);
// Block while loading the customer data....
sn.Message("Loading order history...", 66);
// Block while loading the order history...
sn.Message("Done!", 100);
}
}
...where the StatusNotification class has an event with the a signature like
[EventPublication("StatusChanged")]
public event EventHandler<StatusEventArgs> StatusChanged;
... and the above Message() and Dispose() methods on that class invoke that event appropriately. But that class didn't explicitly have that event hooked up to anything. The object instantiator will have automatically hooked up the events to anybody with a subscription attribute of the same name.
So the MainForm has an event handler that looks something like this:
[EventSubscription("StatusChanged", ThreadOption=ThreadOption.UserInterface)]
public void OnStatusChanged(object sender, StatusEventArgs e)
{
this.statusLabel.Text = e.Text;
if (e.ProgressPercentage != -1)
{
this.progressBar.Visible = true;
this.progressBar.Value = e.ProgressPercentage;
}
}
... or some such. It's more complicated than that since it will rotate through multiple status notifications for a given number of seconds since multiple user controls can be broadcasting status messages around the same time.
So to recreate this behavior without actually switching over to CAB (which, to be honest, is much more complicated than I think it really needs to be), you could either have a MessageNotificationService object that you pass around your application or that you turn into a static/singleton object (I usually avoid this approach since it's harder to test), OR you could have you sub usercontrols be instantiated by a factory class that does the event wiring up for you. Objects could register with the factory by attributes of your own creation or by explicitly calling methods that say "hey, anytime you create an object with an event of this signature, I want to know about it."
Just be careful to have whatever class you implement unhook the events when an object gets disposed because it's stupid easy in this scenario to end up with something that won't get garbage collected.
Hope this helps!