Поддержу по
Триллер.
Реально на андроид проектах любая функциональность пишется за 5 минут на джаве.
Ну, это явное преувеличение. :) Апки разные бывают. Другое дело, что я не могу припомнить случая, когда проектые сложности, с которыми доводилось сталкиваться, магически решились бы сменой языка. Что Java, что Kotlin, всё равно останется вагон факторов, влияние которых на успех проекта несоизмеримо выше.
ну поделился человек своей историей. и спасибо ему за это. зачем сразу ярлыками обвешивать?
Всё бы хорошо, но сарказм — просто другая грань негативизма. Кстати, оч едкая и вредная дрянь.
:) Ну, может не так радикально, но вцелом да — когда реально хотят решить проблему, то ее быстро решают.
Тоже верно. В пост-совковых странах люди страдают от «выученной безпомощности». И у этого феномена есть свои объективные причины.
Данный пост — попадание в
Ну, не то чтобы это здравомыслие. Как раз нет, это таки негативно-депрессивный взгляд на жизнь, который, кстати, снижает качество жизни в долгосрочной перспективе.
Наверное, IT-никам это в нагрузку прилагается природой. Больше видишь деталей и несоответствий — больнее бьёт.
Здравомыслие заключается в том, чтобы осознать это и поменять отношение на нейтральное или позитивное.
Интересный опыт. Не смотря на возможность экономии времени/бюджета, думаю эта технология слабо взлетает у нас по неск причинам:
1. Может так получиться, что вместо двух разработчиков (одного Android и одного iOS) при стандартной дедикейтед разработке, потребуется три (те два + web full-stack), а не один. Ведь вцелом, когда проект только начинается, не всегда его можно надежно и четко оценить (заказчик может и сам не знать что ему нужно, а дозреет только когда получит какую-то часть), часто всё выясняется по ходу проекта.
2. И чтобы потом саппортить код, то также может потребоваться не по одному на платформу, а по паре.
Иными словами существует риск не получить экономию времени/бюджета, а наоборот потратить больше. При этом, конечно, есть случаи, в которых всё достаточно прогнозируемо, где не требуется тяжеловесных операций на клиенте либо доступа к каким-то нативным клиентским API, и там возможна экономия времени/бюджета. С другой стороны, мне, как Android разработчику, за последние годы такие простые проекты не попадались (везде требовалось глубокое понимание своей платформы, которого бы у меня не было будь я web разработчиком).
Сергей, могли бы рассказать в чём был плюс использования Реакт Нейтив на данном проекте? И был ли он вообще или это просто такой заказчик попался (мол, хочу и это не обсуждается)?
Ой, вот только не нагнетайте на ровном месте.. Одна новость — пьяные малолетки, которые найдут не один так другой повод. А вторая наоборот позитивная — вынесли приговор по годичному делу. Всё это есть в любой стране, и по плотности событий стремится к статистической погрешности.
если б только энтерпрайза.. :)
среднестатистический случай — собираем
Глянул в офиц документацию. Картина прояснилась — delay/await в контексте корутины действительно не блокируют поток/нить, на котором исполняетя корутина, а саспендят саму корутину, давая другим корутинам поработать на этом же потоке, если таковые имеются.
Спасибо за ответ. Яснее не стало. Видимо надо почитать что такое корутины. :)
Я так понимаю, что котлиновское Deferred.await()
это аналог джавишного Future.get()
.
Не понятно, в каком потоке выполняется ожидание (Deferred.await()
), сложение, toString()
и самое главное — финальное присвоение значения (myTextView.text =
).
спасибо, тоже глянул. + еще вот это — www.youtube.com/watch?v=CABN2r4GPpQ — не увидел ничего такого ради чего хотелось бы переходить на Котлин. из опыта, проблемы проектов обычно упираются в совсем другие вещи. Java — хорошо сбалансированный язык, который помогает бороться с энтропией на проектах.
Буквально вчера ломал голову над одним багом, который я случайно обнаружил и мне потом не удалось его воспроизвети как я ни пытался. Samsung 7″ 4.4.2. Фрагмент обращался к getResources() и получил ошибку о том, что фрагмент не приатачен. Хотя там была гарантия того, что это происходит между onStart() и onStop(). Поэтому да, возможно там есть какой-то редкий баг, и, возможно, я погорячился на счет акцента на рандомности.
да. я уже понял, что неточно выразился.
А что является предметом спора с Ораклом? Реализация Java APIs. А что Котлин под капотом юзает? Всё это уже было детально рассмотрено, и показано, что Котлин, в его нынешнем виде, не спасает от претензий со стороны Оракла.