Pull to refresh

Comments 8

Выглядит красиво, спору нет. Профессионально и модно. Вот только помогает ли это пользователю?

Допустим, пользователь попал на эту картинку. Это значит, что его запрос не может быть исполнен или новостей нет. Сколько времени ему нужно продираться через остроумные картинки и политкорректные вежливые фразы, чтобы понять, что случился облом?

Хотя эффект подслащения горькой пилюли может и сработать раз или два за счёт таких трюков, в конце концов человек всё равно приспособится быстро понимать, что случилось. И модный читающий газету мужичок на картинке будет раздражать не менее, чем пустой экран.
Паттерн все равно хороший
Для обоих случаев — и если нет новостей, и если случилась ошибка.
Многие интерфейсы реально плохо отображают, что раздел пуст, можно воспринять пустой список как некую ошибку.
Единственное, что стоило улучшить — это подсказку к ошибке. Пользователю действительно ни холодно ни жарко от сообщения об ошибке, необходимо объяснить ему, что сделать
— Сервер не доступен, проверьте интернет-соединение и повторите попытку (и кнопка повторить)
— На сервере произошла ошибка. Наши специалисты разбираются в проблеме, попробуйте зайти позже.
Да, согласен, в первую очередь, конечно, стоит бороться с первоисточником проблемы (в случае ошибки обработки запроса)
Но данная вьюха, в случае отсутствия данных (к примеру, для нового пользователя, который еще не начал взаимодействие с приложением) — выглядит в любом случае и приятней, чем просто пустой экран, и подсказывает, что пользователю вообще на этом экране стоит в будущем ожидать.
В случае ошибки — я согласен, тут есть смысл доработать, и например, замапить текст/текст и картинку на тот же код ошибки, и выводить более user-friendly сообщение, с уточнением причины, и подсказками, что он бы мог в данном случае сделать.

Нарисовали бы просто текущий момент.

Наиболее популярный, и часто встречающийся — MvvmCross. Работает как и с Xamarin Native, так и с Forms.
От себя бы порекомендовал еще FlexiMvvm. Но он исключительно для Xamarin Native. Не очень популярный, но намного ниже порог входа, чем у Cross, и менее тяжеловесный.
Есть еще MVVM Light, но с ним не работал, потому не могу ничего сказать.
Для скрытия View Вы в ViewModel используете метод SetViewModel который имеет прямую ссылку на View(?).
Разве MVVM не говорит о том, что ViewModel не должна знать о View? Мне интересно почему Вы поступили так
Не совсем так. Метод SetViewModel — это метод вьюхи, который мы использовали для кастомного биндинга, и биндили соотвественно EmptyStateViewModel/ErrorStateViewModel из родительской вью-модели, на этот метод.
Сам кастомный биндинг я сюда не выносил, так как он все равно будет разничаться для всех mvvm-фреймворков.
А прописывали биндинг EmptyStateViewModel/ErrorStateViewModel вью-модели на этот метод SetViewModel естественно, в родительской вьюхе, потому ViewModel ничего не знала о View.
По сути, вместо медота SetViewModel можно попросту биндить на проперти ViewModel у вьюхи, и в set прописать соответствующую логику с ViewVisibility.
Sign up to leave a comment.

Articles