По желанию. Можно создавать, можно не создавать. Есть единая структура виджетов и даже то, что считать в нём экраном — можно менять. Например в приложении из примера я могу повесить навигатор на переключатель табов и в приложении кнопка «назад» будет путешествовать по истории переключения табов.
1. В рамках философии Flutter, пользовательский интерфейс должен извлекать максимум из платформы. Так что поддержка клавиатурного ввода — это, скорее всего, будет отдельный набор виджетов. И вряд ли от разработчиков Flutter.
2. Сделать такой набор виджетов, на самом деле, не так трудно самому. Flutter предоставляет колоссальные возможности по их кастомизации, как в части внешнего вида, так и в части поведения.
3. Вообще это выглядит как не очень удачный выбор фреймворка. Flutter хорош для кросс-платформенной мобильной разработки. Если нужна разработка под конкретное устройство, да ещё и с нехарактерным для мобильных способом ввода — тут просится натив.
Что у него графика на OpenGL. Поскольку я довольно мало что про него знаю, я про него почти и не писал.
На самом деле я плотно рассматривал только более-менее популярные фреймворки. Я знаю, что у Kivy хорошая пресса на хабре, но при всём уважении, популярность у него сильно уступает большинству других фреймворков в обзоре.
Мне кажется вы неправильно готовите flutter. В нём пользовательский интерфейс — это отражение состояний (state), сам по себе он и не должен сохраняться, это должен реализовывать программист. Вопрос только в том, как именно сохранять состояния.
У flutter сейчас есть 3 плагина, которые можно использовать для персистентности:
Shared preferences https://pub.dartlang.org/packages/shared_preferences — самый подходящий, если нужно просто сохранить небольшое состояние интерфейса.
SQFLite для данных побольше.
Firebase с возможностью хранить в сети. Тут точно не нужен.
В принципе, этого достаточно. Хотя очень хотелось бы увидеть какой-нибудь синтаксический сахар для автоматического сохранения данных состояния. Через аннотации, например.
Абзац про «экологичное отношение» не учитывает, что до прихода аборигенов бОльшая часть Австралии была покрыта лесами. Индуцированные пожары изначально были не «обновлением», а экоцидом.
Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
Переформулирую — для работы с odata нужно пользоваться соответствующими библиотеками. Это может быть и недостаток, но я бы и graphql без библиотек не советовал использовать.
Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернутьсервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.
А в чём здесь преимущество? Наоборот, подход odata позволил добавить динамические свойства, которые в некоторых сценариях очень полезны.
odata продвигается Microsoft и является у них технологией по умолчанию для rest. Масштаб такой же, как у фейсбука. Тут вопрос скорее в целевой аудитории:
odata больше целится в энтерпрайз и лучше работает с реляционными БД, ORM и т.д.
graphql больше ориентирован на стартапы, поэтому больше заточен на no-sql (прежде всего Mongo) и меньше заботится о документации.
Неудобно. В реализации по умолчанию каждая сущность запрашивается по отдельности. Есть решения, которые делают join, но эффективность под вопросом. Плюс довольно неудобно вставлять ограничения доступа.
Есть postgraphql, который делает всё автомагически, но ограничения доступа и пользователей нужно настраивать на уровне БД.
1. В рамках философии Flutter, пользовательский интерфейс должен извлекать максимум из платформы. Так что поддержка клавиатурного ввода — это, скорее всего, будет отдельный набор виджетов. И вряд ли от разработчиков Flutter.
2. Сделать такой набор виджетов, на самом деле, не так трудно самому. Flutter предоставляет колоссальные возможности по их кастомизации, как в части внешнего вида, так и в части поведения.
3. Вообще это выглядит как не очень удачный выбор фреймворка. Flutter хорош для кросс-платформенной мобильной разработки. Если нужна разработка под конкретное устройство, да ещё и с нехарактерным для мобильных способом ввода — тут просится натив.
Но согласен, формулировка неудачная, в релиз они вышли почти одновременно.
На самом деле я плотно рассматривал только более-менее популярные фреймворки. Я знаю, что у Kivy хорошая пресса на хабре, но при всём уважении, популярность у него сильно уступает большинству других фреймворков в обзоре.
Мне кажется вы неправильно готовите flutter. В нём пользовательский интерфейс — это отражение состояний (state), сам по себе он и не должен сохраняться, это должен реализовывать программист. Вопрос только в том, как именно сохранять состояния.
У flutter сейчас есть 3 плагина, которые можно использовать для персистентности:
Shared preferences https://pub.dartlang.org/packages/shared_preferences — самый подходящий, если нужно просто сохранить небольшое состояние интерфейса.
SQFLite для данных побольше.
Firebase с возможностью хранить в сети. Тут точно не нужен.
В принципе, этого достаточно. Хотя очень хотелось бы увидеть какой-нибудь синтаксический сахар для автоматического сохранения данных состояния. Через аннотации, например.
А в чём здесь преимущество? Наоборот, подход odata позволил добавить динамические свойства, которые в некоторых сценариях очень полезны.
odata больше целится в энтерпрайз и лучше работает с реляционными БД, ORM и т.д.
graphql больше ориентирован на стартапы, поэтому больше заточен на no-sql (прежде всего Mongo) и меньше заботится о документации.
odata выигрывает у graphql по стандартизации и возможностям и делает то же самое
Есть postgraphql, который делает всё автомагически, но ограничения доступа и пользователей нужно настраивать на уровне БД.