Ради бога, бэкенж тоже весьма интересен, в отличие от фронта

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

ну гет/сет что тут думать. Если нет MVVM то да, это зло. Если MVVM есть то без них никак

orm зло

и об этом не только он говорит. Много от кого это слышал. Тоже согласен

DI нужно аккуратно использовать. 1 класс с регистрацией типов ничем не хуже 1 места где инициализируются все объекты. Ну и не нужно забывать что new всегда будет быстрее

но все равно я бы не смог писать по его принципам. Это выше моих нервов

Гет/сет зло только при условии создания доп. двух методов? Насчет того же ef не вижу причин его не использовать. DI только при условии что new быстрее, я про это тоже писал, но по факту зачастую пытаться экономить несколько мс в медленном дотнете даже смешно

Хотя рефлексия работает наамного медленнее, да

Так что не так с orm в средних проектах?

Гет/сет зло только при условии создания доп. двух методов? Насчет того же ef не вижу причин его не использовать. DI только при условии что new быстрее, я про это тоже писал, но по факту зачастую пытаться экономить несколько мс в медленном дотнете даже смешно

про ef ты упускаешь несколько лет его развития. он идет с бородатых лет времен 3.5 дотнета. Но опять же это не отменяет то что любая ORM это черный ящик, повлиять на генерацию SQL которого ты практически не можешь

ef хорошо расширятся

и об этом не только он говорит. Много от кого это слышал. Тоже согласен

А что злого в маппге?

VS 2017 debug Android 8

Кто-нить победил данную проблему?

Господа, таки что лучше, делать всю навигацию на фрвгментах или разных активити? Что считается более верным?

Господа, таки что лучше, делать всю навигацию на фрвгментах или разных активити? Что считается более верным?

есть ещё 3-я вариация. Навигация с помощью View. Оказывается есть из нативщиков те кто упарывается и так. В принципе способ имеет право на жизнь

Так какой все же лучше и чаще используется?

XamarinForms ушел с фрагментов кстати в навигейшн пэйдже оставив их только на табах и в мастер-детэйле

Какие плюсы/минусы

Так какой все же лучше и чаще используется?

не знаю. Там у каждого подхода ещё куча библиотек тащится)

плюсы-минусы…хм. Ну как по мне мэнеджерить активити сложнее. Да и я люблю 1 активити иметь и в ней весь жизненный цикл обрабатывать

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

Как-то Xamarin не очень ценится на рынке... Иногда посещают мысли идти в натив. Но опыт .net не позволяет бросить все

не ценится потому что пришла на хайпе херова туча народа и когда у них нихера не получилось нормального они стали хейтить фреймворк, а не свои руки/головы

Еще часто отождествляют xf с Xamarin

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

Я считаю не хватает компаний которые бы на стэке Xamarin предъявили миру ряд приложений не уступающих ни в одной компоненте нативным именно на андроиде. Такие аппы надо уметь готовить

А замаринщиков кто proguard например умеет готовить - пересчитать по пальцам можно

Xamarin в тырпрайзе хорошо идет

https://youtu.be/LidlAkrYKGg

Господа, таки что лучше, делать всю навигацию на фрвгментах или разных активити? Что считается более верным?

Можно ещё в эту сторону посмотреть

https://mobisoftinfotech.com/services/xamarin-application-development

вон индусы че делають окаянные)

не ценится потому что пришла на хайпе херова туча народа и когда у них нихера не получилось нормального они стали хейтить фреймворк, а не свои руки/головы

+++

https://youtu.be/LidlAkrYKGg

ну так я про это речь и вел. Только навигация “как и в инстаграм” пишется и с фрагментами тоже. С childFragmentManagerом тем самым которого так дико испугались в авиасейлз. Ничего сложного там нет, но видимо уровень программистов… так скажем не высокий https://habrahabr.ru/company/mobileup/blog/314838/ Вот кстати как нативщики маятся

Господа, таки что лучше, делать всю навигацию на фрвгментах или разных активити? Что считается более верным?

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

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

но ради приличия я скажу что с вьюшками решения есть очень даже живые https://habrahabr.ru/post/243363/

можно менять “сцены”

но ради приличия я скажу что с вьюшками решения есть очень даже живые https://habrahabr.ru/post/243363/

Ну да, есть хорошие решения

Ну да, есть хорошие решения

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

https://youtu.be/LidlAkrYKGg

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

А учитывая что на андроид Java использовалась, до недавнего времени, 7 версии, то это та ещё боль.

Только за это уже можно любить Xamarin. хех

Ну да, тут Шарп и всегда свежей версии)

Хотя котлин исправляет ситуацию нативной разработки

котлин не решает проблему кроссплатформа)

но на котлине пока на ios не попишешь ничего

НО. Они говорили что скоро все будет

не будет)

это анрил. сделать по нормальному, а не просто поратнуть кор + в крайнем случае "свой" UI kit

не будет)

и даже на raspberryPi

это анрил. сделать по нормальному, а не просто поратнуть кор + в крайнем случае "свой" UI kit

я думаю там не будет своего UIKit как в React

тогда не нужно

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

точнее будет бомбой если ещё и наш MVVM там будет на уровне языка/фреймворка. я тоды в котлин ударюсь.

Котлин годная штука

После с# прекрасно заходит

В 8 с# будут из котлина фишки

В 8 с# будут из котлина фишки

например?

например?

class BankAccount(Guid Id, string Name, decimal Balance)

extension property

реализация в интерфейсах

реализация в интерфейсах - это от java

екстенш проперти тоже вряд ли котлином вдохновленны

единственная фича котлина которая очень нужна в шарпе - это data class

ERROR: S client not available

class BankAccount(Guid Id, string Name, decimal Balance)

я бы сказал,что это из F# так как это было задолго до котлина.

ну котлин сам по себе вдохновлен и с# в том числе)

но язык замечательный

подобие linq там есть

high order functions удобная штука

не сишарп в том числе, а сишарп там в первых рядах)) его ж писали там поцоны после решарпера

да, на самом деле это котлин впитал в себя все из разных языков, а не например в c# что-то появилось из котлина. Так пока что говорить некорректно)

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

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

ну это сейчас так. Погоди. 2 года дай котлину и возможно он хорошо так потеснит Xamarin на мобилках. А React вообще под шхонарь загонит, где ему и место

за 2 года ничего не сделает

мы столько времени убили на интероп и интеграцию с айосом

и хкодом

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

та же постоянно меняющиеся интеграция с хкодом

мы столько времени убили на интероп и интеграцию с айосом

в 2011. И каким количеством ресурсов

мы столько времени убили на интероп и интеграцию с айосом

и ты же в Xamarin пришел в 2014

extension property

Они их хотят уже несколько версий подряд и ни как... А мне нужна эта фича.

котлин не решает проблему кроссплатформа)

Я говорил не про кроссплатформу, а про нативную разработку и уменьшение её языковой боли

Я говорил не про кроссплатформу, а про нативную разработку и уменьшение её языковой боли

очевидно что котлин лучше для андроида. Но... зная один андроид ты становишься ничем не лучше миллионна андроидеров. Глянь заказы на апворке - там демпинг сумасшедший

очевидно что котлин лучше для андроида. Но... зная один андроид ты становишься ничем не лучше миллионна андроидеров. Глянь заказы на апворке - там демпинг сумасшедший

Ну это само собой

ну и кстати) для нативной разработки можно писать на шарпе код и компилить его в нативную либу ? и использовать из kotlin/swift

я недавно такое делал - у меня жирная логика на шарпе была - скомпилировалась в 4мб либку для ведра и 1.5мб добавила к ipa на айосе при этом я получил нативное ООП апи

более того, можно в такой либке писать ГУЙ - т.е частично писать его в шарпе, частично в котлине

Ну как вариант.

реализация в интерфейсах

Это вообще жесть

Это вообще жесть

Удобно

очевидно что котлин лучше для андроида. Но... зная один андроид ты становишься ничем не лучше миллионна андроидеров. Глянь заказы на апворке - там демпинг сумасшедший

Нативщику вообще сложно там начать. Андроид точно, с иос еще можно попробовать

Удобно

Нет это люто и дико

Я бы обоссал тех, кто добавил реализацию в интерфейсы

Не понятна вообще изначальная идея, в чем прикол реализаций в интерфейсах?

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

Допустим вынести интерфейс для работы с тулбаром