寻找有关如何在MVVM C＃Xamarin中实现“ volume”属性的建议

Question

So I am developing an app that can adjust (amongst other things) the volume of a device. So what I started with was a very simple Model which implements INotifyPropertyChanged. There is no need for a ViewModel in such a simple scenario as far as I can tell. INPC is called when the volume property is set, and the Model generates a TCP message to tell the device to change the volume.

However, this is where it gets complicated. The volume does not have to be changed by the app, it could also be changed directly on the device, or even by another phone with the app. The only way to get these changes from the device is to poll it periodically.

So what I think is reasonable is to change the structure a bit. So now I have a DeviceModel which represents the actual device. I add a VolumeViewModel. The DeviceModel class now handles generating the TCP messages. It also periodically polls the device. However, lets say the DeviceModel finds that the volume changed. How should this propagate back to the VolumeViewModel such that all changes are two-way both from the UI, and from the actual device? If I put INPC in the DeviceModel, it seems my VolumeViewModel becomes superfluous. Perhaps for this simple contrived example that's fine, but lets say the device is more complicated than just 1 volume. I was thinking the VM could contain a reference to the Model, and the volume property could just be a reference to the volume in the DeviceModel but it still doesn't really solve my problem.

If the DeviceModel volume changes, the reference isn't changing, so it seems to me this would not trigger the setter function for the volume property in the VolumeViewModel. Do I have the ViewModel inject an event handler into the Model to be called when polling sees a different volume? Do I use INPC in both (what would implementing it that way look like?)

Answer 1

Set direction is clear. And you want to get it explicitly. So we need something like

class MyDeviceService : IDeviceService
{
    public async Task SetVolumeAsync(int volume) { }
    public async Task<int> GetVolumeAsync() { }
}

// ViewModel
class DeviceViewModel : INotifyPropertyChanged
{
    public int Volume { get{ ... } set { ... } }
    public DeviceViewModel(IDeviceService service) { ... }
}

For the update you have different options:

Callback

Pro:

• Easy to implement

Con:

• only one subscriber
• looks like a bad implementation of events (in our scenario)

class MyDeviceService
{
    public Action<int> VolumeChangedCallback { get; set; }
    public async Task SetVolumeAsync(int volume) { }
    public async Task<int> GetVolumeAsync() { }

    // producer
    VolumeChangedCallback(newVolume);
}

// consumer
myDeviceService.VolumeChangedCallback = v => Volume = v;

// deregistration
myDeviceService.VolumeChangedCallback = null;

Event

Pro:

• Language feature (built in)
• Multiple subscribers

Con:

• ???

class MyDeviceService
{
    public event EventHandler<VolumeChangedEventArgs> VolumeChanged;
    public async Task SetVolumeAsync(int volume) { }
    public async Task<int> GetVolumeAsync() { }

    // producer
    VolumeChanged(new VolumeChangedEventArgs(newVolume));
}

// consumer
MessagingCenter.Subscribe<MyDeviceService, int>(this, 
     MyDeviceService.VolumeMessageKey, newVolume => Volume = newVolume);

// needs deregistration
MessagingCenter.Unsubscribe<MyDeviceService, int>(this, 
    MyDeviceService.VolumeMessageKey, newVolume => Volume = newVolume);

Messaging

Pro:

• Easy Sub / Unsub
• Multiple subscribers
• Multiple senders
• Receiver does not need to know the sender

Con:

• external library needed (but included in Xamarin.Forms , MvvMCross, other MvvM Frameworks)

class MyDeviceService
{
    public static string VolumeMessageKey = "Volume";
    public async Task SetVolumeAsync(int volume) { }
    public async Task<int> GetVolumeAsync() { }

    // producer
    MessagingCenter.Send<MyDeviceService, int>(this, 
        VolumeMessageKey, newVolume);
}

// consumer
MessagingCenter.Subscribe<MyDeviceService, int>(this, 
     MyDeviceService.VolumeMessageKey, newVolume => Volume = newVolume);

// needs deregistration
MessagingCenter.Unsubscribe<MyDeviceService, int>(this, 
    MyDeviceService.VolumeMessageKey, newVolume => Volume = newVolume);

Observable

Using Reactive extensions is always nice, if you have event streams.

Pro:

• Easy Sub / Unsub
• Multiple subscribers
• Filterable like IEnumerable (eg Where(volume => volume > 10) )

Con:

• external library just for one case
• high learning effort due totally new approach

class MyDeviceService
{
    IObservable<int> VolumeUpdates { get; }
    public async Task SetVolumeAsync(int volume) { }
    public async Task<int> GetVolumeAsync() { }
}

// consumer
_volumeSubscription = myDeviceService.VolumeUpdates
                          .Subscribe(newVolume => Volume = newVolume);

// deregistration
// - implicitly, if object gets thrown away (but not deterministic because of GC)
// - explicitly:
_volumeSubscription.Dispose();

Conclusion

I left out INPC in the model, because that's events but worse, because you have to compare the property names. If you have a look at these examples, you see, that they just differ in the way you subscribe and unsubscribe. The main difference is the flexibility they offer. Personally, I'd go for Reactive Extensions ;) But Events and Messaging are fine, too. So go for the approach that you and your team members understand the best. You just have to remember:

ALWAYS deregister! ^^

Answer 2

I am presuming that you intend to show a UI to the user that displays the current volume (such as a slider widget). Therefore your real challenge is the fact that any attempts to manipulate that slider cannot be immediately confirmed - it may take some time for the device to respond, and once it does it may not even accept the request (or might be overridden by local manipulation). Yet you still have a need to show the mobile app user that their request is being processed - or else they will assume it is malfunctioning.

I've had to solve this in an app as well - although my example was a much more complicated situation. My app is used to control large installations of irrigation management hardware, with many devices (with varying versions of firmware and varying degrees of remote control capabilities). But ultimately the problem was the same. I solved it with standard MVVM.

For each device, create a viewmodel that tracks two distinct values: the actual last known (reported) status of the hardware, and any "pending" value that may have been recently requested by the app. Bind the visual controls to the "pending" values via standard INPC bindings. In the setters for those values, if the new value differs from the last known hardware status, then it would trigger an async request to the device to transition to the desired status. And for the rest of the time, you just poll the device status using whatever mechanism makes sense for you (push notifications might be better, but in my case the infrastructure I was working with could only support active polling). You would update with the new hardware status values, and also the pending values (unless a different value was already pending).

In the app UI, you probably want to show the actual hardware status values as well as the "pending" values that the user is allowed to manipulate. For sliders, you might want to implement a "ghost" slider thumb that reflects the reported hardware value (read-only). For switches, you might want to disable them until the hardware reports the same value as the pending value. Whatever makes sense for your app's design language.

This leaves the final edge case of how to deal with situations where the hardware does not (or cannot) respect a request. Perhaps the user tries to turn up the volume to 11 when the device can only go up to 10. Or maybe someone presses a physical pushbutton on the device to mute it. Or maybe someone else is running the mobile app and fighting you for control of it. In any event, it is easily solved by establishing a maximum wait timeout for pending manipulations. For example, any volume change requests that aren't met after 10 seconds are assumed to be pre-empted and the UI would just stop waiting for it by setting the pending value = last reported value.

Anyhow, good luck! It's a challenging thing to handle well, but worth the effort!