First of all, thanks a bunch for your efforts!
That mustve been 200 commits within the last 2 to 3 days... Crazy π₯ π
I also want to thank @vanessas97 for the amazing new UI.
That really blew me away! π₯
Your new approach is really understandable (besides the visual row stuff I guess, but I can't think of a workaround either) and was nearly fully mvvm compliant! My PR does the last bit necesarry to decouple View and ViewModel further.
This PR makes it so that all data updating is done in the viewModel.
The View only uses the data provided now.
At first glance I thought it would be easy to do this, but then I ran into the same issue with having to redraw paths that u likely ran into aswell.
I managed to solve this by using the publish-subscribe mechanicsm of mvvmFx instead of listening to the valueProperty of the frame slider.
In the new solution this method is invoked every time the slider property changes.
This also improves performance, since previosuly the data was updated as many times as the difference between the old and the newFrame.
Now only the visuals are updated as needed, the data is updated just once per frame change.
Other minor adjustments
Removed PlayerDataRow. Player already had the fields we required for this. Seeing as I ran into some import issues, I'm guessing you did aswell and thats why it didnt work. (It thought u passed type globalmodel.cbrshooter.Player instead of our model :smile:)
Use lambda expressions for initializeEventListenersForRow. This is a preference question, which is why I changed it only in the last commit. If you prefer anonymous classes here, we can just remove the last commit from the PR :)
New update method that is invoked every time the slider property changes.
private void onDataUpdated(String message, Object[] payloadObjects) {
var payload = (DataUpdatedPayload) payloadObjects[0];
var newRound = payload.getNewRound();
var oldRound = payload.getOldRound();
if (newRound != oldRound) {
for (Player player : players)
player.resetPath();
}
var oldFrame = payload.getOldFrame();
var newFrame = payload.getNewFrame();
if (newFrame < oldFrame) {
while (newFrame < oldFrame) {
roundStartIndex = viewModel.getRoundStartIndex(newRound);
for (Player player : players) {
var positionsForInterval = viewModel.getPlayerPositionsForInterval(player.getName(),
roundStartIndex, newFrame);
player.redrawPath(positionsForInterval, coordinateHelper);
}
updateMapElements();
oldFrame--;
}
} else {
while (newFrame > oldFrame) {
updateMapElements();
oldFrame++;
}
}
updateMapElements();
}
First of all, thanks a bunch for your efforts! That mustve been 200 commits within the last 2 to 3 days... Crazy π₯ π I also want to thank @vanessas97 for the amazing new UI. That really blew me away! π₯ Your new approach is really understandable (besides the visual row stuff I guess, but I can't think of a workaround either) and was nearly fully mvvm compliant! My PR does the last bit necesarry to decouple View and ViewModel further.
This PR makes it so that all data updating is done in the viewModel. The View only uses the data provided now. At first glance I thought it would be easy to do this, but then I ran into the same issue with having to redraw paths that u likely ran into aswell. I managed to solve this by using the publish-subscribe mechanicsm of mvvmFx instead of listening to the valueProperty of the frame slider.
In the new solution this method is invoked every time the slider property changes. This also improves performance, since previosuly the data was updated as many times as the difference between the old and the newFrame. Now only the visuals are updated as needed, the data is updated just once per frame change.
Other minor adjustments
globalmodel.cbrshooter.Player
instead of our model :smile:)initializeEventListenersForRow
. This is a preference question, which is why I changed it only in the last commit. If you prefer anonymous classes here, we can just remove the last commit from the PR :)New update method that is invoked every time the slider property changes.