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

Сценарии первой группы рассмотрим на примере сценария, создающего новую заявку от пользователя.

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

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

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

Далее необходимо получить недостающие для создания записи данные.

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

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

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

$query = "insert into orders (oClientID, oFCityID, oFStreetID, oFHouse,oFBuilding, oTCityID, oTStreetID, oTHouse, oTBuilding, oInsurance, oSize, oMass,oCustom, oDuty) values(:client, :fcity, :fstreet, :fhouse, :fbuilding, :tcity, :tstreet, :thouse, :tbuilding, :insurance, :sze, :mass, :custom, :duty);";

$opt = array(":client" => $userID,

":fcity" => $fromCity,

":fstreet" => $fromStreet,

":fhouse" => $_POST['fHouse'],

":fbuilding" => $_POST['fBuilding'],

":tcity" => $toCity,

":tstreet" => $toStreet,

":thouse" => $_POST['tHouse'],

":tbuilding" => $_POST['tBuilding'],

":insurance" => $_POST['insurance'],

":sze" => $_POST['size'],

":mass" => $_POST['mass'],

":custom" => $_POST['custom'],

":duty" => $_POST['duty']);

try{

$prep = $db->prepare($query);

$prep->execute($opt);

}

catch (PDOExeption $ex){

$response["success"] = 0;

$response["message"] = "Database Error! Please Try Again.";

$response["error"] = $ex->getMessage();

die(json_encode($response));

}

$response["success"] = 1;

$response["message"] = "Order Successfully Placed!";

die (json_encode($response));

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

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

Далее в блоке try-catch запрос устанавливается связь с базой данной и подготавливается к выполнению командой prepare, команда execute инициирует выполнение запроса, подменяя заполнители на реальные данные.

Три строки таблицы orders (структура представлена на рисунке 3) заполняются автоматически, идентификационный номер oID формируется автоинкрементом, идентификационный номер статуса выполнения oStatID получает по умолчанию значение 1, соответствующее статусу «Заявка принята в обработку», поле даты создания oCreationDate имеет тип timestamp и автоматически сохраняет дату и время создания поля.

Если блок try-catch выполняется без выбрасывания исключения, то сценарий формирует отклик об успешном выполнении и отправляет инициализировавшему его выполнение приложению ответ в JSON-представлении.

Следующая группа сценариев осуществляет редактирование уже существующих данных. Рассмотрим подобные сценарии на примере сценария обновляющего пароль пользователя.

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

После этого требуется внести изменения в соответствующую запись в базе данных (листинг приведен ниже).

$query = "update users set uPassword = :newpass where uID = :id;";

$opt = array(":id" => $uID,":newpass"=>$_POST["newPassword"]);

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

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

$query = "select oID, oStatID, oCreationDate from orders where oClientID = :uid and oStatID <> :statLim group by oCreationDate DESC;";

$opt = array(":uid" => $uID, ":statLim" => $statLimit);

В переменной query подготавливается запрос на выборку заголовочных данных о заказа (идентификационный номер, статус и дата создания), где в качестве ограничителей выступают идентификационный номер пользователя и значение статуса (в выборке участвуют только заявки, статус которых не установлен в значение «Выполнен»), далее полученные данные выборки упорядочиваются по дате создания в порядке убывания.

После успешного получения данных, их нужно преобразовать в JSON и оправить приложению (листинг приведен ниже).

if($rows){

$response["success"] = 1;

$response["message"] = "Orders have been found!";

$response["orders"] = array();

foreach ($rows as $row) {

$order = array();

$status = findStatus($db, $row["oStatID"]);

$order["oID"] = $row["oID"];

$order["oStat"] = $status;

$order["oCreationDate"] = $row["oCreationDate"];

array_push($response["orders"], $order);

}

echo json_encode($response);}

PHP-функция json_encode позволяет преобразовать различные данные в JSON-представление. Наиболее удобный и очевидный способ перевода данных в JSON-представление является формирование ассоциативного массива с данными полученными из базы данных.

В листинге выше формируется ассоциативный массив с тремя ключами success – флаг успеха выполнения, message ­– сообщение, ассоциированное с флагом выполнения и orders – вложенный ассоциативный массив, в свою очередь состоит из трех ключей oID – идентификатор заказа, oStat – статус заказа и oCreationDate – дата и время создания заказа, функция array_push помещает данные о каждом единичном заказе в массив с ключом orders. После того, как все данные сохранены в ассоциативный массив, функция json_encode завершает преобразование данных в JSON-представление и передает результат приложению [25, 26].

Все остальные необходимые для работы приложения сценарии создаются с использованием описанных выше методов. Примеры полных сценариев расположены в приложении Б.

4.2 Разработка приложения. Файл манифеста Android

Всю первичную необходимую информацию о приложении Android получает из XML-структурированного файла манифеста, AndroidManifest.xml.

Обязательными префиксом любого манифеста является строка <?xml version="1.0" encoding="utf-8"?>, указывающая на используемую версию XML и кодировку.

Сам содержательная часть манифеста помещается в парный тег <manifest>, который является корневым. Если приложению требуется получить от пользователя разрешение на использование определенных функций устройства, например, использовать камеру, то внутри корневого тега объявляется одиночный тег <uses-permission>. Разрешение на использование функций, объявленных таким тегом, подтверждается (или не подтверждается) единожды, в момент установки приложения пользователем. Во время работы с приложением пользователь не будет получать никаких оповещений о необходимости выдать разрешение на использование функции, если при установке приложение разрешение не получило, то все попытки использовать неразрешенную функцию будут остановлены без оповещения пользователя. В случае приложения, разрабатываемого в рамках данной работы, требуются два разрешения ACCESS_NETWORK_STATE, позволяющее просматривать статус доступа к сети, и INTERNET, гарантирующий доступ приложению к сети Интернет для обмена информацией с базой данных.

Внутри корневого тега размещается тег <application>, являющийся родительским для тегов компонентов приложения. Тег <application> имеет ряд атрибутов, например, атрибут icon указывает на иконку, используемую для запуска программы, label – на называние приложения, а theme – используемую тему оформления.

Внутри тега <application> объявляются требуемы компоненты приложения (например, Активити, службы, контент-провайдеры и т.д.). Любой компонент, исключая широковещательный приемник, не объявленные в манифесте не будут созданы Android.

В приложении требуется объявить через тег <activity> нужные Активити, представляющие собой класс, выполняющий определенные функции, связанные с XML-макетом, с которым пользователь может взаимодействовать непосредственно (в отличии, например, от службы, работающей в фоновом режиме). Для того чтобы выделить один из Активити для выполнения при запуске приложения требуется внутри Активити объявить фильтр интентов через тег <inten-filter>.

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

– для отсылки широковещательного сообщения;

– для запуска службы;

– для запуска Активити.

В первом случае, интент создается, чтобы разослать широковещательное сообщение о каком-либо системном событии, в таком случае интент передается методам sendBroadcast(), sendOrderedBroadcast() или sendStickyBroadcast().

Во втором случае, интент передается методу bindService() или startService(), в таком случае интент содержит описание службы, компонента, выполняющегося в фоновом режим, и все требуемые ей данные.

В третьем случае, интент используется для запуска нового Активити, содержит описание Активити, которую нужно запустить и все требуемые для этого данные, и передается методу startActivity() или startActivityForResult(). При вызове второго метода от Активити, которую запустит интент потребуется результат, оформленный в виде другого интента, отправляемый в методе обратного вызова onActivityResult().

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

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