ViewModels and GameClient refactoring.

[ST-Apps]

Following ST-Apps/PoGo-UWP#678

[robertmclaws]

So, the short version is this:

Based on my structure proposal, GameClient and related logic would move to the PoGo.GameServices assembly.

We would break GameClient into separate GameServices (or perhaps, GameEngines, if Services confuses the intention), which would be separate instance-based classes that would be self-contained, bindable (implement INPC), and testable.

We would then use Dependency Injection (something like Autofac, perhaps) to handle managing the instance lifecycle of those services, and inject dependent services into each one through the Service constructors.

Services I can see needing right off the bat:

• LocationService (NearbyPokemon collections, as well as abstracted location logic).
• PokedexService (PokemonInventory, PokedexInventory, etc)
• EncounterService (All of the logic for managing an Encounter, likely injecting PokedexService)
• EvolutionService (The logic for managing stardust, candy, and evolution requests)
• HatcheryService (EggsInventory, IncubatorsInventory, etc)
• PlayerService (manage username, level, achievements, appearance, etc).

The best way to manage the interactions with the API would be to create a set of interfaces that the ApiClient implements, and then potentially have another assembly that allows many of those calls to be mocked w/o needing something like this at all. Then, any code needing to use one of these services would pass either the mock Client or the real one into the constructor.

In turn, the ViewModels in the app itself would just accept the services they need in their constructor. The XAML would then be able to bind to those properties on the ViewModel, instead of having bridge properties that don't always get updated as their source collection changes.

As a whole, this structure would reduce code complexity, increase testability, and let people focus on their specific tasks w/o intermingling core gameplay logic with user experience logic. I'll create a branch with a prototype so you all can see what it would look like.

[ghost]

I agree that separating GameLogic from UI is needed. I work mostly on backend, but in this project I am having trouble distinguishing between the GameLogic, becasue some is in the code behind and some is in the ViewModel, which is weird.

Also interactive UI screens need to be separate from simple Views. For example the catching View can become so complex, that 3 or more files manage it, when only one file would do the job. Will also make the job easier if we switch to 3D in the future.

[ST-Apps]

Closing because we agreed on project's structure.