Особенности ОС Андроид ( и, как я предполагаю, других мобильных платформ) диктуют свои нормы на дизайн пользовательского интерфейса, ключевым элементом в котором является класс TTabControl – многостраничник, который содержит в себе всё, что нужно показать пользователю. Каждая страница – это отдельный режим работы с приложением.
Кроме многостраничника (2) требуются кнопки и элементы, которые я сгруппировал в две категории и разместил на двух панелях инструментов:
- Шапка – кнопки вызова помощи и возврата к предыдущему режиму, а также название программы (1)
- Подвал – кнопки взаимодействия с отображаемым объектом (3).
Но за скромность в числе элементов приходится платить условностями в обработчиках: в зависимости от того, какая вкладка активна, нужно выполнять те или иные действия.
И вот теперь я в раздумьях. Дело в том, что сложность формы будет расти, значит, будет расти и сложность обработчиков. С другой стороны, если на каждой вкладке разместить нужные панели и кнопки, то обработчики станут простыми, хотя увеличится их общее количество.
Вторая неприятность подкралась незаметно. Кнопки (TButton, TSpeedButton) можно подключить к привычному по работе с VCL компоненту TImageList, но FireMonkey не умеет управлять положением такого изображения на кнопке – оно всегда располагается в левой части кнопки, а справа можно отобразить текст. То есть невозможно расположить изображение по центру кнопки (и при этом 2024 год на дворе). Проблема, конечно, решается добавлением на кнопку изображения TGlyph, которое получает картинку из того же списка изображений (TImageList), но для меня это выглядит как костыль.
Ещё напрягает, что если все это будет свалено на одной форме, то некоторые похожие элементы (например, кнопки редактирования или навигации) должны иметь уникальные названия. Всё это наводит меня на мысль о создании отдельных фреймов для каждого “экрана” (режима работы) программы. В качестве плюса фреймовой системы можно рассмотреть создание фреймов по необходимости, что ускорит запуск программы, так как элементы пользовательского интерфейса будут создаваться не при запуске приложения, а по мере надобности. Также их можно будет при необходимости утилизировать, высвобождая оперативную память. По большому счету при фреймовой архитектуре TTabControl становится не нужным, так как переключение режимов сводится к переключению видимости фреймов.
Надо подумать…