Ideell design mønster for kontaktliste / vaktliste nedlasting / synkronisering i en Messenger bibliotek

stemmer
3

Det er et Pålogging funksjon på en MessengerClient klasse. Den MessengerClient klasse har en logg hendelse og en IsLoggedIn eiendom.

Når Login kalles på MessengerClient klasse kontaktlisten / roster hentes via et uttak fra en fjerntliggende server og behandlet, og deretter Kunden anses logget inn, og IsLoggedIn vil returnere sann. Den logg hendelsen oppstår inne i Pålogging funksjon etter dette (og dermed inne i samme tråd ber om påloggings - som jeg ikke tror er en dårlig ting).

Når du er logget inn, får kunden live oppdateringer fra den eksterne serveren som de oppstår.

Ved behandling kontaktliste / vaktliste under innlogging Jeg tror den ideelle design for sluttbrukeren er å ha alle kontaktliste / vaktliste data behandles før klienten anses logget inn. På denne måten når brukeren mottar logg arrangementet, er de i stand for å få tilgang til kontakt data umiddelbart.

For eksempel -

Her har vi sluttbrukerens behandleren for logg hendelsen.

    void MsgrLoggedIn(object sender, EventArgs a)
    {
        _msgr.Contacts.Contains(billy@bob.com); //returns true
    }

Siden alle i kontaktlisten har blitt behandlet før klienten er merket som logget på, og før logg arrangementet har blitt hevet, går over utsagnet sant. Logisk Jeg tror dette er hva sluttbrukeren forventer, som laster ned og behandling kontaktlisten er en del av påloggings drift.

Nå, jeg liker også å heve hendelser når en kontakt er lagt til i kontaktlisten, eller lagt til en gruppe. Går av logikken jeg har nevnt så langt, selvsagt er det ingen mening å heve ContactAdded , ContactAddedToGroup osv hendelser som dataene blir behandlet, da dette vil føre til at sluttbrukeren som mottar en av disse hendelsene før MessengerClient klassen er enda merket som blir logget inn.

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

Hvilke som vist ovenfor, vil resultere i dårlige ting skjer.

Så det jeg egentlig trenger å gjøre er å behandle kontaktliste data, heve logget inn hendelsen, og deretter heve alle andre kontakt hendelser etterpå.

For dette kan jeg bare iterere over alle kontakt objekter, gruppe objekter, etc .. og heve de aktuelle hendelsene.

Greit så langt, ikke sant?

Problemet er imidlertid at i tillegg til å laste ned kontaktlistedata ved første pålogging, jeg må også være forberedt på å synkronisere kontaktdata hvis klienten er logget av og deretter logge tilbake igjen.

Dette vil innebære arrangementer som ContactRemoved, ContactNameChanged, ContactRemovedFromGroup etc.

Så det er ikke lenger fullt så enkelt som itera over kontakter, grupper, osv, fordi nå må jeg ta hensyn til kontakter som har blitt fjernet eller som har hatt sine egenskaper endres.

Så jeg trenger en alternativ måte å kø disse hendelsene skal heves etter innlogging har funnet sted.

Jeg har vurdert å ha klasser for å representere hver av synkroniserings hendelser - f.eks .. SyncContactRemoved, SyncContactNameChanged, SyncContactAddedToGroup. Med denne kan jeg behandle data, og lage en Sync * XXX * klasse for hver hendelse og legge dem til en liste som jeg kan deretter gjenta etter innlogging.

Jeg har også vurdert å ha metoder på objektene selv. dvs. Group.SyncContactsAdded, Contact.SyncNameChanged, MessengerClient.SyncContactsAdded. Da kunne jeg iterere over kontakter / grupper osv etter innlogging, sjekk disse egenskapene, heve hendelser om nødvendig, og deretter fjerne dem.

Endelig har jeg vurdert å ha en hendelse klasse som inneholder en Event og EventArgs. Hendelsene kan være kø på denne måten, og deretter startes en etter en etter innlogging.

Om noen, hvilke av disse mønstrene ville bli betraktet som mer vanlig praksis. Eller er det et alternativ betyr å oppnå dette?

Jeg beklager så lang spørsmålet, men det er ikke et enkelt spørsmål.

Takk

Publisert på 10/04/2012 klokken 09:58
kilden bruker
På andre språk...                            


4 svar

stemmer
0

Jeg endte opp med å lagre hendelsene i en liste og oppdra dem etter.

List<SomethingEventArgs> events;

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

Det er ikke så glamorøst som jeg hadde håpet, men det gjør mye fornuftig, og det fungerer perfekt.

Svarte 26/04/2012 kl. 01:17
kilden bruker

stemmer
0

Jeg tror at du trenger å ta en titt på statene design mønster. Tenk at klienten har en annen stat hver gang slik ut:

Pålogging stat i denne tilstanden noen spesielle hendelser vil bli generert som LoginFailed eller LoginSucceed og også denne tilstanden vil gi kun én metode innlogging.

Chatting tilstand hvor brukeren vil godta meldinger og sende dem til gruppen.

Og uansett hva du trenger.

Så du klient klassen vil implementere Spesial tilstand lytteren grensesnitt som vil generere gyldige hendelse (event er bare et grensesnitt metode samtale).

På denne måten vil du skille logikken i de ulike stater i de ulike klassene. Du vil endre statene internt i din nåværende tilstand, slik at brukeren av biblioteket ikke vil være i stand til å gjøre noen hack og gjøre biblioteket for å jobbe galt.

Jeg tror at det er den beste løsningen for asynkron kommunikasjon gjennomføring. Betrakt to tilstandsmaskiner i klient og server side.

Egentlig er det mye kode, så jeg bare ga deg konseptet.

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

Svarte 19/04/2012 kl. 09:05
kilden bruker

stemmer
0

hvilke av disse mønstrene ville bli betraktet som mer vanlig praksis. Eller er det et alternativ betyr å oppnå dette?

Så hvis jeg får dette rett, vil du stå i kø alle hendelser som oppstår på en gitt Kontakt kontakter, mens den første er offline? Så Kontakt A har kontakt B i sin kontaktliste, men Kontakt A er ikke på dette tidspunktet. Nå Kontakt B endrer sin profil, og du vil kø den hendelsen ( ContactNameChangedog så videre) for kontakt A?

Jeg ville ikke gjøre det på den måten. Jeg vil heller lagre en slags sync-token (en datetime ville være fint) som indikerer når Kontakt A har fått Kontakt B data. Hver kontakt har da en LastModifiedeiendom, som du sammenligner med synkroniserings-token. Hvis noen modifikasjoner har blitt gjort siden forrige synkronisering, gjør en anmodning om å få alle detaljer om den modifiserte Contact.

For slettede kontakter, kan du bare krysse to lister. En med kontaktlisten klienten mener er dagens liste, og en up-to-date liste fra serveren. Sammenligning de som vil føre til tilgang og avgang, og mens looping gjennom denne listen kan du også sammenligne nevnte LastModified-datetimes.

Svarte 18/04/2012 kl. 09:37
kilden bruker

stemmer
0

Hver kontakt har en egen kontaktliste.

public class Contact
{
  List<Contact> Contacts;
}

Hver kontakt har egne arrangementer (PropertyChanged, logg, uansett)

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

Hvis Kontakt logger inn, denne kontaktregistre til alle Hendelser til hver kontakt i sin kontaktliste.

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

Nå hvis noe skjer i kontaktlisten, vil de som er logg og ha denne kontakten der List, få Event.

public void ChangeProperty
{
  //Change Property and raise event!
}
Svarte 14/04/2012 kl. 12:01
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more