Collections

[jonborchardt]

How would you handle storing the data ofr a collection of items..
Say you data is an array of balls... all moving with physics... and you want events when they touch each other.

this is not exacty what im building, but it will answer the general question of how to have a model that is a collection.

Thank you!

[SamuelAsherRivello]

Hi @jonborchardt. Great question.

Here is one solution, written in pseudocode.

Let's assume that BounceMini is the main app.

• The BounceModel holds the list of all balls, BEFORE you create them as GameObjects. In a VERY simple demo, with Ball GameObjects already in the Scene, you can skip this step.
• The BounceView holds a reference to all Ball GameObjects. Or even better, holds a list of type Ball. Ball is a custom class that extends MonoBehaviour. This can be a masterlist that you use to spawn the GameObjects. Or this list can be lazy, created after, based on whatever balls are already in your Scene using something like GameObject.Find(). Each Ball class dispatches a custom OnHit() UnityEvent. The View loops through and subscribes to all OnHit() and broadcasts its own custom OnBallHit() UnityEvent
• The BounceController subscribes to BounceView.OnBallHit and handles the consequence.

The reason the list may exist in the BounceModel or the BounceView is because MonoBehaviour (and subclasses) are not purely View nor purely controller, nor purely Model. Each MonoBehaviour (and subclasses) is actually a combination of Model/View/Controller Depending on how you use it. So you can put it in the View or in the Model depending on how you choose to structure things.

Experiment with one approach (such as the above approach) and see how it feels. Remember the guiding principle is to separate your concerns so your project is more readable, scaleable, and maintainable. Its a subjective art, not an exact science.

Which way did you solve it? Do you like your result?

[jonborchardt]

Thank you for your reply. Your solution does indeed address my original query. However, my real issues turned out to be more complex. Each ball has its own set of data that I hoped to store in its 'own' model. Unfortunately, the current generic system you have seems to prohibit multiple instances of a model.

To address this, I believe I need to hold the data in a dictionary indexed by the ball ID. However, this approach diminishes the value of the existing event system, as I need to manually pass all events.

I want to do something like this:

public class ToysMini : Mini.Context.IMiniMvcs
{
    public List<UnitView> UnitViews { get; private set; }
    public List<UnitModel> UnitModels { get; private set; }

    private Mini.Context.Context _context;
    private ToysController _toysController;
    private bool _isInitialized;

    public ToysMini(List<UnitView> unitViews, List<UnitModel> unitModels)
    {
        _unitViews = unitViews;
        _unitModels = unitModels;
    }

    public void Initialize()
    {
        if (!_isInitialized)
        {
            _isInitialized = true;

            // Context
            _context = new Mini.Context.Context();

            // Controller
            _toysController = new ToysController(_unitViews, _unitModels);

            // Initialize Models
            _unitModels.ForEach(model => model.Initialize(_context));

            // Initialize Views
            _unitViews.ForEach(view => view.Initialize(_context));

            // Initialize Controller (init this main controller last)
            _toysController.Initialize(_context);
        }
    }
}

However, I cannot create more than one model because Context.ModelLocator.AddItem(this) ends up causing an error if a model of the same type is registered.

How would you adapt your code to handle multiple balls, each with many attributes, where altering one of the balls triggers events only for that specific ball, and also have a wrapper that knows when any ball has changed?

I believe I could make the above work if the model locator was not based solely on type.

[SamuelAsherRivello]

Great info.

Let's see. Instead of calling Context.ModelLocator.AddItem(this) as you mentioned, have you considered Context.ModelLocator.AddItem(this, key)?

See Locator.cs.

Would that help resolve your issue?