Размышления о новинках: MUI, LB, FMX

Несколько мыслей, на которые захотелось найти время и опубликовать. Итак...


Metropolis UI
Нацелен на планшетное применение (ну мне так показалось: интерфейс пропагандирует применение жестов и управление пальцем). Как следствие, приложения под Metropolis плохо применимы под интенсивный пользовательский ввод данных. Ну вот, к примеру, мне тяжело представить IDE среды разработки приложений какого-нибудь языка для планшета. Слишком неудобно. Ну, допустим, мы будем использовать внешнюю клавиатуру, чтобы сэкономить часть экранного пространства, занимаемого виртуальной клавиатурой. Причём, лучше нормальную клавиатуру, чем док-станцию, ибо верхний край экрана должен быть на уровне глаз (вообще Microsoft в хелпах и руководствах пользования очень часто акцентирует внимание на то, как правильно сидеть за ПК). Тогда и мышь должна быть внешней, ибо тыкать пальцем куда-то перед собой (как мне кажется) не очень удобно. Да и при визуальном проектировании дизайна, порой очень важна точность указательного ввода, которой пальцем не достигнуть в принципе (ну разве что стилусом можно, и то, с оговорками). А тогда это получается уже не планшет, а десктоп.
Ну хорошо, набирать код и проектировать дизайн мы не будем. Заниматься интенсивным клавиатурным вводом данных – тоже. Попробую представить, что за программы можно делать для планшетов/в стиле Metropolis UI.
Сразу оговорюсь, я не хочу рассматривать приложения развлекательного и полуразвлекательного характера, т.к. для них Metropolis UI подойдёт точно. (А это могут быть лёгкие графические реакторы, может быть даже простые редакторы аудио и видео, заметки и напоминания, всякая социальщина, игры.) Мне интересно применение Metropolis UI в бизнесе. Ну, хотя бы потому, что мы Delphi-программисты, как правило, делаем заказное ПО, направленное на решение конкретных, часто узкопрофильных задач.

Первое, о чём я подумал – это приложения, работающие с базами данных. Допустим, есть некая БД, данные в которой наполняются обычными десктопными приложениями. С планшета можно подключиться к БД и отображать какие-то данные, следить за их изменениями. Производить минимальные манипуляции с данными.
Если это складская программа, то можно научиться распознавать штрих-коды, получаемые камерой, и таким образом, заниматься наведением порядка на складском помещении: считали штрих-код с товара, затем считали штрих-код шкафа/полки/ячейки, где лежит товар – и провели операцию совмещения товара с местом его хранения. (Т.е. ничего вводить с клавиатуры вообще не надо, достаточно нескольких тапов по экрану.) Да, ещё отслеживание GPS датчика тоже интересно.
Если это документооборот и делопроизводство, то на планшете можно смотреть, за какие документы отвечает пользователь, назначать ответственных и переводить документы из состояния в состояние (причём клавиатурный ввод может быть минимальным).
Наверное, в любой сфере деятельности, важны отчёты. В принципе, на планшете довольно удобно читать информацию, поэтому специальные приложения «для босса», которые позволяют быстро посмотреть что-то, могут быть востребованы в любом бизнесе.
Ещё можно представить себе школьников (студентов) с планшетами, на которых отображается контент, задаваемый учителем (преподавателем).
Вот, на большее у меня фантазии пока не хватило…


Live Bindings
Мысль первая. Live Bindings (как я понял) реализован как некая машина, разбирающая скриптовый код. Если этот код формируется в Run-Time, то применение такого механизма вполне оправдано. Но ёлки-палки, во всех демках (с оговоркой: которые я успел посмотреть) по XE2 и даже в Visual Live Bindings – этот код уже сформирован ещё до компиляции проекта! Непонятка…
Мысль вторая. В последнем семинаре (от 12.09.2012, который я посмотрел в оффлайне) звучит пару высказываний, примерно такого содержания:

• нативный код всегда лучше, чем интерпретируемый (это мнение я разделяю);
• ничего плохого в скриптовости LiveBinding’а нет, ведь SQL-то тоже интерпретируется.

Однако сравнение с SQL не совсем корректно, т.к. разбор SQL, как правило, выполняется на сервере, вычислительные возможности которого намного выше клиентского. (Ну и можно вспомнить, что SQL-запросы далеко не всегда статичны, а формируются в Run-Time.)
В общем, Live Bindings как-то плохо вяжется с пропагандой нативного кода… Да и вообще, как-то складывается впечатление, мол дурят нашего брата.
P.S.: я не хочу так категорически отговаривать людей от использования Live Bindings. Тем более, что в Embarcadero уделяют этому механизму очень много внимания. И даже предложили визуальный построитель и показали, как всем этим пользоваться. Но для себя я на эту диковинку пока смотрю с некоторой настороженностью.


Fire Monkey
Вполне себе такой интересный фреймворк. С учётом того, сколько ему уделяется внимания и сил разработчиков, в него вполне можно поверить. Однако лично мне кое-что в нём не нравится. Например, очень сильно печалит тот факт, что нельзя штатными средствами использовать FMX-форму в VCL-проекте. Второй факт: FMX-компоненты называются также, как и VCL-компоненты (TEdit, TLabel и т.п.), однако набор свойств расходится. Чтобы написать универсальный компонент, который бы компилировался и в VCL и в FMX, приходится сильно извра.. исхитряться (например: DualCompileControl)
Факт третий: визуальные компоненты (типа кнопок, полей ввода, комбобоксов), совсем даже не нативные (с точки зрения операционной системы). Для себя я пока до конца не определился, хорошо это, или плохо. Однако больше склоняюсь к тому, что интерфейс приложения должен максимально соответствовать особенностям используемой ОС.