В данный момент фокус направлен на уже существующую кодовую базу. Но при появлении нового проекта не исключено, что он будет на Flutter. Я, по крайней мере, сейчас его активно пропагандирую внутри компании. Думаю вариант присматриваемся вполне подходит :)
Не стесняюсь указывать источники, в этой части потерялась фраза из предыдущей, которая идёт первым предложением. Поэтому отвечу комментарием из той же предыдущей части:
«Поэтому я решил интерпретировать официальную документацию Flutter в лаконичный формат «вопрос — ответ».»
Тега лаконичная интерпретация нет, а взятые с офф сайта заголовки и примеры всё-таки сложно назвать переводом.
Но понимаю суть негодования и в следующих частях обязательно укажу ссылку на оригинальную документацию.
Я так понимаю речь идёт о пользователях PC, т.к. в мобильной версии сайта и мобильном приложении:
А) Нет превью статей, а показываются только заголовки;
Б) Эта же картинка весит ~300 KB.
А раз речь о пользователях PC, то следовательно это либо Wi-Fi, либо оптоволокно, либо 4G (модем или раздача с телефона). В картинке размером 1.8 MB с моей точки зрения всего 2 аспекта для беспокойства: потраченный трафик и кеширование в памяти.
Скорее всего у большинства пользователей PC безлимитный трафик, поэтому скачивание беспокойство вызывать не должно. А если трафик лимитированный — то возникает вопрос: почему у такого пользователя всё ещё включена предзагрузка картинок? Ведь прилететь может отовсюду, та же лента в любой соцсети отожрёт больше трафика, чем первая страница хабра. Картинки в статью заливаются через habrastorage, где: “Доступные расширения: jpg, gif, png; ширина до 5000px; максимальный размер до 8 Мбайт”.
Если зайти с позиции памяти на жёстком диске, то чаще всего браузеры используют сложные стратегии кеширования, в том числе LRU. И новые картинки просто вытеснят старый кэш и изменения в памяти заметно не будет.
Я, конечно, попрошу графического дизайнера переделать картинку, но, кажется, беспокойство немного гиперболизированно.
The purpose of this project is to support building applications that use Flutter on Windows, macOS, and Linux.
2. Не Вам одному. Мне бы тоже хотелось =)
И всем, кто следит за этой issue: github.com/flutter/flutter/issues/7053
По поводу дат неизвестно. (Но стоит milestone: May 2019, может чудо всё-таки свершится?)
Спасибо за поддержку! В планах ещё части для iOS, React Native, Web, Xamarin.Forms разработчиков.
По поводу получения текста — это делается через TextEditingController. Подробный пример можно посмотреть тут: flutter.dev/docs/cookbook/forms/retrieve-input
Да, встречались с такой проблемой. Написали свой workaround, который слушал onGlobalLayout через ViewTreeObserver.OnGlobalLayoutListener и высчитывали высоту, которую можно использовать для верстки через getWindowVisibleDisplayFrame. И после расчёта прокидывали в качестве callback'а новую высоту и разницу в высотах всем слушателям. А они уже в свою очередь перерисовывались. Надеюсь будет полезно :)
В данном случае я привожу примеры программной чёлки, она нужна только для того, чтобы понять, где могут быть проблемы на реальных девайсах с чёлкой.
На реальных девайсах же она будет аппаратная и в ней будет скрываться камера и разные датчики, т.е. там уже будет действительно недоступная зона экрана.
Есть ли в ней жизненная необходимость производители смартфонов уже решили и практически каждый новый анонсированный девайс ей оснащён. Пользоваться такими устройствами или нет — Ваш выбор. А вот поддерживать её в своём приложении или нет — думаю нет выбора, т.к. если где-то из-за неё едет вёрстка, то однозначно придётся.
Да, глупее пока сложно что-то придумать
По сути, если приложение не лезет под статус бар, то оно по умолчанию будет без ограниченной части верстаться
В основном зависит от windowActionBarOverlay флага, и других, типа windowActionBar, windowNoTitle, windowDrawsSystemBarBackgrounds, windowTranslucentStatus, windowIsTranslucent и их комбинаций
т.е дефолтное приложение без заморочек сверстается адекватно
«Данный подход хорош тем, что мы не делаем ничего лишнего — фреймворк построен на столько, на сколько это нужно для работы тестов. Можно сказать, что это концепция MVP в тестировании»
Можно сказать, что это TDD)
Flutter Developers — русскоговорящее сообщество
Dart & Flutter по-русски
Flutter Dev Подкаст
2. Есть класс MediaQuery для этих целей.
Но понимаю суть негодования и в следующих частях обязательно укажу ссылку на оригинальную документацию.
А) Нет превью статей, а показываются только заголовки;
Б) Эта же картинка весит ~300 KB.
А раз речь о пользователях PC, то следовательно это либо Wi-Fi, либо оптоволокно, либо 4G (модем или раздача с телефона). В картинке размером 1.8 MB с моей точки зрения всего 2 аспекта для беспокойства: потраченный трафик и кеширование в памяти.
Скорее всего у большинства пользователей PC безлимитный трафик, поэтому скачивание беспокойство вызывать не должно. А если трафик лимитированный — то возникает вопрос: почему у такого пользователя всё ещё включена предзагрузка картинок? Ведь прилететь может отовсюду, та же лента в любой соцсети отожрёт больше трафика, чем первая страница хабра. Картинки в статью заливаются через habrastorage, где: “Доступные расширения: jpg, gif, png; ширина до 5000px; максимальный размер до 8 Мбайт”.
Если зайти с позиции памяти на жёстком диске, то чаще всего браузеры используют сложные стратегии кеширования, в том числе LRU. И новые картинки просто вытеснят старый кэш и изменения в памяти заметно не будет.
Я, конечно, попрошу графического дизайнера переделать картинку, но, кажется, беспокойство немного гиперболизированно.
UPD
Картинку обновили, теперь весит 250 KB.
Тега лаконичная интерпретация нет, а взятые с офф сайта заголовки и примеры всё-таки сложно назвать переводом.
2. Не Вам одному. Мне бы тоже хотелось =)
И всем, кто следит за этой issue: github.com/flutter/flutter/issues/7053
По поводу дат неизвестно. (Но стоит milestone: May 2019, может чудо всё-таки свершится?)
flutter.dev/docs/resources/faq#can-i-build-3d-opengl-apps-with-flutter
По поводу получения текста — это делается через TextEditingController. Подробный пример можно посмотреть тут: flutter.dev/docs/cookbook/forms/retrieve-input
www.xda-developers.com/google-wants-developers-to-add-dark-themes-to-save-battery-life
На реальных девайсах же она будет аппаратная и в ней будет скрываться камера и разные датчики, т.е. там уже будет действительно недоступная зона экрана.
Есть ли в ней жизненная необходимость производители смартфонов уже решили и практически каждый новый анонсированный девайс ей оснащён. Пользоваться такими устройствами или нет — Ваш выбор. А вот поддерживать её в своём приложении или нет — думаю нет выбора, т.к. если где-то из-за неё едет вёрстка, то однозначно придётся.
По сути, если приложение не лезет под статус бар, то оно по умолчанию будет без ограниченной части верстаться
В основном зависит от windowActionBarOverlay флага, и других, типа windowActionBar, windowNoTitle, windowDrawsSystemBarBackgrounds, windowTranslucentStatus, windowIsTranslucent и их комбинаций
т.е дефолтное приложение без заморочек сверстается адекватно
Можно сказать, что это TDD)