Question

There is a Login function on a MessengerClient class. The MessengerClient class has a LoggedIn event and a IsLoggedIn property.

When Login is called on the MessengerClient class the contact list/roster is fetched via a socket from a remote server and processed, and then the client is considered logged in and IsLoggedIn will return true. The LoggedIn event is raised inside the Login function AFTER this (and thus, inside the same thread requesting the login — which I do not believe is a bad thing).

Once logged in, the client receives live updates from the remote server as they occur.

When processing the contact list/roster during login I believe the ideal design for the end user is to have ALL contact list/roster data processed BEFORE the client is considered logged in. This way, when the user receives the LoggedIn event, they are able to access contact data immediately.

For example –

Here we have the end user’s handler for the LoggedIn event.

    void MsgrLoggedIn(object sender, EventArgs a)
    {
        _msgr.Contacts.Contains("[e-mail]"); //returns true
    }

Since all of the contact list has been processed BEFORE the client is marked as logged in, and BEFORE the LoggedIn event has been raised, the above statement returns true. Logically I believe this is what the end user would expect, as downloading and processing the contact list is part of the login operation.

Now, I also like to raise events when a contact has been added to the contact list, or added to a group. Going by the logic I’ve mentioned so far, it obviously makes no sense to raise the ContactAdded, ContactAddedToGroup etc events as the data is being processed, as this would result in the end user receiving one of those events before the MessengerClient class is even marked as being logged in.

    void MsgrContactAdded(object sender, ContactEventArgs e)
    {
        _msgr.SendMessage(e.Contact, "hello there"); // throws NotLoggedInException
    }

Which as shown above, would result in bad things happening.

So what I really need to be doing is processing contact list data, raising the logged in event, and then raising all other contact events afterwards.

For this I can just iterate over all contact objects, group objects, etc.. and raise the appropriate events.

Fine so far, right?

The problem however, is that in addition to downloading contact list data upon first login, I also have to be prepared to synchronize contact data if the client is Logged out and then logged back in.

This would involve events like ContactRemoved, ContactNameChanged, ContactRemovedFromGroup etc.

So it’s no longer quite as simple as iterating over the contacts, groups, etc, because now I have to take into account contacts that have been removed or which have had their properties changed.

So I need an alternative way of “queuing” these events to be raised after the login has taken place.

I’ve considered having classes to represent each of the synchronization events – eg.. SyncContactRemoved, SyncContactNameChanged, SyncContactAddedToGroup. With this I can process the data, and create a Sync*XXX* class for each event and add them to a list which I can then iterate after login.

I’ve also considered having methods on the objects themselves. ie Group.SyncContactsAdded, Contact.SyncNameChanged, MessengerClient.SyncContactsAdded. Then I could iterate over the contacts/groups etc after login, check these properties, raise events if necessary, and then clear them.

Finally I’ve considered having an Event class which contains an EventHandler and EventArgs. The events could be queued up in this fashion and then invoked one by one after login.

If any, which of these patterns would be considered more common practice. Or is there an alternative means to achieve this?

I apologize for such a long question, but it’s not a simple question.

Thanks

Answer 1

I ended up storing the events in a list and raising them after.

List<SomethingEventArgs> events;

foreach (SomethingEventArgs e in events)
    OnSomethingEvent(e);

It’s not as glamorous as I’d have liked, but it makes a lot of sense and it works perfectly.