Метод

И GetCities

И GetCities

Не понимаю, оно и так уже параллельно выполняется, в первом случае

.Result убивает всю параллельность

Основной поток ловится, пока не будет этого результата

Основной поток ловится, пока не будет этого результата

Хорошо, а вверху реализация ?

А какую ошибку он выдает?

А InnerException есть?

Это точно не в DataBaseService падает?

Это точно не в DataBaseService падает?

ну он сам по себе внутри еще await парочку имеет

Ну вон написано же. Нет конструктора в LandingPage

Он или приватный, или другой тип принимает

но он есть

А что он принимает?

Так, стопе, я думал эта штука сначала ViewModel где-то цепляет

Сама страница-то пустой конструктор имеет

Вот это проблема века

?

Спасибо, я кажется понял

И ещё. async void лучше не использовать. В этом случае исключения падающие пропадают. Отсюда и непонятки

Вместо этого async Task

А что лучше ?

А пример можно ?

Просто void на Task замени)

? это я могу))

И соответственно везде выше тоже, если есть async void на таски поменять

И соответственно везде выше тоже, если есть async void на таски поменять

ну ошибку он опять не поймал какую надо, но видимо это уже вообще проблема не ассинхронности

ну ошибку он опять не поймал какую надо, но видимо это уже вообще проблема не ассинхронности

Когда студия выдает ошибку жми продолжить и после закрытия приложения на Андроиде в output отобразится ошибка, стектрейс

Когда студия выдает ошибку жми продолжить и после закрытия приложения на Андроиде в output отобразится ошибка, стектрейс

Да-да, так и делаю

@BOOMikru Еще вопрос вот есть, как можно заранее кешировать ViewModel с MvvM Light ?

@BOOMikru Еще вопрос вот есть, как можно заранее кешировать ViewModel с MvvM Light ?

Не работал с mvvm light

И ещё. async void лучше не использовать. В этом случае исключения падающие пропадают. Отсюда и непонятки

честно, я устал бороться против этой дичи. меняем на async Task и что? И все не падает но тред падает и проглатывается. Пользователь жмет на кнопку и ничего не происходит. Класс. Супер

Здесь нужно правильно подойти к отлову эксепшнов

не try catchить глобально, а только те методы которые могут упасть. Соответственно внутри async void метода если этот метод может завершиться непредвиденно делаем try catch

в случае с таском если мы хотим глобально во всех тасках перехватывать эксепшны и хотя бы знать что упало и отправлять эту инфу в хокей-апп например - надо в виде экстеншна прикручивать ещё дополнительный ContinueWith с параметром OnFaulted

меня если честно задолбала эта дичь с async void. Где-то вычитали и давай распространять

меня если честно задолбала эта дичь с async void. Где-то вычитали и давай распространять

Не дичь вовсе это, воид по сравнению с таском разные в этом плане.

в таске любой выпавший эксепшн крэшит таск

в async void методе любой выпавший эксепшн возврашяется в управление UI треда или треда вызвавшего async void метод

в UIтреде аппа падает

и пусть себе падает в тех методах где гарантированно они должны завершиться без исключений.

хокейапп это подхватит, пошлет репорт и будет известно где проблема

в случае если просто так упадет таск - ничего не будет известно. Где упало? Что упало? Аппа работает, но ничего не происходит.

в async void методе любой выпавший эксепшн возврашяется в управление UI треда или треда вызвавшего async void метод

щас по твоей логике таск просто закроет аппку и нифига ты эксепшена не получишь, а с воидом все збс ибо он могущий.

нет, надо правильно подходить к отлову эксепшнов

и падение таска не закрывает аппку как раз. аппка живет. Но ничего не делает. и непонятно что произошло

нет, надо правильно подходить к отлову эксепшнов

за это никто и не спорит, хендить поверхностно не правильно

ну так и переделывать все на async Task это тоже не правильно

только где это возможно и нужно

ну очевидно что async Task нужно делать методы которые будут awaitятся в других методах. Но корневой метод из которого возможен уход в бэкграунд - async void. В нем в зависимости от необходимости - например мы читаем файлы и мы знаем по документации что асинхронные методы чтения/записи могут завершиться с исключением - берем и ловим их try catch и обрабатываем. А например если мы делаем таски в которых происходит какая-то калькуляция чего-то и эксепшнов в этих методах быть не должно то так же как и в первом случае используем без сомнений async void в корневом методе и try catch не пишем. Если вдруг там упало с out of range или null reference - мы должны про это знать на этапе разработки и тестирования. Пусть аппа падает.

Вот с этого места поддержу. Например, async void можно вызвать из конструктора. Но суть не в этом, а в том что ловить исключения надо всегда по месту возникновения. Банально ждать пробитого стэка не надо - прямой путь к мемори ликам

ну очевидно что async Task нужно делать методы которые будут awaitятся в других методах. Но корневой метод из которого возможен уход в бэкграунд - async void. В нем в зависимости от необходимости - например мы читаем файлы и мы знаем по документации что асинхронные методы чтения/записи могут завершиться с исключением - берем и ловим их try catch и обрабатываем. А например если мы делаем таски в которых происходит какая-то калькуляция чего-то и эксепшнов в этих методах быть не должно то так же как и в первом случае используем без сомнений async void в корневом методе и try catch не пишем. Если вдруг там упало с out of range или null reference - мы должны про это знать на этапе разработки и тестирования. Пусть аппа падает.

ты описал две разные задачи, которые вообще не идентичны, воид можно юзать никто не запрещает это делать, тем более я же говорю что таски нужно юзать там где им место и когда нужно, например при использовании апи, ибо таски позволяют гибче решить такие задачи. А то что ты юзаешь асинк воид, та пожалуйста, я же не против) Спорить по этому поводу можно очень долго, на практике и те и те решения получают применение.

А по отлавливанию ошибок, спорить не буду все верно сказано, хендлить только в проблемном месте, нет смысла хендлить там где шишка не вылезет.

“юзать там где им место и когда нужно, например при использовании апи” Правильно. Апи возвращает результат. void же означает что мы результата в методе не ожидаем)

Коллеги, такой вопрос. Извиняюсь что не по теме Xamarin. Может ли кто нить дать поглядеть какое нить ТЗ на разработку мобильного приложения. Меня больше интересует, указываете ли вы какие разрешения экранов поддерживает мобильное приложение?

не указываем... делаем резиновые...

Да, указывать ключевые разрешения обязательно

главное указать минимальные платформы...

Да, указывать ключевые разрешения обязательно

А можешь пример привести абзаца как вы описываете разрешения экранов?

2.1 Требования к дизайну мобильного приложения Дизайн мобильного приложения должен быть создан с учетом требований компаний Google и Apple для Android и iOS, отраженным в соответствующих руководствах. Дизайн необходимо разработать для разрешений экранов: 640х1136 пикселей (iPhone) 1536 x 2048 пикселей (iPad) 1080x1920 пикселей (смартфоны на базе Android) 1080x1920 пикселей (планшеты на базе Android) Дизайн должен поддерживать возможность автоматического масштабирования для различных разрешений целевой операционной системы без потери функциональности и пользовательских характеристик. Дизайн необходимо разработать только для портретного (вертикального) расположения экрана. Приложения для планшетов также должны поддерживать работу при альбомной (горизонтальной) ориентации экранов. Дизайн должен полностью соответствовать стилистике целевой операционной системы.

и отдельным пунктом указываем эталонный список устройств

на которых приложение будет тестироваться при приемке-сдаче

а то клиенты хитрые, всю плеш проесть могут, если на каком-нибудь рутованом корявом Android проблемы будут

ух. я бы такое не подписал)

ERROR: S client not available

это выработалось за годы, с нормальными клиентами проблем нет ;)

т.е это хорошие требования но недостаточные. я бы их дополнил

это лишь часть :)

это же не все ТЗ

я бы заменил разрешения экрана на форм факторы и плотности экранов

дизайнер потом голову сломает :)

а так - вот тебе формат выходных картинок от дизайнера

не. дизайнер не должен быть таким) дизайнер должен быть мобильным

т.е понимать как все устроено

3.1.2 ТТТ для пользовательского приложения Android Пользовательское приложение Android должно поддерживать следующие версии операционных систем: Операционная система Android 4.1 - 6.0 Работа приложения на других версиях операционных систем, не включенных в список, возможна, но не гарантирована. Приемка-сдача результатов работ должна осуществляться на следующих устройствах, работающих под управлением официальных версий прошивок операционных систем от самих производителей данных устройств (эталонный список устройств Android): Google Nexus 5 Samsung Galaxy A5 Samsung Galaxy S6 Micromax Q415 (предоставляется Заказчиком на весь период тестирования) Goolge Nexus 7 Google Nexus 10 Samsung Galaxy Tab A В случае возникновения ошибок на устройствах, не входящих в список эталонных, Исполнитель проводит техническую экспертизу, и если ошибка была допущена по вине Исполнителя, то осуществляется ее устранение. Если ошибка связана с особенностями или недостатками самого устройства или его операционной системы, то Исполнитель не обязан устранять выявленную ошибку.

и верстать под 16:9 в векторе с указаниями как должны растягиваться элементы

это по эталонному списку устройств

Спасибо за разъяснения.

это по эталонному списку устройств

ну и его постоянно менять?

вышел гнусмас s8 - надо его в договоры внести

да, немного менять. зависит от клиента и проекта

зачем?

мы входим в проект и выходим из него на понятных условиях

ну а почему s6 эталонный а s8 нет?

потому что пример старый

я как клиент хочу все топовые устройства считать эталонными

я как клиент хочу все топовые устройства считать эталонными

ну, на момент подписания договора пусть будет список какой-то эталонных. А если проект затянется и вышли новые, и что-то не так, то есть описанный список устройст. Остальное новой сметой

мы входим в проект и выходим из него на понятных условиях

Это правильно

короче у нас тоже выработаны определенные требования и в этих требованиях мы пишем соотношения сторон под который верстается дизайн и указываем максимальную и минимальную плотность экрана. На ios и андроид максимальная и минимальная она одинаковая - максимум xxhdpi или @3x, минимум mdpi или @1x(может меняться в сторону xhdpi @2x). Соотношения сторон 16:9 на смартфонах, 4:3 на планшетах.

отдельно для ios можем обговорить устройства и обычно это ограничивается “саппортим iphone 4 или нет”. Уже как правило нет. И все

Тоже приблизительно подобный набор оговорок

ну отдельно можем прописать список устройств который есть у нас и который есть у заказчика на которых все это будет тестироваться

но нигде не указывам что вот на такой модели аппа должна работать, а на всех остальных - нет

ну отдельно можем прописать список устройств который есть у нас и который есть у заказчика на которых все это будет тестироваться

возьму на заметку. спасибо

и главное все решение оно основано на том что производители договорились что в принципе они будут стараться делать смартфоны 16:9 и планшеты 4:3. И статистика по количеству девайсов разного формфактора она говорит о том что это самые распространенные. 16:10 ещё есть и появился 18:9 - но они больше 16:9 - один в длину другой в ширь поэтому их можно отдельно не описывать. А дизайнер должен верстать все под базовые соотношения с пониманием того как все это будет растягиваться

так и живем

так и живем

Спасибо. Ценные советы