Оглавление (стр. 3 )

JSON (JavaScript Object Notation) -- простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. JSON - простой, основанный на использовании текста, способ хранить и передавать структурированные данные. С помощью простого синтаксиса пользователь может легко хранить все, что угодно, начиная от одного числа до строк, массивов и объектов, в простом тексте. Также можно связывать между собой массивы и объекты, создавая сложные структуры данных. После создания строки JSON, ее легко отправить другому приложению или в другое место сети, так как она представляет собой простой текст. JSON имеет следующие преимущества:

·  Компактность, по сравнению с XML;

·  Легкость в чтении как человеком, так и машиной;

·  Легкость преобразования в структуру данных для большинства языков программирования;

·  Многие языки программирования имеют функции и библиотеки для создания и чтения JSON.

1.8 Обоснование выбора метода хранения данных

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

Было проведено сравнение XML и JSON по следующим критериям:

1.  Простота, открытость и взаимодействие;

2.  Расширяемость;

3.  Удобство чтения человеком;

4.  Полная интеграция всех возможных форматов;

5.  Обмен простыми данными;

Результаты сравнения:

·  В вопросах простоты, открытости и взаимодействия XML и JSON различия минимальны;

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

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

Рисунок 8. Пример структуры JSON

Рисунок 9. Пример структуры XML

В данном случае и JSON, и XML читаются одинаково удобно из-за наличия в обоих структурах только простых элементов.

Как было отмечено ранее, в XML, в отличие от JSON, пользователь может хранить любые типы данных, что не всегда хорошо. Например, в XML добавить исполняемый файл, что может быть опасным для безопасности. JSON, благодаря своей простоте, позволяет избежать использования данной лазейки.

· Для обмена и обработки простых данных JSON подходит лучше, так как использует массивы и объекты, в то время, как XML хранит данные в дереве. Оба этих метода имеют свои преимущества, но обмен и обработка данных намного проще, когда данные хранятся в структуре, родной для объектно-ориентированных языков программирования. Эта особенность позволяет с легкостью импортировать файлы из JSON в объектно-ориентированные языки программирования, например, в Java, Perl, Ruby, Python. В случае с XML, перед импортированием данных их требуется сначала преобразовать.

В обоих случаях необходимо не только создать структуру, но и хранить ее. Хранить данные можно в виде отдельного файла, либо в виде SharedPreference. SharedPreferences – это класс, который позволяет сохранять и извлекать данные в виде пар "ключ-значение". Данные будут храниться в виде строки.

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

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

.

Рис. 10. Файл со структурой JSON

1.9 Обзор метода проектировки пользовательского интерфейса

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

1.  Интерфейс должен быть понятен и легок к освоению наибольшему кругу лиц (т. е. иметь наименьший порог вхождения);

2.  Предоставлять пользователю возможность ввода информации, не показывая процесс вычислений;

3.  Отвечать всем потребностям пользователя, не заостряя его внимания на процессе обработки данных.

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

Пользовательский интерфейс должен удовлетворять следующим требованиям:

1.  Цветовая гамма приложения не должна быть яркой и содержать «кислотные цвета», но при этом сочетание цветов должно быть контрастным;

2.  Дизайн должен быть простым и понятным, необходимо избегать использование непонятных иконок и пространственных описаний;

3.  Навигация между окнами также должна быть предельно простой и понятной. У пользователя нет никакого желания блуждать в «лабиринте» из разных окон;

4.  Хорошим тоном также является наличие обратной связи с пользователем. Приложение должно уведомлять пользователя о том, что оно откликнулось на какой-либо запрос.

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

1.10 Android Guidelines

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

ГЛАВА 2 ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Activity

Activity, или активность — аналог формы в программировании настольных приложений. Чаще всего, активности взаимодействуют с пользователем посредством пользовательского интерфейса. Активность, запускающаяся при старте приложения, считается главной. Из главной активности можно запускать другие активности, притом, не всегда активности, запускаемые из главной, должны принадлежать одному и тому же приложению.

2.2 Жизненный цикл активности

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

1.  Активная — активность находится на переднем плане экрана. Пользователь может взаимодействовать с активным окном:

2.  Приостановленная — активность потеряла фокус, но все еще видима пользователю. То есть, активность находится сверху и частично перекрывает данную активность. Приостановленная активность может быть уничтожена системой в критических случаях при нехватке памяти;

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

Рисунок 11. Жизненный цикл Activity

2.3 Service

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

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

При использовании сервисов приложения будут продолжать свою работу даже в неактивном состоянии.

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

2.4 Жизненный цикл сервисов

Подобно активностям, сервисы имеют свой жизненный цикл.