Я не фанат SingleLiveEvent
, потому что он ограничен одним наблюдателем, но вы также можете добавить много наблюдателей, так что он может быть подвержен ошибкам.
Но в очень простом сценарии (например, в приложении todo, которое вы упомянули) это может быть лучшим вариантом, чем шаблон оболочки событий.
В сложном сценарии шаблон обертки событий был бы лучшим вариантом, но он также имеет некоторые ограничения. В этой реализации предполагается, что у вас есть только один основной потребитель (см. getContentIfNotHandled
).Итак, я думаю, что работа с несколькими наблюдателями приведет к тому, что шаблон решит, кто из них является основным потребителем или когда мне следует позвонить getContentIfNotHandled
или peekContent
.
Но , все эти ограничения могут быть исправлены с помощью вашей собственной реализации.
Например, вот расширенная версия SingleLiveEvent
, которая поддерживаетнесколько наблюдателей:
public class SingleLiveEvent<T> extends MutableLiveData<T> {
private LiveData<T> liveDataToObserve;
private final AtomicBoolean mPending = new AtomicBoolean(false);
public SingleLiveEvent() {
final MediatorLiveData<T> outputLiveData = new MediatorLiveData<>();
outputLiveData.addSource(this, currentValue -> {
outputLiveData.setValue(currentValue);
mPending.set(false);
});
liveDataToObserve = outputLiveData;
}
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<T> observer) {
liveDataToObserve.observe(owner, t -> {
if(mPending.get()) {
observer.onChanged(t);
}
});
}
@MainThread
public void setValue(T value) {
mPending.set(true);
super.setValue(value);
}
}
Как видите, речь идет не о SingleLiveEvent
против шаблона оболочки событий, все зависит.Лично я использую другие шаблоны (например, шаблоны, существующие в мире React / Flux) для работы с состояниями.
Имейте в виду, что в разработке программного обеспечения нет серебряной пули.