Шрифт:
1. Загрузка данных из базы данных. Этот экран предоставляет пользователю возможность подтвердить свои права доступа к базе данных и загрузить данные конкретного пациента. К необходимым служебным данным приложения относятся следующие данные:
• Соединения с базой данных.
• Форма, отображающая пользовательский интерфейс, необходимый для входа в базу данных.
2. Сохранение данных в базе данных. Этот экран предоставляет пользователю возможность подтвердить свои права доступа к базе данных и сохранить данные конкретного пациента. К необходимым служебным данным приложения относятся следующие данные.
• Соединения с базой данных.
• Форма, отображающая пользовательский интерфейс, необходимый для входа в базу данных.
3. Основной экран приложения. Этот экран отображает данные истории болезни пациента, которые были загружены из базы данных, и предоставляет пользователю устройства возможность просматривать данные и переходить от одних данных к другим. К необходимым служебным данным приложения относятся следующие данные:
• Форма для основного экрана.
• Изображения общего назначения, используемые в пользовательском интерфейсе.
4. Экран, отображающий подробную информацию, необходимую для работы с конкретными данными и их редактирования. Этот экран отображается тогда, когда пользователю необходимо редактировать отдельные элементы данных о пациенте или вводить новые данные. К необходимым служебным данным приложения относятся следующие данные:
• Форма для редактирования загруженной записи.
• Пользовательские элементы управления формы, обеспечивающие нестандартные возможности ввода данных (например, пользовательский элемент управления для ввода данных о кровяном давлении с одновременной проверкой корректности ввода или пользовательский элемент управления для редактирования информации о медикаментозных дозах).
5. Экран диаграмм для отображения наборов точек, соответствующих данным. Этот экран предназначается для отображения графической информации, связанной с некоторыми аспектами истории болезни пациента. Например, могут быть построены диаграммы, представляющие изменение кровяного давления или количество белых кровяных телец с течением времени, по которым можно судить о наличии инфекции. К необходимым служебным данным приложения относятся следующие данные:
• Графические перья и кисти, используемые для рисования диаграмм.
• Объекты шрифтов, используемых для отображения надписей на диаграммах.
• Кэшированные фоновые изображения.
• Внеэкранная поверхность растрового изображения, используемая для подготовки изображения диаграммы перед его копированием на экран.
Некоторые из этих состояний разделяют общие ресурсы. Например, графическое перо черного цвета, или шрифт определенного размера, или растровое изображение могут использоваться в нескольких из перечисленных выше состояний. В соединении с базой данных нуждаются два состояния. Кроме того, некоторые объекты могут не требоваться для всех без исключения состояний, но их создание занимает длительное время; в этом случае целесообразно прибегнуть к кэшированию объектов, которое предварительно следует протестировать с точки зрения влияния на производительность.
Создать конечный автомат для управления этими видами ресурсов не составляет особого труда. Все, что требуется сделать при вхождении в новое состояние — это определить, какие объекты необходимо создать, если они к этому времени еще не существуют, и какие из размещенных в предыдущем cocтоянии объектов должны быть удалены из памяти. Управление этой логикой с помощью всего лишь одного конечного автомата, а не посредством кода, разбросанного по всему приложению, позволяет легко поддерживать данную информацию. Кроме того, конечный автомат облегчает проведение экспериментов с различными схемами оптимизации и настройку производительности приложения.
Если объект больше не используется, код вашего приложения может освободить его, удалив все ссылки, которые на него указывают. Занимаемая объектом память будет восстановлена, когда во время очередной сборки мусора (обычно это происходит тогда когда приложению необходимо распределить память) среда выполнения обнаружит, что на данный объект не указывает ни одна ссылка. Обычно такая схема вас будет вполне устраивать, но из нее следует, что удаление объектов из памяти может откладываться на неопределенное время и производиться лишь тогда, когда острая необходимость в дополнительной памяти заставит систему произвести сборку мусора. Поскольку мы не можем точно сказать, когда именно это произойдет, а, следовательно, и судить о том, когда именно будет удален объект, о времени жизни такого объекта в памяти говорят как о "недетерминированном". Недетерминированность очистки памяти от ненужных объектов является обычной проблемой систем управления памятью, использующих сборку мусора. Поэтому, как правило, следует избегать использования в логике приложения кода, выполнение которого связывается с вызовом деструктора объекта поскольку в этом случае приложение не может явно контролировать, когда именно будет выполнен такой код.
Проблемы могут возникать также в тех случаях, когда освобождаемый за ненадобностью объект представляет такой "дорогостоящий неуправляемый ресурс", как соединение с базой данных, файловый дескриптор или некоторый графический ресурс. До тех пор, пока объект не будет удален из памяти во время сборки мусора, неуправляемый ресурс, который он представляет, будет удерживаться приложением. Это может отрицательно сказываться на производительности системы как в отношении клиентского устройства, так и в отношении ресурсов сервера удерживаемых клиентом.
Для того чтобы справиться с этой проблемой, в .NET Compact Framework предусмотрена схема позволяющая коду явно освобождать базовый ресурс, удерживаемый объектом. Для всех объектов, которые представляют дорогостоящие ресурсы, предусмотрен метод Dispose. Определение этого метода содержится в интерфейсе IDisposable; классы, поддерживающие детерминированный отказ от своих ресурсов, реализуют этот интерфейс и, таким образом, включают в себя метод Dispose.
Если объект имеет метод Dispose, то вы всегда можете вызвать этот метод, если необходимость в использовании данного объекта в приложении отпала. Метод Dispose должен вызываться тогда, когда вы собираетесь удалить любые переменные ссылки на него, чтобы предоставить сборщику мусора возможность удалить этот объект из памяти. Тем самым гарантируется, что дорогостоящий объект, представляемый ресурсом, будет немедленно освобожден. Как и в других ситуациях, имеющих отношение к управлению памятью, если в случае приложений для настольных компьютеров такой подход является просто плодотворным, то в случае мобильных приложений, испытывающих дефицит системных ресурсов (таких, например, как дескрипторы операционной системы). ею применение жизненно необходимо.
Точно так же, проектируя класс, который представляет дорогостоящий ресурс, вы должны реализовать интерфейс IDisposable, тем самым предоставляя коду, использующему этот класс, возможность детерминированного освобождения удерживаемых данным классом ресурсов. Для подробного ознакомления с деталями надлежащей реализации этого свойства обратитесь к той части документации .NET Compact Framework, в которой описывается метод IDisposable.Dispose.
На заметку! В языке C# введено специальное ключевое слово, упрощающее вызов метода Dispose в тех случаях, когда область использования ресурса ограничивается блоком кода функции. Вместо обязательного явного вызова метода .Dispose можно объявить соответствующую переменную с помощью ключевого слова using.
Например:
В случае использования такого объявления метод Dispose вызывается автоматически при выходе за пределы области видимости переменной. Ключевое слово using очень удобно использовать в тех случаях, когда переменная существует только внутри некоторого блока кода.
Управление объемом пользовательских данных, хранящихся в памяти
Пользовательские данные представляют собой фактические данные, которые может просматривать или которыми может манипулировать пользователь приложения. Управление объемом и временем жизни пользовательских данных, хранящихся в памяти, может оказаться более сложным по сравнению с управлением служебными данными приложения, поскольку в зависимости от структуры и назначения приложения природа данных, сохраняемых в памяти, может быть самой различной. Пользовательские данные шахматной игры отличаются своей структурой от пользовательских данных истории болезни пациента. Состояние шахматной доски может храниться в целочисленном массиве фиксированных размеров. Объем данных истории болезни не может быть заранее определен; эти данные могут включать в себя результаты измерений, текстовые записи, изображения, ссылки на дополнительные данные и почти неограниченный объем любой другой подходящей информации.