в вашем случае я вообще работающего варианта не вижу

идёт подписка в подписке какая-то

Чет прям какой-то холивар начался

https://pastebin.com/Xb05AenB вот реализация с XLabs с поддержкой ObservableCollection

какая оптимизация? что тут неоптимизированно? какой костыль?

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

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

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

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

мы тут о частном случае. И в данном случае подписка на изменения коллекции нужна во вью.

Послушай голосовое я там всё объясняю

Послушай голосовое я там всё объясняю

без наушников, сори

Писать долго

Писать долго

понимаю, подруга также иногда делает

мы тут о частном случае. И в данном случае подписка на изменения коллекции нужна во вью.

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

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

Дело не в том что подписка в подписке а в том как ты с этим работаешь если ты вовремя подписываешься и вовремя отписывайся то никакой проблемы в этом нет

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

При изменении коллекции идт подписка на изменения в ней. Главное не забывать от старой отписываться.

понял, изначально про отписку не сказали

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

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

а какой еще вариант? через вью модель отправлять различные события?

понял, изначально про отписку не сказали

ну если есть подписка, то должна быть и отписка. Это закон)

вчера вышла версия XF 3.2 уже успели затестить?)

вчера вышла версия XF 3.2 уже успели затестить?)

А ты рисковый товарищ...

А ты рисковый товарищ...

риск - мое второе имя

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

Кинь сверху BoxView ?

Кинь сверху BoxView ?

шмешно

Бэджика?

Положить в свой грид внутри вью не помогает?

Положить в свой грид внутри вью не помогает?

делал со StackLayout. Как в Gride второй столбик растянуть на всю ширину? Звездой?

Да

Если первый авто, а второй * - будет первый размером с контент (как wrap_content в ведре), а второй растянется (как match_parent)

Там пилят абсолютно новый API для формсов: https://github.com/xamarin/Xamarin.Forms/issues/2415

Привет, ребят, есть способо исправить эту ошибку без переустановки всех пакетов по новой ? Error java.lang.IllegalArgumentException: already added : Lcom/google/android/gms/iid/MessengerCompat;

Там пилят абсолютно новый API для формсов: https://github.com/xamarin/Xamarin.Forms/issues/2415

это 3.2, что ли?

Если первый авто, а второй * - будет первый размером с контент (как wrap_content в ведре), а второй растянется (как match_parent)

не, не работает это( при этом в андроид все ок

не, не работает это( при этом в андроид все ок

покажи код xaml

погоди... а где грид?

делал со StackLayout. Как в Gride второй столбик растянуть на всю ширину? Звездой?

не этот вопрос разве? Типа с грид, как на всю ширину сделать

не этот вопрос разве? Типа с грид, как на всю ширину сделать

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

А... разве есть из коробки вообще такая возможность?

Можно просто спрятать навибар и отрисовать свое с событиями по нажатию. Топорные вариант, но рабочий.

Можно просто спрятать навибар и отрисовать свое с событиями по нажатию. Топорные вариант, но рабочий.

да не, это извращение. вообще Майкрософт допилил кастомный бар (ну почти допилил ?)

Там пилят абсолютно новый API для формсов: https://github.com/xamarin/Xamarin.Forms/issues/2415

Давно уже же, и это больше как предложение, спорное предложение Это не то, что даже новый API, а вообще новый подход к созданию

Мне кажется, в формс сейчас слишком много всего. По сути хватит парсера XAML + пары базовых классов для элементов. Остальное - пусть снаружи доставляют

Мне кажется, в формс сейчас слишком много всего. По сути хватит парсера XAML + пары базовых классов для элементов. Остальное - пусть снаружи доставляют

+

Можно просто спрятать навибар и отрисовать свое с событиями по нажатию. Топорные вариант, но рабочий.

Ох, не надо такого предлагать

Мне кажется, в формс сейчас слишком много всего. По сути хватит парсера XAML + пары базовых классов для элементов. Остальное - пусть снаружи доставляют

Entry, label, button?

Entry, label, button?

Ну главное FrameworkElement, чтобы биндинги всякие и т.п.

И привести наконец все имена к привычному виду

TextBox, TextBlock, DependencyProperty ?

И привести наконец все имена к привычному виду

что за "привычный вид"?

ну хз, не вижу проблем в расширении формс

TextBox, TextBlock, DependencyProperty ?

TextBox, TextBlock - вообще не привычно) Это не UWP)

TextBox, TextBlock, DependencyProperty ?

привычные кому? uwp, android, ios? не на много ли стульев сразу сесть надо?

TextBox, TextBlock - вообще не привычно) Это не UWP)

UWP, WPF, Silverlight, WP - везде у MS были такие наименования

По сути XF - единственный XAML фреймворк с другим именованием

Да даже в cshtml5 правильно скопировали

По сути XF - единственный XAML фреймворк с другим именованием

по сути xamarin - не microsoft продукт изначально и верстка сделана на основе мобилок, и названия из мобилок, в частности из iOS

да там солянка сейчас из имён: Label из iOS, RelativeLayout из ведра

по сути xamarin - не microsoft продукт изначально и верстка сделана на основе мобилок, и названия из мобилок, в частности из iOS

+

Это же не M$ продукт, они его недавно относительно выкупили.

UWP, WPF, Silverlight, WP - везде у MS были такие наименования

Xamarin'овцам было не до нейминга UWP/WPF/etc.

по сути xamarin - не microsoft продукт изначально и верстка сделана на основе мобилок, и названия из мобилок, в частности из iOS

XF - очевидно продукт в первую очередь для WPF/WP/UWP разработчиков, которые хотят расширится еще и на другие платформы

Это всё равно что сделать продукт ориентированный на веб-разрабов, но вместо <a> сделать какой-нибудь <link>

ERROR: S client not available

Можно конечно, но уменьшает возможности шаринга кода и вносит лишнюю путаницу

С чего вдруг xf ориентирован на wpf/WP/uwp?..

С того что это C#+XAML

XF - очевидно продукт в первую очередь для WPF/WP/UWP разработчиков, которые хотят расширится еще и на другие платформы

Это майки так стали позиционировать и я не совсем согласен с этой позицией.

Зачем вообще брать XAML, если не для ориентации на существующих XAML-девелоперов?

С чего вдруг xf ориентирован на wpf/WP/uwp?..

ну UWP ожидаемо, а WPF недавно опционально добавили там

изначально XF был с поддержкой WinPhone 8

UWP лишь на замену пришёл

Это майки так стали позиционировать и я не совсем согласен с этой позицией.

Ну у этой позиции есть одна серьезная проблема: маппинг в натив вместо отрисовки всего в шаблонах, что резко делает XF непохожим на другие XAML фреймворки (кроме наверное cshtml5)

Но в целом это всё равно +- так

Вот с обычном Xamarin понятно что дела обстоят иначе и в целом он больше для нативщиков, которые хотят шарить код, чем для мигрантов с других WPF/UWP

Вот с обычном Xamarin понятно что дела обстоят иначе и в целом он больше для нативщиков, которые хотят шарить код, чем для мигрантов с других WPF/UWP

Ну там вообще скорее просто обёртка нативных API/SDK/etc. на шарпе

И еще мне кажется, gesture recognizers надо выкинуть из XF

Они нравятся только iOSникам

И еще мне кажется, gesture recognizers надо выкинуть из XF

А как по-другому сделать тап с командой?

События

У событий же есть обработчики add/remove - там всё можно смапить в натив как сейчас в методах делают

События

То есть писать в Page обработчики и вызывать из ViewModel методы?

Жесты это чисто про View, что там дальше будет - в целом всё равно

То есть Вы предлагаете делать как я написал?

Не обязательно. Если нам надо что-то вызвать из VM - вызываем, если нет - не вызываем

Ну вот допустим есть кнопка У нее есть Command и Click Соответственно команда и событие Вместо того, чтобы просто забиндить команду к VM, вы предлагаете делать обработку события в Page и вызывать метод из VM Что нарушает сам паттерн mvvm Или я чего-то не понимаю)

Причем тут команды?)

Я именно про замену Gesture Recognizers

Не обязательно. Если нам надо что-то вызвать из VM - вызываем, если нет - не вызываем

- Что можешь делать? - Могу копать. - А еще? - Могу и не копать. А как вызывать - напрямую вызывать из View методы во ViewModel? Нормально с gesture recognizers работать. Достаточно удобный механизм, хорошо работает с MVVM. Свайпы - ну их часто на уровне вью обрабатывать, да. Можно оставить только скелет от формс, но тогда придется самому всё писать, а надо ли?

GestureRecognizer использует команды

Я именно про замену Gesture Recognizers

а зачем менять то, что и так хорошо работает?

Затем что везде не так. Это снижает удобство при переключении с одного фреймворка на другой и шаринг кода и вообще в чем профит?

GestureRecognizer использует команды

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

Если бы все всё делали как везде, мы бы ещё жили в 1980

Менять можно. Если это дает хоть какие-то преимущества и остальные потом подтянутся