Лучший подход для вызова веб-сервиса (или аналогичного) с MvvmCross

Question

В последнее время я размышлял над этим, и я надеялся, что кто-то, кто лучше знает MvvmCross, чем я, может пролить свет на это. Учитывая нюансы между каждой мобильной платформой, возможно, есть несколько разных факторов, которые могут повлиять на эту проблему. Но для этого сценария предположим, что нам нужен лучший подход для кросс-платформенного решения.

Итак, предположим, что у нас есть базовый вид и установка класса ViewModel. Вот пример iOS.

Посмотреть

public partial class FirstView : MvxViewController<FirstViewModel> 
{ 
    public FirstView(IntPtr handle) : base(handle) 
    { 
    } 

    public override void ViewDidLoad() 
    { 
     Request = new MvxViewModelInstanceRequest(FirstViewModel.NewInstance()); 
     base.ViewDidLoad(); 
    } 
} 

вид Модель

public class FirstViewModel : MvxViewModel 
{ 
    public static FirstViewModel NewInstance() 
    { 
     return Mvx.IocConstruct<FirstViewModel>(); 
    } 

    public FirstViewModel() 
    { 
    } 
} 

Теперь при загрузке этого View или в какой-то момент как раз перед вид создается мы хотим загрузить некоторые данные из сеть с использованием услуги, которую мы вводим с использованием инъекции зависимостей; потому что отображение представления зависит от этих данных. Здесь кроется проблема .. в какой точке с точки зрения платформы и в жизненном цикле MvvmCross было бы наиболее подходящим местом для вызова функции веб-выборки в сервисе.

Что касается платформы, я бы предположил, что мы должны сделать это, как только будет загружен вид. Потому что, если извлеченные данные - это нечто иное, чем простые типы данных, будет неудобно работать с Android, так как нужно было бы перенести данные на диск и получить их после навигации из-за сериализации между действиями.

Так что предположим, что мы вызвали веб-выборку во время процесса загрузки вида. Где лучшее место в архитектуре MvvmCross, чтобы скрыть это, наиболее точно следует парадигмам дизайна. например Модель просмотра. Есть ли какие-либо методы жизненного цикла, которые кто-то мог бы рекомендовать, чтобы вызвать его внутри. Что-то вроде метода Start, вызванного после создания модели представления.

Answer 1

Прежде всего, я не понимаю, почему вы не позволяете самой платформе создавать экземпляр и делать это жизненным циклом ViewModel вместо создания нового экземпляра ViewModel с использованием Mvx.IocConstruct. Этот метод не вызывает жизненный цикл ViewModel и не будет называть No Init или Start на ViewModel.

Если вы позволите платформе сделать это для вас, сначала вызывается метод Init с аргументами, которые вы задаете при использовании ShowViewModel<T>(args).

При вызове метода ViewDidLoad вызывается метод Start.

Это дает вам два места для вызова Сервиса, который вы вводите в ctor ViewModel.

Если вы хотите больше контролировать, когда загружать данные, вы можете создать некоторую ICommand, которую вы вызываете в ViewModel в любом из методов жизненного цикла ViewController. Это может быть в методе ViewWillDisappear/ViewDidDisappear или вы можете получить данные.

Есть так много способов, которыми вы можете это сделать. В конце концов, это зависит от вас, и вы не можете знать, когда пользователь решит перейти на другой вид. Тем не менее, вы можете сделать квалифицированные догадки и попробовать получить данные до того, как пользователь действительно захочет этого.

Для вас есть read here, by Rob Gibbens on how you could do Resilient network services.В нем описывается, как можно спекулировать выбор ресурсов на основе того, что делает пользователь, и таким образом есть что-то готовое для пользователя, чтобы увидеть, когда он войдет в представление. Это могут быть кэшированные данные или свежие данные, которые вы извлекаете после показа кешированной версии.

В любом случае, я предлагаю вам прекратить загрузку ViewModel с помощью Mvx.IocConstruct и позволить MvvmCross обрабатывать это для вас, чтобы вызвать методы жизненного цикла.