:strip_exif()/u/242341/crop55d72c2ca29b1.gif?f=community)
Ik heb een applicatie die als een server een lijst met gebruikers bijhoudt. De gebruikers kunnen realtime met de server verbinden en ook weer weg gaan.
De server moet aan elke gebruiker een kleurtje toekennen. Je kan het voorstellen als een lijstje met gebruikers waarbij elke gebruiker zijn eigen kleurtje heeft. (Misschien een voorbeeld is een Whatsapp groepsgesprek).
Er zijn echter maar een klein aantal kleuren beschikbaar, voornamelijk omdat de kleuren goed van elkaar te onderscheiden moeten zijn (geel en oranje lijken bijvoorbeeld te veel op elkaar), dus ik heb niet veel kleuren tot m'n beschikking. Het kan dus regelmatig voorkomen dat er meer gebruikers zijn dan er kleuren beschikbaar zijn en dat er dus gebruikers met dezelfde kleur zijn (dat is niet te voorkomen).
Ik wil de kleuren toekennen in de volgorde waarin ik ze definieer. Ik heb dus een lijstje met kleuren op volgorde (bijvoorbeeld rood, groen, blauw), en de kleuren worden in die volgorde toegekend. Komen er dus 3 gebruikers achter elkaar online dan krijgt gebruiker 1 de kleur rood, gebruiker 2 de kleur groen en gebruiker 3 de kleur blauw.
Zodra een gebruiker weg gaat moet die kleur echter weer beschikbaar komen. Stel dat gebruiker 2 weg gaat (groen), en daarna gebruiker 4 verbindt, dan krijgt gebruiker 4 dus de eerst beschikbare kleur (groen). Zodra gebruiker 5 binnen komt zijn er geen kleuren meer over, en krijgt hij weer de eerste kleur uit het rijtje (rood).
Extra eis: Er is echter nog een "eis" die ik graag wil stellen: als er minder gebruikers zijn dan er kleuren beschikbaar zijn, dan mag het nooit voorkomen dat een gebruiker een kleur krijgt die al in gebruik is. Dus: als er twee gebruikers zijn dan krijgt gebruiker 3 altijd een unieke kleur en nooit een die gebruiker 1 of 2 al heeft.
Hoe kan ik dit het beste implementeren?
Het meest kom ik in de buurt met een stack van kleuren. Zodra er een nieuwe gebruiker verbindt pakt hij de eerste kleur van de stack. Zodra een gebruiker vertrekt legt hij de kleur weer terug boven op de stack zodat deze weer beschikbaar komt voor de volgende gebruiker.
Dit werkt prima, maar wat doe ik als de stack leeg is (meer gebruikers dan kleuren beschikbaar)?
De oplossing die ik daarvoor had bedacht is door de stack meerdere keren te vullen met de lijst van kleuren. In plaats van een stack RGB (rood groen) heb ik dus RGBRGBRGBRGB... Ik kan de stack natuurlijk enorm veel groter maken dan er ooit gebruikers zullen zijn.
Op deze manier kunnen er echter problemen optreden. Stel dat ik maar twee kleuren beschikbaar heb (zodat de lijst wat korter is): rood (R) en groen (G). Het kan dan voorkomen dat er straks een gebruiker verbonden is, en dat een tweede gebruiker dan dezelfde kleur krijgt, en dat wil ik niet. Aangezien er maar 1 gebruiker is, moet de andere kleur altijd toegewezen worden aan de andere gebruiker. Dit was mijn extra eis: als er minder gebruikers dan kleuren zijn dan moet een nieuwe gebruiker altijd een unieke kleur krijgen die nog niet in gebruik is.
Voorbeeld: links is de stack (die ik vanaf rechts benader, rechts is dus "boven" en daar haal ik de kleuren weg), rechts is het lijstje gebruikers (eigenlijk de kleur die ze hebben)
Nu heb ik dus een "probleem". Voor de volgende gebruiker die zou verbinden ligt groen boven op de stack, maar er is maar 1 gebruiker verbonden en die heeft al groen. Dit wil ik voorkomen, want nu krijgen beide gebruikers groen, terwijl rood gewoon beschikbaar is.
Zodra er meer gebruikers dan kleuren zijn is het niet te voorkomen dat er dubbele kleuren voorkomen, en het is ook niet te voorkomen dat er tig gebruikers zijn met allemaal 1 kleur (als alle andere kleuren weg gaan), maar zodra er een nieuwe gebruiker komt, en er zijn minder gebruikers dan kleuren, dan wil ik dat die altijd een kleur krijgt die beschikbaar is.
Liefsft heb ik hier een geschikt algoritme voor zonder dat ik met ifs en uitzonderingen ga werrken, maar ik kan het niet vinden... Iemand een idee?
De server moet aan elke gebruiker een kleurtje toekennen. Je kan het voorstellen als een lijstje met gebruikers waarbij elke gebruiker zijn eigen kleurtje heeft. (Misschien een voorbeeld is een Whatsapp groepsgesprek).
Er zijn echter maar een klein aantal kleuren beschikbaar, voornamelijk omdat de kleuren goed van elkaar te onderscheiden moeten zijn (geel en oranje lijken bijvoorbeeld te veel op elkaar), dus ik heb niet veel kleuren tot m'n beschikking. Het kan dus regelmatig voorkomen dat er meer gebruikers zijn dan er kleuren beschikbaar zijn en dat er dus gebruikers met dezelfde kleur zijn (dat is niet te voorkomen).
Ik wil de kleuren toekennen in de volgorde waarin ik ze definieer. Ik heb dus een lijstje met kleuren op volgorde (bijvoorbeeld rood, groen, blauw), en de kleuren worden in die volgorde toegekend. Komen er dus 3 gebruikers achter elkaar online dan krijgt gebruiker 1 de kleur rood, gebruiker 2 de kleur groen en gebruiker 3 de kleur blauw.
Zodra een gebruiker weg gaat moet die kleur echter weer beschikbaar komen. Stel dat gebruiker 2 weg gaat (groen), en daarna gebruiker 4 verbindt, dan krijgt gebruiker 4 dus de eerst beschikbare kleur (groen). Zodra gebruiker 5 binnen komt zijn er geen kleuren meer over, en krijgt hij weer de eerste kleur uit het rijtje (rood).
Extra eis: Er is echter nog een "eis" die ik graag wil stellen: als er minder gebruikers zijn dan er kleuren beschikbaar zijn, dan mag het nooit voorkomen dat een gebruiker een kleur krijgt die al in gebruik is. Dus: als er twee gebruikers zijn dan krijgt gebruiker 3 altijd een unieke kleur en nooit een die gebruiker 1 of 2 al heeft.
Hoe kan ik dit het beste implementeren?
Het meest kom ik in de buurt met een stack van kleuren. Zodra er een nieuwe gebruiker verbindt pakt hij de eerste kleur van de stack. Zodra een gebruiker vertrekt legt hij de kleur weer terug boven op de stack zodat deze weer beschikbaar komt voor de volgende gebruiker.
Dit werkt prima, maar wat doe ik als de stack leeg is (meer gebruikers dan kleuren beschikbaar)?
De oplossing die ik daarvoor had bedacht is door de stack meerdere keren te vullen met de lijst van kleuren. In plaats van een stack RGB (rood groen) heb ik dus RGBRGBRGBRGB... Ik kan de stack natuurlijk enorm veel groter maken dan er ooit gebruikers zullen zijn.
Op deze manier kunnen er echter problemen optreden. Stel dat ik maar twee kleuren beschikbaar heb (zodat de lijst wat korter is): rood (R) en groen (G). Het kan dan voorkomen dat er straks een gebruiker verbonden is, en dat een tweede gebruiker dan dezelfde kleur krijgt, en dat wil ik niet. Aangezien er maar 1 gebruiker is, moet de andere kleur altijd toegewezen worden aan de andere gebruiker. Dit was mijn extra eis: als er minder gebruikers dan kleuren zijn dan moet een nieuwe gebruiker altijd een unieke kleur krijgen die nog niet in gebruik is.
Voorbeeld: links is de stack (die ik vanaf rechts benader, rechts is dus "boven" en daar haal ik de kleuren weg), rechts is het lijstje gebruikers (eigenlijk de kleur die ze hebben)
| Stack | Gebruikers | Actie |
|---|---|---|
| RGRG | - | (start) |
| RGR | G | G connect |
| RG | GR | R connect |
| R | GRG | G connect |
| RR | GG | R disconnect |
| RRG | G | G disconnect |
Nu heb ik dus een "probleem". Voor de volgende gebruiker die zou verbinden ligt groen boven op de stack, maar er is maar 1 gebruiker verbonden en die heeft al groen. Dit wil ik voorkomen, want nu krijgen beide gebruikers groen, terwijl rood gewoon beschikbaar is.
Zodra er meer gebruikers dan kleuren zijn is het niet te voorkomen dat er dubbele kleuren voorkomen, en het is ook niet te voorkomen dat er tig gebruikers zijn met allemaal 1 kleur (als alle andere kleuren weg gaan), maar zodra er een nieuwe gebruiker komt, en er zijn minder gebruikers dan kleuren, dan wil ik dat die altijd een kleur krijgt die beschikbaar is.
Liefsft heb ik hier een geschikt algoritme voor zonder dat ik met ifs en uitzonderingen ga werrken, maar ik kan het niet vinden... Iemand een idee?
:strip_exif()/u/138622/kikker.gif?f=community)
/u/13464/Delphi.png?f=community)
:strip_exif()/u/34748/ferrari_avatar.gif?f=community){kind=avatar}
Bedankt, dat moet inderdaad werken!