диплом (Мобильное приложение для оформления заказов на транспортировку товаров), страница 6

Метод onDestroy() – это последний вызов, который Активити получает перед разрушением, это происходит либо потому, что был вызван метод finish() и Активити завершается, или потому, что система временно разрушает экземпляр Активити, чтобы высвободить память (метод isFinishing() может определить какая из этих двух ситуаций имеет место быть).

Любой Активити может быть принудительно уничтожен системой, только если он находится в состоянии onDestroy() или onStop().

Жизненный цикл Активити представлен на рисунке 9.

Рисунок 9 – Жизненный цикл Активити

Полный жизненный цикл приложения начинается первым вызовом onCreate(Bundle) и заканчивается вызовом onDestroy(). В onCreate() Активити получает основные нужные для его работы ресурсы и высвобождает все оставшиеся после выполнения функций Активити ресурсы в onDestroy().

Видимый жизненный цикл Активити начинается вызовом метода onStart() и заканчивается соответствующим ему вызовом метода onStop(). В течении видимого жизненного цикла пользователь видит Активити на экране, хотя оно не обязательно находится на переднем плане и взаимодействует с пользователем. Этими двумя методами можно управлять ресурсами, необходимыми для отображения Активити пользователю.

Активный жизненный цикл Активити заключен между вызовом onResume() и соответствующим вызовом onPause(). Во время этого жизненного цикла Активити находится на переднем плане и взаимодействует с пользователем. Активити может часто переходить из состояния «Приостановлен» к состоянию «Возобновление работы», поэтому не рекомендуется нагружать эти методы излишним кодом [26-27, 34].

Реализацию Активити начинается с реализации метода onCreate(). Любой метод onCreate() сначала вызывает super.onCreate(savedInstanceState), savedInstanceState позволит восстановить сохраненное состояние Активити, если оно было уничтожено системой, когда он был скрыт от пользователя. Далее следует установить Активити соответствующее ему отображение с помощью setContentView(), где в качестве параметра следует указать либо непосредственно отображение View, либо целочисленный идентификатор XML-макета из ресурсов.

Далее следует инициализировать все объекты, которые расположены на макете или отображении, чтобы ими впоследствии можно было манипулировать, для этого используется метод findViewById(), где в качестве аргумента указывается идентификатор элемента из ресурсов, помимо этого результат findViewById() должен быть явно приведен к типу элемента, который инициализируется, так как метод возвращает объект View (например, user = (EditText) findViewById(R.id.teUsername) инициализирует EditText, хранящий в себе имя пользователя).

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

View.OnClickListener является интерфейсом, следовательно требует переопределение метода onClick(View), входящего в него. Если на макете находится всего один объект для которого требуется установить обработчик нажатия, то новый экземпляр View.OnClickListener можно объявить прямо внутри setOnClickListner() и там же перегрузить метод onClick(). Однако если таких элементов несколько, то имеет смысл реализовать интерфейс прямо внутри Активити (в заголовке класса Активити следует указать implements OnClickListener). Тогда за обработку нажатий будет отвечать один централизованный метод onClick (помимо этого не требуется создавать никаких дополнительных объектов). Определить на каком из элементов сработало нажатие можно, получив идентификатор объекта, переданного onClick, как параметр, с помощью метода getId().

В главе 3 упоминалось, что профиль пользователя организован на основе ListView. Рассмотрим подробно его инициализацию и создание обработчика (листинг приведен ниже).

private static final String[] headers = new String[] {"Мои заявки", "Подать заявку", "Архив заявок", "Настройки", "Выйти из аккаунта"};

protected void onCreate(Bundle savedInstanceState) {

ArrayAdapter<String> adapter= new ArrayAdapter<String> (this, android.R.layout.simple_list_item_1, android.R.id.text1,

headers);

listView.setAdapter(adapter);

listView.setOnItemClickListener(new AdapterView.OnItemClickListener() {

@Override

public void onItemClick(AdapterView<?> parent, View view, int position, long id) {

int itemPos = position;

switch (itemPos){

case 0:

Intent in = new Intent(Profile.this,MyOrders.class);

in.putExtra("aim",0);

startActivity(in);

break;

}}});

В переменной headers объявляется массив заголовков, который позже будут помещены в ListView, массив объявлен как private static final, что делает его принадлежащим классу, а не экземпляру, доступным только методам класса и сохраняющим содержимое неизменным после инициализации.

Далее в onCreate() создается адаптер ArrayAdapter, использующий стандартный макет simple_list_item_1 для отображения массива строк headers в виде простого списка. Далее адаптер соединяется с ListView и элементы станут видимы на экране. Однако если для требуется, чтобы элементы списка реагировали на нажатие, то списку следует установить onItemClickListener, создать новый объект AdapterView.onItemClickListener и в переопределенном методе onItemClick реализовать обработчик нажатия для элементов списка. Например, в листинге выше при нажатии на первый элемент списка будет создан новый Активити MyOrders, который сменит текущий Активити в вершине стека Активити.

Схожим с ListView образом инициализируется выпадающий список Spinner, однако для организации его работы ArrayAdapter использует макет android.R.layout.simple_spinner_item и для адаптера также требуется указать setDropDownViewResource(android.R.layout.simple_dropdown_item_1line), метод который непосредственно организует отображение для выпадающего меню.

В работе уже ранее упоминался вспомогательный класс Validator, задачей которого является проверка корректности заполнения форм. В общем случае такая проверка осуществляется, только после того, как пользователь уже нажал кнопку отправки формы, однако это не всегда удобно. Для того, чтобы осуществить проверку еще до того, как форма была отправлена требуется к элементам TextEdit добавить TextChangedListener и реализовать в Активити TextWatcher. Интерфейс TextWatcher имеет три публичных метода, доступных для переопределения, afterTextChanged(), вызывается в случае, если текст в объекте был изменен, beforeTextChanged(), вызывается перед тем, как текст начнут изменять, onTextChanged(), вызывается, если текст только что был изменен и позволяет определить сколько символов и с какой позиции было изменено.

Для работы с классом Validator потребуется только метод afterTextChanged(), однако требуется присутствие все трех методов, иначе класс станет абстрактным. В afterTextChanged() требуется вызвать соответственный полю EditText метод класса Validator. В случае, если поле заполнено с нарушением, то рядом с полем будет выведено сообщение об ошибке и на поле появится иконка ошибки (рисунок 10).

Рисунок 10 – Сообщение об ошибке

Однако для полной проверки корректности данных в Активити требуется создать еще один метод, который проверит все нужные поля перед отправкой формы (пример в листинге ниже).

private boolean validate(){
boolean result = true;
if(!Validator.notEmpty(city)) result = false;
if(!Validator.notEmpty(street)) result = false;
return result;
}

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

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

Как было упомянуто в 3 главе процесс регистрации нового пользователя из-за большого объема принимаемых данных был разделен на два экрана. На первом экране пользователь заполняет форму для авторизации и сохранения личных данных, второй экран содержит форму для внесения данных о компании, которую пользователь представляет.

В базе данных таблица пользователей users хранит, соотнесенную с каждым пользователем ссылку идентификатор организации, которую они представляют. Таким образом поле в таблице пользователей является внешним ключом к таблице организаций, из чего логично следует, что данные об организации требуется внести в таблицу прежде, чем будет создана запись о пользователе. Проблема очередности записи может быть решена снятием ограничения внешнего ключа, но это может в конечном итоге привести к нарушению целостности данных. Вместо этого в приложении при переходе с одного экрана регистрации, то есть из одного Активити в другой, данные не пересылаются на сервер, а переходят в другой Активити и уже после заполнения формы данных о компании отправляются на сервер.

Для того чтобы организовать передачу данных из одного Активити в другой можно присоединить данные к вызывающему новый Активити интенту.

Интентам для работы требуются два атрибута: действие (например, ACTION_VIEW, ACTION_MAIN) и данные (например, URI). Однако интенты позволяют использовать еще четыре дополнительных атрибута: категория (несет в себе вспомогательную информацию о действии, которое выполняется, например CATEGORY_LAUNCHER), тип (явно определяет тип данных интента, обычно тип определяется непосредственно по данным, если такой параметр установлен, то используется тип указанный явно), компонент (определяет явно имя компонента, используемого в интенте, обычно компонент определяется по всей совокупности данных в интенте (действие, данным и категории), подходящие компоненты выбираются сопоставлением с этим набором данных, если компонент установлен явно, то все вычисления пропускаются и он используется напрямую, если компонент определен явно, все остальные параметры интента становятся необязательными) и дополнительные данные (набор любой дополнительной информации).

Присоединить данные аутентификационные и личные данные о пользователе, как дополнительные данные интенту, вызывающему Активити с формой данных о компании, можно с помощью метода putExtras().

Дополнительные данные организуются в виде простых пар «ключ-значение» [26-27].

После того, как создан новый Активити, данные из предыдущего – можно получить с помощью методов вида getIntent().getStringExtra(String key), где вместо String используется подходящий тип дополнительных данных.

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

Android предлагает ряд средств для работы в фоновом режиме, таких как Executor, ThreadPoolExecutor, AsyncTask и т.д. Однако обмен текстовыми данными в формате JSON не предполагает, что фоновые операции будут длится в течении длительного периода времени, поэтому наиболее подходящим вариантом выступает AcyncTask.

AsyncTask – это абстрактный класс специально предназначенный для работы с краткосрочными операциями (до нескольких секунд). Асинхронная операция определяется вычислениями, выполняющимися в фоновом потоке, чей результат отображается в поток пользовательского интерфейса. Асинхронная операция определяется тремя обобщенными типами: Params (тип аргументов, передаваемых операции для выполнения), Progress (тип данных о прогрессе операции, отображаемые во время фоновой операции) и Result (тип результата, возвращаемого из фоновых вычислений), и четырьмя этапами: onPreExecute(), doInBackground(), onProgressUpdate() и onPostExecute().

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

Метод doInBackground() вызывается в фоновом потоке сразу же после того, как был выполнен onPreExecute(). Этот этап непосредственно выполняет фоновую операцию и может занять какое-то время. Все параметры необходимые асинхронной операции передаются на этом этапе. Метод обязательно возвращает результат операции, который будет передан следующему этапу, если таковой реализован. Этот же метод может быть также использован для обновления прогресса операции с помощью publishProgress(Progress...), где указанные значения будут переданы в поток пользовательского интерфейса во время этапа onProgressUpdate(Progress...).

Метод onProgressUpdate(Progress...) вызывается после вызова publishProgress(Progress...). Время выполнения не определено. Метод может отображать прогресс в любой форме, пока продолжается выполнение операции в фоновом потоке. Очень часто этот метод используют для анимации индикатора прогресса или вывода логов.