Compact Framework лучшие практики: создание графического интерфейса

Question

Я поддерживаю приложение Windows CE, созданное на основе .NET Framework, которое имеет около 45 форм. Есть 5 «секций», которые ведут к нужной вам функции. Приложение работает на 100% в полноэкранном режиме, и важно, чтобы его нельзя было свернуть.

Поскольку существует так много форм, трудно отследить, какая форма должна отображаться после ее закрытия. Для этого я устанавливаю свойство владельца формы перед его отображением и показываю владельца при его закрытии.

Мне также сообщили, что лучше всего создавать экземпляры всех форм при загрузке приложения, а не утилизировать их, чтобы сэкономить время обработки. Я не уверен в этом.

У меня вопрос: как лучше всего показывать, скрывать формы, где вы хотите, чтобы любая 1 форма была впереди, на весь экран?

Answer 1

Я бы не пошел по пути создания 45 форм при запуске приложения. Это значительно увеличит время запуска и, возможно, (если не вероятно) исчерпает ваши ресурсы памяти, и все это обеспечит функциональность, которая может даже не понадобиться вашему пользователю.

В моих приложениях WinMo каждая форма предназначена для работы с относительно небольшим подмножеством данных, поэтому время запуска ограничено вызовами базы данных и загрузкой данных в элементы управления формы. Как правило, время, необходимое для создания экземпляра одной из этих форм и показа, никогда не превышает секунды или две.

Если для показа ваших форм требуется больше времени, чем это, возможно, существует проблема с извлечением данных или способом загрузки данных в элементы управления формы (например, у вас может быть пользовательский элемент управления gridview, который полностью отображает все 300 строки, хотя только 12 видны одновременно). Если ваши данные настолько велики, что для их извлечения законно требуется много времени, скорее всего, это гораздо больше данных, чем пользователь может практически взаимодействовать с ними в любом случае.

Я предполагаю, что ваше упоминание о "5 разделах", чтобы добраться туда, куда пользователь должен пойти, означает, что они могут (как минимум) "свернуть" 5 уровней до чего-то. Если бы вы реализовали это, создав каждую экземпляр формы и показав следующую форму, используя ShowDialog, у вас было бы не более 5-6 форм одновременно, что не должно быть проблемой для приложения .Net CF (I делай это все время). Таким образом, вам не нужно делать ничего особенного, чтобы отследить, какая форма должна отображаться, когда - вы просто открываете форму откуда угодно, а когда форма закрывается, вы автоматически возвращаетесь к вызывающей форме.

Есть некоторая странность менеджера z-порядка / задач, с которой вам приходится иметь дело, но это не особенно сложно. Перед вызовом ShowDialog в дочерней форме вы устанавливаете свойство Text родительской формы в пустую строку, а затем возвращаете исходную подпись формы после возврата ShowDialog. Это не является строго обязательным, но в Windows Mobile (по крайней мере до версии 6) все открытые формы .Net (с непустым свойством Text) отображаются в списке «Выполняемые программы», даже если они все из одного и того же приложение. Мне обычно нравится, когда мои мультиформные приложения выглядят как одна программа, поэтому я обычно устанавливаю Text каждой формы в название приложения).

Я также экспериментировал с приложением для одной формы, которое реализует каждый элемент пользовательского интерфейса как пользовательский элемент управления вместо формы, а затем создает и складывает элементы управления, как если бы вы создавали и открывали формы. Это работает, но это взлом, и я не рекомендую это. Формы имеют событие Load, а UserControls - нет, что является основной проблемой.

Answer 2

В процесс загружено множество переменных, поэтому не существует методологии "один размер подходит всем". Конечно, загрузка всех форм первоначально означает быструю межстраничную навигацию, но она замедляет загрузку и может также вывести вас из памяти.

Моя общая методология - использовать фреймворк - лично я фанат OpenNETCF IoC фреймворка , но тогда я, вероятно, пристрастен.

В любом случае вам нужна общая структура, которая делает две вещи:

1. Отделяет представления от модели (должны ли эти представления быть FOrms, пользовательскими CFontrols, панелями или какими-либо предметами, подлежащими обсуждению).
2. Отслеживает, какой вид находится на переднем плане, а какой вид должен быть «следующим» (движетесь ли вы вперед или назад)

Я написал простую фреймворковую статью об этом давным-давно для MSDN . Я обновил его, чтобы использовать более чистый MVC отдельно и IoC Framework , совсем недавно .

Это не значит, что мой путь - единственный или даже "правильный" путь. Тем не менее, это методология, которая оказалась успешной в нескольких развертываниях, как на настольных компьютерах, так и на устройствах.

Трудно дать вам более детальные предложения, потому что мы действительно не знаем, каковы ваши требования или ограничения. Если вы работаете на медленном ARM-устройстве с очень ограниченным объемом памяти и графикой, я, безусловно, буду атаковать некоторые вещи иначе (кэширование, отложенная загрузка и т. Д.), Чем встроенное устройство класса Pentium x86 с гигабайтом оперативной памяти. *

EDIT

Вы увидите, что различие между тем, как MusiGenesis и я бы атаковали это, подчеркивает тот факт, что нет "правильного" пути. Пока мы говорим, я делаю код для полноэкранного встроенного приложения, которое имеет 47 представлений, и проект содержит одну и только одну форму. Он, вероятно, будет использовать 47 различных форм. Оба выполняют свою работу. Общность заключается в том, что у нас обоих есть какая-то базовая инфраструктура, которая имеет дело со всей необходимостью знать, что должно быть на вершине. Он полагается на ShowDialog, показывающий родной z-порядок форм. Я полагаюсь на пользовательский фреймворк, который запоминает, откуда вы пришли.

Опять же, это только подчеркивает, что нет правильного или неправильного - при условии, что оно соответствует требованиям проекта.