Consistency
A consistent app implements familiar standards and paradigms by using system-provided interface elements, well-known icons, standard text styles, and uniform terminology. The app incorporates features and behaviors in ways people expect.
Выяснилось, что это приложение использует Flutter лишь на нескольких экранах, и в комментарии пользователь указал, что Realtor.com «медленно интегрирует» Flutter в приложение.
Тем не менее, ставить такое приложение в showcase, мягко говоря, нечестно.
Да нет, это все еще проблема флаттера. Чтобы нативное приложение выглядело ненативно и ощущалось так же, разработчикам приходится стараться, чтобы сделать плохо (в основном с подачи менеджеров и дизайнеров, которые не понимают/не хотят понимать разницы между платформами и не хотят читать гайдлайны по UI для этих платформ). В случае с флаттером же приходится стараться, чтобы оно выглядело и ощущалось как нативное.
Например, учитывая, что Flutter, грубо говоря, берет от системы только канвас и рисует весь интерфейс на нем, приложение будет одинаково выглядеть и вести себя и на 10, и на 5 андроиде.
С этим прекрасно справляется AndroidX. В случае же с iOS, напротив, нежелательно, чтобы системные компоненты на разных версиях iOS — как минимум выглядит неопрятно, как максимум — запутывает пользователя. Так что в данном случае Флаттер вряд ли «может и убрать».
Нативное != хорошее, подешевле-побыстрее != хуже.
Абсолютно верно! В теории это не так. На практике же зачастую именно так и выходит. И, опять же, на хорошо сделанное ненативное приложение может быть потрачено намного больше человекочасов, чем могло бы быть потрачено на две платформы просто потому, что помимо проблем платформы приходилось решать еще и проблемы кроссплатформенного фреймворка.
Ну так этот код все равно бы пришлось писать.
Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
а) вторую платформу
б) объединяющего их интерфейса/плагина
Потому что может оказаться, что этот супер-новый компонент нативно доступен только в условном Андроиде 31, до которого в ближайшие пару лет обновятся только 5% ваших пользователей, и без костылей на предыдущих версиях его все равно не сделать.
Я немного не про то. Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно — например, теперь оно стало шириной с весь экран, и кнопка, означающая «разрушительное» действие всегда будет помещена системой в самый конец списка кнопок. В предыдущей версии, например, было наоборот. Если вдруг разработчики флаттера сделали самописный диалог, а не просто вызов UIAlertController, я получу неконсистентное поведение — во всей системе «разрушительная кнопка» внизу, а во флаттере до обновления она все еще вверху. Чтобы это исправить, мне придется обновлять версию флаттера, и заново выпускать новую версию. А с этим обновлением я получу корректное поведение для пользователей более новой системы, но некорректное — для пользователей более старой. Не говоря уже о том, что обновление версии флаттера может нести в себе множество других сюрпризов — например, сломается другая критическая часть приложения.
Очень громкое название.
Flutter побеждает ровно до тех пор, пока не требуется сделать что-то, что использует что-то более сложное, чем список товаров в приложении, подтянутый с API. Не говоря уже о том, насколько сильно Flutter отличается от нативных приложений в плане look-and-feel. За Андроид говорить не берусь, использую телефон на Android'е только как тестовое устройство, но на iOS Flutter ощущается, будто кто-то очень и очень удачно замаскировал WebView под нативное приложение, и это очень неприятно. Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.
Не говоря уже о том, что у всех подобных кроссплатформенных библиотек всегда есть три фундаментальные проблемы:
1. Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
2. Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
3. Ограниченный выбор библиотек — некоторые находятся на очень ранней стадии развития, некоторые просто отсутствуют в силу особенностей платформы, некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них (уменьшая выгоду по времени от кроссплатформенности и добавляя еще один слой, на котором может что-то пойти не так)
Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием. Но называть бы это победой я не стал.
Знакомый интерфейс на скриншоте с акциями Теслы. Не Investing.com, случайно? Если да, то приятно, что продукт, над которым ты работал, пользуется спросом!
Было бы интересно очень почитать про то, как проходит налогообложение на доходы с фондового рынка.
Ох уж это ваше высокомерие, сквозящее в каждом комментарии. При этом вы все еще пытаетесь убедить словами, мол, «нет, я не высокомерный, я такой же весь», но ваши слова намного сильнее показывают, какой вы есть.
Ах да, открою секрет — из ухвативших мысль только вы один, так как мысли-то толком и не было.
Вашу мысль ухватить невозможно — она разбросана по статье настолько мелкими и мутными кусочками, что приходится чуть ли не с микроскопом ее выискивать. А в комментариях автор вместо того, чтобы разъяснить свою мысль, просто раскидывается косвенными оскорблениями и раздутым эго.
Люди, скорее, не «представляют», а «не представляют» — не представляют, что такое вообще программирование, как оно работает, и чем занимается программист большую часть времени.
Я думаю, zagayevskiy спрашивал про Kotlin. Мне бы тоже было любопытно услышать, почему в Kotlin'е нельзя пользоваться Runnable — пользуюсь им часто и с удовольствием :)
Есть интересные случаи, на которые можно попасться, вроде описанного тут, но вообще никто не запрещает использовать Runnable так, как вздумается.
FileKit, насколько я знаю, не самый лучший выбор. Он удобный, но в нем есть несколько проблем — к примеру, лично столкнулся с такой проблемой: при использовании FileKit внутри блока, отправленного через dispatch_async, использование памяти растёт неограниченно из-за создания новых потоков. Плюс в нем не используется NSFileCoordinator, что тоже не есть хорошо.
Среди которых есть следующее:
Material Design на iOS это нарушает.
Это как в англоязычном высказывании — «plural of anecdote is not data». Измерять стабильность фреймворка только по себе — это совсем неправильно.
Тем не менее, ставить такое приложение в showcase, мягко говоря, нечестно.
Да нет, это все еще проблема флаттера. Чтобы нативное приложение выглядело ненативно и ощущалось так же, разработчикам приходится стараться, чтобы сделать плохо (в основном с подачи менеджеров и дизайнеров, которые не понимают/не хотят понимать разницы между платформами и не хотят читать гайдлайны по UI для этих платформ). В случае с флаттером же приходится стараться, чтобы оно выглядело и ощущалось как нативное.
С этим прекрасно справляется AndroidX. В случае же с iOS, напротив, нежелательно, чтобы системные компоненты на разных версиях iOS — как минимум выглядит неопрятно, как максимум — запутывает пользователя. Так что в данном случае Флаттер вряд ли «может и убрать».
Абсолютно верно! В теории это не так. На практике же зачастую именно так и выходит. И, опять же, на хорошо сделанное ненативное приложение может быть потрачено намного больше человекочасов, чем могло бы быть потрачено на две платформы просто потому, что помимо проблем платформы приходилось решать еще и проблемы кроссплатформенного фреймворка.
Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
а) вторую платформу
б) объединяющего их интерфейса/плагина
Я немного не про то. Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно — например, теперь оно стало шириной с весь экран, и кнопка, означающая «разрушительное» действие всегда будет помещена системой в самый конец списка кнопок. В предыдущей версии, например, было наоборот. Если вдруг разработчики флаттера сделали самописный диалог, а не просто вызов UIAlertController, я получу неконсистентное поведение — во всей системе «разрушительная кнопка» внизу, а во флаттере до обновления она все еще вверху. Чтобы это исправить, мне придется обновлять версию флаттера, и заново выпускать новую версию. А с этим обновлением я получу корректное поведение для пользователей более новой системы, но некорректное — для пользователей более старой. Не говоря уже о том, что обновление версии флаттера может нести в себе множество других сюрпризов — например, сломается другая критическая часть приложения.
Flutter побеждает ровно до тех пор, пока не требуется сделать что-то, что использует что-то более сложное, чем список товаров в приложении, подтянутый с API. Не говоря уже о том, насколько сильно Flutter отличается от нативных приложений в плане look-and-feel. За Андроид говорить не берусь, использую телефон на Android'е только как тестовое устройство, но на iOS Flutter ощущается, будто кто-то очень и очень удачно замаскировал WebView под нативное приложение, и это очень неприятно. Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.
Не говоря уже о том, что у всех подобных кроссплатформенных библиотек всегда есть три фундаментальные проблемы:
1. Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
2. Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
3. Ограниченный выбор библиотек — некоторые находятся на очень ранней стадии развития, некоторые просто отсутствуют в силу особенностей платформы, некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них (уменьшая выгоду по времени от кроссплатформенности и добавляя еще один слой, на котором может что-то пойти не так)
Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием. Но называть бы это победой я не стал.
Было бы интересно очень почитать про то, как проходит налогообложение на доходы с фондового рынка.
Ах да, открою секрет — из ухвативших мысль только вы один, так как мысли-то толком и не было.
Вашу мысль ухватить невозможно — она разбросана по статье настолько мелкими и мутными кусочками, что приходится чуть ли не с микроскопом ее выискивать. А в комментариях автор вместо того, чтобы разъяснить свою мысль, просто раскидывается косвенными оскорблениями и раздутым эго.
Есть интересные случаи, на которые можно попасться, вроде описанного тут, но вообще никто не запрещает использовать Runnable так, как вздумается.
FileKit, насколько я знаю, не самый лучший выбор. Он удобный, но в нем есть несколько проблем — к примеру, лично столкнулся с такой проблемой: при использовании FileKit внутри блока, отправленного через dispatch_async, использование памяти растёт неограниченно из-за создания новых потоков. Плюс в нем не используется NSFileCoordinator, что тоже не есть хорошо.