Ideal design pattern for contact list/roster download/synchronization in a Messenger library

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("billy@bob.com"); //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.

Answer 2

Each Contact has an own Contact List.

public class Contact
{
  List<Contact> Contacts;
}

Each Contact has its own Events (PropertyChanged, LoggedIn, whatever)

public class Contact
{
  List<Contact> Contacts;
  public event OnPropertyChanged;
}

If Contact logs in, this Contact registers to all Events of each Contact in his Contact List.

public void LogIn
{
  //Load Contact List for User - Do other stuff
  foreach(Contact c in Contacts)
    c.PropertyChanged += new PropertyChangedEventHandler(ContactPropertyChanged);
}

Now if something happens in the Contact List, the ones who are LoggedIn and have this Contact in there List, will get the Event.

public void ChangeProperty
{
  //Change Property and raise event!
}

Answer 3

I believe that you need to take a look on the States design pattern. Consider that the client has a different state each time like:

Login state in this state some special events will be generated like LoginFailed or LoginSucceed and also this state will provide only one method Login.

Chatting state where the user will accept the messages and send them to the group.

And whatever you need.

So you client class will implement the Special state listener interface which will generate the valid event ( event is just a interface's method call ).

In this way you will separate the logic of the different states in the different classes. You will change the states internally in your current state so the user of your library will not be able to make any hack and make your library to work wrong.

I think that it is the best solution for the asynchronous communication implementation. Consider two state machines in client and server side.

Actually it is a lot of code so I just gave you the concept.

http://en.wikipedia.org/wiki/State_pattern

Answer 4

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

So if I get this straight, you want to queue all events that occur on a given Contact's contacts, while the first is offline? So Contact A has Contact B in his contact list, but Contact A is offline at this time. Now Contact B changes his profile, and you want to queue that event (ContactNameChanged and so on) for Contact A?

I wouldn't do it that way. I'd rather store some kind of sync-token (a datetime would be fine) which indicates when Contact A has received Contact B's data. Every Contact then has a LastModified property, which you compare to your sync-token. If some modification has been made since your last sync, do a request to get full details of the modified Contact.

For deleted contacts, you could just intersect two lists. One with the contact list the client thinks is its current list, and one up-to-date list from the server. Comparing those to will lead to additions and deletions, and while looping through this list you can also compare above mentioned LastModified-datetimes.