Разработка мобильного приложения игры для тренировки памяти для ОС Android

Министерство образования и науки Российской Федерации

ФГАОУ ВПО «Северо-Восточный федеральный университет им. М.К.Аммосова»

Институт математики и информатики

Кафедра информационных технологий













ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка мобильного приложения игры 

для тренировки памяти для ОС Android







Выполнила: студент ИВТ-13 ИМИ Варламова Татьяна Валерьевна

Научный руководитель:

Павлов Александр Викторович, доцент кафедры ИТ, к.ф.-м.н.

















Якутск
2017



Оглавление



	Введение	3

		1	Теоретическая часть	4

		1.1	Платформа Android и средства разработки приложений для нее	4

		1.2	Понятие аналитики мобильных приложений	6

		1.3	Анализ приложений конкурентов	15

		1.4	Сервисы для анализа мобильных приложений	16

	Вывод по 1 главе	17

		2	Практическая часть	18

		2.1	Игра для тренировки памяти	18

		2.2	Анализ использования приложения на примере игры для тренировки памяти	20

	Заключение	21

	Список литературы	22















Введение

		

	Данная работа посвящена разработке приложения для тренировки памяти на платформе Android.

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

	ОС Androidразработана на ядре Linux. Гибкость настроек системы Android чрезвычайно удачно сочетается с удобным инструментарием, что является идеальным решением для создания новых приложений. Основным источником для Android-устройств является PlayMarket. Приложения для Android компилируются в нестандартный байт-код Java, рекомендуемым средством разработки от Google является Android SDK, в котором используется Java. Также доступны средства разработки сторонних поставщиков, в том числе кроссплатформенные и использующие другие языки программирования.

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

	изучить архитектуру, инструменты и особенности разработки приложений для ОС Android;

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

	разработать приложение на Android;

	протестировать разработанное приложение;

	загрузить приложение в GooglePlayMarket.



	Теоретическая часть



Платформа Android и средства разработки приложений для нее

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

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

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

В Android можно запускать много приложений. Но одно из них является главным и занимает экран. От текущего приложения можно перейти к предыдущему или запустить новое. Это похоже на браузер с историей просмотров.

Каждый экран пользовательского интерфейса представлен классом Activity в коде. Разные Activity содержатся в процессах. Activity может даже жить дольше процесса. Activity может быть приостановлена и запущена вновь с сохранением всей нужной информации.

Компоненты приложений в Android

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

Всего в Android-приложениях существует четыре типа компонентов:

Activity;

Service;

BroadcastReceiver;

ContentProvider.

Взаимодействие этих компонентов осуществляется с помощью объектов Intent. Кратко рассмотрим все компоненты и их взаимодействие.

Activity

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

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

Service

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

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

BroadcastReceiver

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

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

ContentProvider

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

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

Объекты Intent

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

Поэтому, в отличие от приложений в большинстве других систем, у приложений Android нет единственной точки входа для запуска всего приложения, аналогичной, например, функции main() в C-подобных языках программирования. Программа может иметь несколько точек входа.

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

В системе Android все коммуникации между приложениями, службами и отдельными компонентами происходят только с использованием объектов Intent. 



Понятие аналитики мобильных приложений



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

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

	магазин приложений;

	поведение пользователя;

	источник трафика.

Все эти типы систем отличаются между собой по источнику данных и целевой направленности. Описания свойств типов систем представлены в таблице 1.

Таблица 1. Свойства типов систем

Аналитика магазинов приложений

Аналитика поведения пользователей

Аналитика источников трафика

Данные из консоли разработчика

Данные из встроенного SDK

Данные из встроенного SDK

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

Изучение поведения пользователей в приложении.

Анализ скачиваний и поведение привлеченных пользователей для различных источников трафика.

	

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

	Аналитика поведения пользователя должна показывать, как именно используется приложение.

	Аналитика источников трафика отслеживает эффективность рекламы из различных каналов.

	Основные виды метрик.

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

	источник установки приложения – информация о том, откуда пользователь узнал о приложении;

	удержание пользователей – сколько человек запустило приложение спустя разное количество дней после установки;

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

	сессия – продолжительность взаимодействия с приложением, какие экраны приложения посещал пользователь, когда и как завершена сессия;

	взаимодействие с интерфейсом – какие кнопки и в какой последовательности были нажаты, А/В тесты и т.д.;

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

Источник установки приложения

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

Удержание пользователей

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

Чтобы оценить интересность для пользователей, чаще всего снимаются метрики:

	1-day retention. Метрика означает долю пользователей (%), открывших приложение на следующий день после установки. То есть это количество тех, кого продукт заинтересовал настолько, что они очень быстро к нему вернулись. Низкое значение этого показателя говорит о том, что пользователей что-то не устраивает в приложении. Чаще всего плохой «1-day retention» говорит о проблемах с интерфейсом: он может быть неудобен и/или непонятен, это первое, чем нужно заняться для исправления ситуации. Ведь если пользователь не вернулся на следующий день, то с высокой вероятностью не вернётся совсем. Так что повышение значения этой метрики — одна из важнейших задач после выкладывания приложения.

	Вычисляется по формуле: 

	1DR = X1 / Z,

	где X1 — количество пользователей, запустивших приложение на следующий день, Z — общее количество установивших.

	7-day retention. Доля пользователей, вернувшихся спустя неделю после установки. Если этот показатель ниже «1-day retention», значит пора проанализировать, что пользователей может не устраивать после более продолжительного, недельного знакомства с приложением. Возможно, стоит пересмотреть подход к usecases.

	Вычисляется по формуле: 

	7DR = X7 / Z,

	где X7 — количество пользователей, запустивших приложение на седьмой день, Z — общее количество установивших.

	28-day retention. Доля тех, кто воспользовался приложением на 28-й день после установки. Если даже месяц спустя люди возвращаются к продукту, то это говорит о том, что он импонравился. Уменьшение значения этой метрики по сравнению с предыдущей свидетельствует о каких-то глубоких, неявных, стратегических недостатках. 

	Вычисляется по формуле: 

	28DR = X28 / Z,

	где X28 — количество пользователей, запустивших приложение на двадцать восьмой день, Z — общее количество установивших.

Все три метрики снимаются ежедневно, при каждом запуске приложения сравниваются текущая дата и дата установки. Анализ динамики изменения каждой из метрик позволит также понимать реакцию пользователей на те или иные изменения, вносимые вами в приложение. Например, уровень 1-day retention обычно свидетельствует о том, как пользователи реагируют на интерфейс приложения. И если этот показатель начал снижаться, то в первую очередь необходимо проверить, что не так с интерфейсом. 

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

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

Количество уникальных пользователей в течение определённого периода

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

	DAU (DailyActiveUsers)– количество уникальных пользователей в день.

	WAU (WeeklyActiveUsers)– количество уникальных пользователей в неделю. 

	MAU (MonthlyActiveUsers)– количество уникальных пользователей в месяц. 

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

Также можно вычислять производную метрику StickyFactor = DAU/WAU или DAU/MAU. Её название можно перевести как «степень липкости». Она характеризует регулярность использования приложения в течение недели или месяца, то есть позволяет оценить, насколько людям нравится приложение на основании частоты использования. Если все пользователи будут запускать программу каждый день, то DAU будет равен и WAU, и MAU, а их отношение будет равно 100%. Но так не бывает, и потому StickyFactor позволяет оценить, насколько часто люди обращаются к приложению в течение недели или месяца. Логично, что снижение этих показателей — неприятный сигнал, говорящий об охлаждении аудитории. 

Сессия

Сессия — это время, которое пользователь провел в мобильном приложении с момента запуска до окончания его использования. Применительно к сессиям снимается обычно две метрики:

	общее количество сессий за период;

	средняя продолжительность сессии (AverageSessionLength, ASL)–среднее арифметическое всех длин сессий за некоторый временной интервал. Вычисляется по формуле:

	ASL = T / N, 

	где T — суммарная продолжительность сессий за период, N — общее количество сессий за тот же период.

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

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

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

Другой пример: если у разработчика есть форма заказа товара, состоящая из 3-4 экранов, то эта метрика покажет, на каком шаге большинство пользователей покидает приложение. В качестве решения можно уменьшить количество шагов, оптимизировать их порядок или оформление.

Взаимодействия с элементами интерфейса

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

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

Финансы

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

Первое, что приходит в голову — общая сумма платежей за период, Gross. Однако надо иметь в виду, что это брутто-доход, из которого придётся ещё вычесть долю магазина, через который распространяется приложение. А после вычета получают метрику Revenue, которая отражает сумму, поступающую на счёт.

Допустим, само приложение бесплатное, но часть контента доступна только за деньги — разработчик распространяет его по модели in-apppurchases. Для развития приложения и увеличения дохода нужно знать, сколько уникальных пользователей платят в течение заданного периода. 

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

Помимо количества плательщиков интересует и удельное количество платежей на одного пользователя, Transactions by User. Эта метрика вычисляется по формуле:

TBU = T / PU,

где T — общее количество платежей (транзакций) за какой-то период, PU (payingusers) — общее количество плательщиков за тот же период.

Если TBU > 1, значит часть пользователей делали более одной покупки. 

Следующие важные метрики ARPU и ARPPU:

	ARPU (AverageRevenuePerUser)– средняя прибыль с одного пользователя за период. Вычисляется по формуле: 
ARPU = Gross / DAU, или Gross/WAU, или Gross/MAU.

	ARPPU (AverageRevenuePerPayingUser)– средняя прибыль с одного платящего пользователя за период. Вычисляется по формуле: 

	ARPPU = Gross/PU,

	где PU — общее количество уникальных пользователей, заплативших за контент в приложении в течение какого-то периода. 

	Эта метрика позволяет оценить удельную прибыльность этого сегмента аудитории. А динамика изменения ARPPU даёт сигнал об отношении плательщиков к ценам/качеству платного контента.

Говоря о получаемой с пользователей прибыли нельзя забывать и о том, во сколько обходится их привлечение. В качестве метрики здесь используется стоимость одной установки приложения (CPI, CostperInstall). Вычисляется по формуле:

CPI = A/I,

где А — стоимость рекламы, продвижения и маркетинга, I — количество установок приложений.

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

Метрика LTV (LifetimeValue) — это удельная прибыльность пользователя на протяжении всего периода использования им приложения. Существует масса способов вычисления LTV, но для начала можно воспользоваться формулой:

LTV = ARPU * Lifetime,

где Lifetime — это усреднённая продолжительность использования приложения начиная с первого запуска и заканчивая последним. Если пользователь впервые зашёл в приложение 1 января, а последний раз — 15 августа и больше им не пользовался, то для него Lifetime равен 7,5 месяцев. Просуммировав Lifetime для всех пользователей и разделив на их общее количество, мы получим среднее значение этой метрики, которое и будет использовано при расчёте LTV.

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

Анализ приложений конкурентов

Идеи для развития своего проекта, в частности, приложения, нужно черпать отовсюду. В том числе и смотреть, что интересного появилось у конкурентов. AppStoreOptimization (ASO) и аналитические инструменты могут много чего подсказать разработчику приложения о том, как продвинуть свою программу, увеличить количество загрузок, сделать ее более заметной в поисковой выдаче каталога. Причем очень выгодным может быть анализ схожих с приложениями, выпущенных другими разработчиками.

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

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

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

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

	скриншоты – они очень значимы, так как делают приложение наиболее заметным в поисковой выдаче и повышают уровень загрузок;

	отзывы и рейтинги – очень сильно влияют на скачиваемость приложения. Также пользователи указывают то, что нравится или не нравится больше всего, поэтому стоит обратить внимание на отзывы, которые относятся к приложению;

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

	Таким образом, анализ приложений конкурентов может быть хорошим «оружием», который поможет создать и улучшать собственное приложение.



Вывод по 1 главе

Практическая часть

Создание приложения в Android Studio

Приложение называется английским словом «Memory», который переводится как «память». Она относится к категории классических игр для развития памяти. Несомненным ее преимуществом является то, что она реализована просто, но при этом подходит и взрослым, и детям.

В этой игре перед пользователем 36 перевернутых карт и у каждой из них есть пара. Разрешается перевернуть только две из них. В случае совпадения карты исчезают с игрового поля. Надо найти 18 пар.

Каждый переворот карты считается за 1 ход, время отсчитывается с момента перевертывания первой карты.

Было задумано сделать 3 формы:

Форма 1. Основное меню

Данная форма имеет 4 кнопки: Старт, Настройки, Рекорды и Выход





Рис. 1 Основное меню

Форма 2. Игра

Содержит поле для игры



Рис. 2 Игровой процесс

Форма 3. Диалог финиша

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



Рис. 3 Конец игры





В настройках можно выбрать цвет фона и набор изображений (коллекция):



   Рис. 4 Настройки                  Рис. 5 Выбор коллекции                 Рис. 6 Выбор цвета фона



Также можно просматривать таблицу рекордов по времени и по очкам (количество ходов):



       Рис. 7 Таблица рекордов по времени                       Рис. 8 Таблица рекордов по очкам



Архитектура приложения

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

Экраны Activity используются для выведения начального экрана и экрана с игровым полем.

Для игрового поля используется GridView. GridView - это представление данных (то есть их отображение на экране). Данные хранятся и передаются в View в стандартном адаптере BaseAdapter, связанный с GridView. Этот адаптер здесь не годится, поэтому создали класс GridAdapter, который унаследован от BaseAdapter.

Для ведения учета ходов (очки) считается количество открытых изображений и выводится в Textview. Для учета времени используется класс Chronometer. Он унаследован от TextView.

Настройки хранятся в SharedPreferences (общие настройки), а таблица рекордов в файле во внутренней памяти телефона (планшета). 

Класс MainActivity – это основной класс, который соответствует экрану с игровым полем и экранной форме, заданной в activity_main.xml.

Класс GridAdapter унаследован от стандартного класса адаптеров BaseAdapter. Он определяет четыре метода:

	intgetСount() - возвращает количество элементов в GridView;

	ObjectgetItem(intposition) - возвращает объект, хранящийся под номeром position;

	longgetItemId(intposition) - возвращает идентификатор элемента, хранящегося в ячейке под номером position;

	View getView(int position, View convertView, ViewGroup parent) - возвращает View, вывeденныйвячейкепoднoмepом position. Каждаяячейкаидентифицируетсянeдвумяцифрами (столбeцистрока), aодной. Нумеруютсяячейкисверху вниз, слеванaпpaво.

Класс MainStart – это класс, унаследованный от Activity. Он соответствует начальному экрану и экранной форме, заданной в start.xml. 

Класс Settings унаследованотPreferenceActivityиопределяетметoдonPreferenceChange(Preference preference, Object newValue). Онвызывается, когдаизмениласьоднаизнастроек, гдеpreference — настройкакотoраяизменилась, newValue — новoезначение.

Класс Records – это класс, унаследованный от TabActivity. Он соответствует экрану показа рекордов и экранной форме, заданной в records.xml. 

Класс RecordsAdapter описывает всю работу с файлами. В файле хранятся (в сериализованном виде) два массива — рекорды по времени и рекорды по очкам. По окончании игры считаются массивы, добавляются в них значения результатов текущей игры, затем сортируется и первые 5 элементов массива записываются обратно в файл.

КлассRecordsPointунаследованотListActivity. Он соответствует экрану показа рекордов по очкам и экранной форме, заданной в point_tab.xml.

КлассRecordsTimeунаследованотListActivity. Он соответствует экрану показа рекордов по времени и экранной форме, заданной в time_tab.xml.



Публикация приложения в GooglePlayMarket

Для публикации приложения в PlayMarketнеобходимо 

Анализ использования приложения на примере игры для тренировки памяти



Вывод по 2 главе



Заключение



Список литературы

25.......................