DroidScript
DroidScript
учимся и разрабатываем

Порядок инициализации объектов в функции OnStart

06.04.2017

При инициализации приложения в функции OnStart происходят следующие действия:

  • Создание объектов
  • Настройка свойств объектов
  • Компоновка объектов
  • Отображение компоновок на экране

Порядок следования данных операций не важен, за исключением единственного момента: перед использованием объектов их нужно создать. Любое действие с несуществующим объектом вызовет ошибку при выполнении приложения.

То есть, теоретически после создания объектов все остальные действия с ними можно выполнять в любом порядке, например, как показано в примере ниже.

Выполнить

Это пример прекрасно работает, но так писать код не рекомендуется по причине того, что все операции в нём перемешаны. При работе с 20 объектами в таком стиле код превратиться в один запутанный клубок, в котором будет сложно понять какие объекты созданы и каким компоновщикам добавлены. Запутанный и сложный код - это источник ошибок и проблем. Для эффективной разработки и поддержки приложений лучше произвести группировку однотипных действий по разделам.

Выполнить

Преимущества показанной группировки следующие:

  • Все компоновщики и элементы сгруппированы в своих разделах. Это позволяет создавать и удалять их независимо друг от друга
  • Связывание компоновщиков и элементов производится в отдельном разделе перед отображением компоновки, что позволяет делать это компактно и наглядно по сравнению с тем способом, когда компоновщик следует сразу за элементом и приходится искать по всему коду какиие элементы добавлены тому или иному компоновщику
  • Если необходимо установить размер одних объектов в зависимости от каких-то условий, то это производится после отображения компоновки. До вызова метода app.AddLayout размеры всех объектов равны 0, даже если они заданы в конструкторах или методах установки размеров. После выполнения метода app.AddLayout элементы становятся видимыми и при их большом количестве пользователь видит неприятный эффект постепенной прорисовки интерфейса. Для устранения этого эффекта объекты при создании делаются невидимыми, а их отображение производится после полного построения интерфейса.

В самом конце присутствует интерфейсный раздел. В этом разделе в глобальное свойство-массив controls добавляются объекты (компоновщики и элементы), к которым необходимо обращаться во внешнем коде. Это гарантирует то, что никто за пределами функции инициализации не сможет изменить элементы интерфейса, которые не предназначены для изменения или взаимодействия с пользователем, что делает код более надёжным. В приведённом выше примере доступ открыт только к объекту _btn.

Можно ли отдельные разделы поместить в разные функции, например, создавать компоновщики в одной функции, объекты- в другой, компоновать их в третьей и т.д.? Можно, но это приведёт к следующему: для доступа к объектам из разных функций первые должны быть общедоступны. Для чего открывать доступ к объектам интерфейса, которые не требуется менять во внешнем коде?

© 2016-2024 
actech