Разработка клиентской части программной системы обеспечения работы социальной сети организации учебных и развлекательных мероприятий для iOS

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

Введение 4
1. Технологии разработки клиентской части программной системы обеспечения работы социальной сети 7
1.1. Социальная сеть как платформа отражения и организации социальных взаимоотношений 7
1.2. Клиент-серверное взаимодействие в рамках обеспечения работы социальной сети 12
1.3. Виды операционных систем для мобильных устройств 18
1.4. Особенности разработки клиентского приложения для мобильных устройств на платформе iOS 24
1.5. Технологии разработки клиентской части программной системы обеспечения работы существующих социальных сетей 30
2. Проектирование основных модулей клиентского приложения социальной сети 34
2.1. Модуль устойчивого асинхронного соединения с сервером на основе технологии GCD 34
2.2. Модуль кэширования данных мобильного приложения с использованием БД SQLite 36
2.3. Модуль точного и энергоэффективного определения географического положения пользователя с помощью фреймворков CoreLocation и CoreMotion 42
3. Программная реализация клиентского приложения социальной сети для мобильных устройств на платформе iOS с применением технологии GCD 45
3.1. Особенности организации соединения клиентской части программной системы обеспечения работы социальной сети с сервером 45
3.2. Разработка базы данных клиента для мобильных устройств 50
3.3. Геолокация в клиентской части программной системы обеспечения работы социальной сети 54
3.4. Интеграция клиентского приложения с другими социальными сетями 57
4. Тестирование разработанной клиентской части программной системы обеспечения работы социальной сети организации учебных и развлекательных мероприятий 60
4.1. Использование встроенных средств среды Xcode и ОС iOS для тестирования и отладки мобильного приложения 60
4.2. Тестирование клиентской части программного обеспечения работы социальной сети организации учебных и развлекательных мероприятий с привлечением сторонней организации 63
Заключение 67
Список использованной литературы 69
Приложение 1 71
Приложение 2 88
Приложение 3 9

Целью дипломного проекта является разработка клиентской части программной системы обеспечения работы социальной сети организации учебных и развлекательных мероприятий с применением технологии GCD.
Поставленная цель достигается решением следующих задач:
1. Обзор основных существующих технологий разработки клиентской части программной системы обеспечения работы социальной сети;
2. Проектирование основных модулей клиентского приложения социальной сети;
3. Программная реализация клиентского приложения обеспечения работы социальной сети организации учебных и развлекательных мероприятий для мобильных устройств на платформе iOS;
4. Оценивание работоспособности разработанной программной системы на основе проведения тестирования.

В качестве примера можно привести пользователей, которые посещают определенные мероприятия. Для хранения такой информации требуется дополнительная таблица, которая будет хранить факт участие в событии. Так же требуются дополнительные таблицы для хранения приглашений, комментариев, «лайков». Система обмена сообщениями так же требует несколько дополнительных таблиц – с сообщениями, со списками бесед, с участниками каждой беседы. Все медиа-объекты сохраняются в отдельной таблице t_data, а факт «прикрепления» к какому-либо объекту (например, событию, профилю пользователя, сообщению или комментарию) хранится в таблице t_attachments. ER-диаграмма БД мобильного приложения, спроектированная с помощью утилиты MySQL Workbench, приведена на рисунке 2.3.Рисунок 2.3. ER-диаграмма, экспортированная изMySQL Workbench2.3. Модуль точного и энергоэффективного определения географического положения пользователя с помощью фреймворков CoreLocation и CoreMotionОперационная система iOS обладает широким набором фреймворков, с помощью которых можно использовать наборы готовых методов и не тратить время на повторное написание уже реализованных функций. Применимо к геолокации и информации о местоположении устройства следует рассмотреть такой iOS фреймворк, как CoreLocation. Также данные об ориентации устройства в пространстве частично можно получить с помощью фреймфорка CoreMotion. Основная разница между названными платформами заключается лишь в том, что фреймворк CoreLocation предназначен для определения местоположения устройства на поверхности Земли (то есть географических координат – широты и долготы) и удобного отслеживания их изменений, а фреймворк CoreMotion отвечает за более локальные перемещения устройства – такие как повороты (акселерометр), вращение (гироскоп) и изменение ориентации относительно магнитного поля Земли (компас). Кроме того, фреймворк CoreLocation поддерживает перспективную технологию iBeacon, предназначенную для определения местоположения внутри помещений с помощью Bluetooth low energy меток.Полный список данных, которые можно получить с помощью CoreLocation, выглядит следующим образом:высота над уровнем моря;GPS координаты;точность определения;скорость (в м/с);направление (в градусах).Также CoreLocation предоставляет методы для таких распространенных задач как, например, определение расстояния между двумя точками земной поверхности.В общем виде работа с фреймворком сводится к созданию объекта класса CLLocationManager и регистрации объекта, реализующего интерфейс делегата CLLocationManagerDelegate. Затем требуется вызвать методы, с помощью которых приложение получит доступ к системному датчику GPS/Glonass. После успешного получения доступа делегатный объект с помощью специальных методов получает возможность отслеживать все изменения местоположения.Фреймворк CoreMotion также предполагает создание специального объекта класса CMMotionManager, который затем конфигурируется путем установки частоты опроса сенсоров устройства. После этого чтение показаний осуществляется путем обращения к свойствам объекта класса CMMotionManager.Таким образом, говоря о фреймворке CoreLocation как способе реализации геолокации в клиентской части программной системы обеспечения работы социальной сети, следует отметить, что он предназначен именно для определения местоположения устройства на поверхности Земли (то есть географических координат – широты и долготы) и удобного отслеживания их изменений. Кроме того, фреймворк CoreLocation поддерживает технологию iBeacon, представляющую собой API сервиса iOS и позволяющую передачу данных между беспроводными устройства – маяками – и устройствами, поддерживающими Bluetooth LE (спецификацию ядра беспроводной технологии Bluetooth, наиболее существенным достоинством которой является сверхмалое пиковое энергопотребление). Все это позволяет рассматривать CoreLocation в качестве технологии, дающей возможность организации геолокации при разработке клиентских приложений социальных сетей, что приводит к расширению их функциональности. 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ СОЦИАЛЬНОЙ СЕТИ ДЛЯ МОБИЛЬНЫХ УСТРОЙСТВ НА ПЛАТФОРМЕ iOS С ПРИМЕНЕНИЕМ ТЕХНОЛОГИИ GCD3.1. Особенности организации соединения клиентской части программной системы обеспечения работы социальной сети с серверомВ общем случае коммуникация мобильного приложения с сервером состоит из нескольких слоев абстракции. Для того чтобы обеспечить надежную, быструю, безопасную и расширяемую двустороннюю передачу данных, требуется качественно реализовать каждый из них.Изначально интерфейс команд приложения к серверу представляет собой ассоциативный массив вида «ключ»-«значение», в зарезервированном поле «command» которого хранится название команды, а в ассоциативном массиве по полю «data» - ее параметры. Перед отправкой на сервер команда преобразуется в один из широко используемых в сети Интернет формат описания данных – JSON. Средства языка Objective C и его стандартной библиотеки Foundation позволяют произвести такое преобразование с использованием специальных методов объекта NSData. Отрывок кода, осуществляющий преобразование, приведен в листинге 3.1.Листинг 3.1. Преобразование описания команды в данные в формате JSONNSData *jsonData = [NSJSONSerialization dataWithJSONObject:dictionaryoptions:NSJSONWritingPrettyPrinted error:&error];Конец листинга 3.1После успешного преобразования команда приобретает удобночитаемый вид, что облегчает отладку приложения и позволяет находить ошибки в названии и параметрах еще до отправки данных на сервер. Пример команды приведен в листинге 2.Листинг 3.2. JSON-представление команды серверу{ command = "dialog_get_list"; data = { "load_old" = 1; "target_datetime" = ""; };}Конец листинга 3.2Формат JSON является текстовым, что подразумевает некоторую избыточность данных. Для уменьшения размера используется GZip сжатие, основанное на использовании библиотеки zlib, которая так же по умолчанию включена в ОС iOS. Базовый класс NSData расширяется с помощью категории NSData (GZIP), которая и обеспечивает методы для осуществления сжатия. Фрагмент кода, осуществляющий сжатие JSON представления команды приведен в листинге 3.3.Листинг 3.3. Сжатие данных перед отправкой на сервер#ifdef COMPRESSION_ONmessage_data=[message_data gzippedDataWithCompressionLevel:GZIP_COMPRESSION_LEVEL];#endifКонец листинга 3.3Полученные в результате всех операций данные являются компактным и полным представлением команды и могут быть отправлены на сервер путем записи их в открытое сокет соединение. В листинге 3.4 показан процесс окончательного формирования пакета данных для отправки на сервер (в заголовке пакета записывается размер данных, а затем сами данные, используется один из самых часто используемых классов в iOS SDK – NSData/NSMutableData). Листинг 3.4. Формирование окончательного пакета и отправка на серверunsigned int data_size=(unsigned int) [message_data length];NSMutableData *data_to_send= [[NSMutableData alloc] init];[data_to_send appendBytes:&data_size length:sizeof(data_size)];[data_to_send appendData:message_data];for (unsigned int i=0;i<[data_to_send length];i+=max_write_portion) { NSData* data_to_write = [data_to_send subdataWithRange:NSMakeRange(i, ([data_to_send length]-i)<=max_write_portion?[data_to_send length]-i:max_write_portion)]; [asyncSocket writeData:data_to_write withTimeout:-1.0 tag:1];}Конец листинга 3.4Сам процесс записи данных в сокет активно использует технологию GCD, а именно функцию dispatch_async, которая предназначена для асинхроннного, неблокирующего интерфейс приложения выполнения определенных программистом задач. Для работы с сокетами используется библиотека GCDAsyncSocket, главное предназначение которой заключается в обеспечении асинхронного сокет-соединения с сервером и предоставления callback-методов для обработки событий – таких, как получение данных, успешная отправка, ошибки соединения и так далее. Пример метода writeData, показанного в листинге 3.5, демонстрирует использование функции dispatch_async в коде библиотеки.Листинг 3.5. Использование GCD для записи пакета данных в сокет- (void)writeData:(NSData *)data withTimeout:(NSTimeInterval)timeout tag:(long)tag{if ([data length] == 0) return;GCDAsyncWritePacket *packet = [[GCDAsyncWritePacket alloc] initWithData:data timeout:timeout tag:tag];dispatch_async(socketQueue, ^{ @autoreleasepool {if ((flags & kSocketStarted) && !(flags & kForbidReadsWrites)) {[writeQueue addObject:packet];[self maybeDequeueWrite];}}});}Конец листинга 3.5Процесс принятия данных или команды от сервера имеет обратный порядок действий. Так, сначала библиотека GCDAsyncSocket осуществляет вызов так называемого delegate-метода у объекта, отвечающего за обработку полученных данных. Затем требуется проверить тип данных – низкоуровневый ping клиента сервером или сжатое JSON-представление ответа сервера. При успешной идентификации JSON-данных производится их разжатие и последующая десериализация в объект NSDictionary. Полное описание метода - (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag размещено в коде класса AIMSServer, приложение 1.Описанных решений достаточно для того, чтобы обеспечить двустороннюю связь между клиентом и сервером в расширяемом и в тоже время компактном виде, но соединение не будет достаточно безопасным и, в теории, может быть прослушано. Для того, чтобы избежать проблем с безопасностью передачи данных через сокет, требуется корректно настроить библиотеку GCDAsyncSocket для использования SSL/TLS шифрования соединения, а так же проверять сертификат сервера при каждом подключении. Листинг 3.6 демонстрирует код, необходимый для включения SSL.Листинг 3.6. Включение шифрованияNSMutableDictionary *tlsSettings = [[NSMutableDictionary alloc] init]; [tlsSettings setObject:[NSNumber numberWithBool:NO] forKey:(NSString *) kCFStreamSSLIsServer]; [tlsSettings setObject:[NSNumber numberWithBool:YES] forKey:(NSString *) GCDAsyncSocketManuallyEvaluateTrust]; [asyncSocket startTLS:tlsSettings];Конец листинга 3.6Успешное установление SSL-соединения позволяет быть уверенным в том, что данные при передаче не будут расшифрованы и подменены, не позволяет удостовериться в том, что сервер является тем, за кого себя выдает. Для идентификации сервера можно использовать метод проверки сертификата, который приведен в листинге 3.7.Листинг 3.7. Проверка сертификата сервераSecCertificateRef certRef = SecTrustGetCertificateAtIndex(trust, i);NSData* certData = (__bridge NSData*) SecCertificateCopyData(certRef);CFStringRef certSummary = SecCertificateCopySubjectSummary(certRef);if ([certData isEqual:_trustedServerCetificate])certificateIsTrusted = YES;Конец листинга 3.7Для удобного использования в коде мобильного приложения класса, поддерживающего соединение с сервером, имеет смысл вынести его в singleton-класс, т.е. класс, объект которого создается единожды при первом обращении и вызывается при всех последующих. Пример создания singletone-класса приведен в листинге 3.8.Листинг 3.8. Создание singletone+ (AIMSServer *) sharedSServer { @synchronized(sharedSServer) { if (!sharedSServer||sharedSServer==NULL) sharedSServer=[[AIMSServer alloc] init]; } return sharedSServer;}Конец листинга 3.8Далее для выполнения какой-либо команды команду серверу в любой точке кода приложения достаточно вызвать объект этого класса и обратиться к нужному методу. После того, как метод будет полностью исполнен сервером (будет получен ответный JSON-массив с данными), вызвавший метод объект будет уведомлен об этом с помощью вызова метода. Такая реализация взаимодействия с сервером позволяет создать пользовательский интерфейс без задержек, что позволяет пользователю не дожидаться реакции сервера, при, например, нестабильном соединении, а продолжать использование функций приложения. Пример вызова метода приведен в листинге 3.9.Листинг 3.9. Отправка сообщения в диалог [[AIMSServer sharedSServer] postMessage:[AIM_Helpers cleanString:textView.text] withAttachments:attachments forDialogWithID:_dialog_id listener:self tag:dialog_state_sending_message];Конец листинга 3.93.2. Разработка базы данных клиента для мобильных устройствИспользование встраиваемой компактной базы данных в мобильном приложении является эффективным способом для повышения удобства его использования. База данных может обеспечивать кэширование большинства данных, получаемых приложением с сервера, что избавляет от необходимости постоянного подключения для таких задач, как просмотр истории сообщений или списка друзей. ОС iOS содержит встроенную поддержку базы данных SQLite, которая является одной из самых распространенных в мире. Для более эффективной работы с этой базой данных в дипломной работе применяется wrapper-класс FMDB, который скрывает детали C-реализации SQLite, заменяя их на Objective-C методы.Структура базы данных приложения предполагает хранение различных наборов объектов, а именно: списков друзей пользователя, списков его личных сообщений и их контента, списков его планов (мероприятий, которые пользователь решил посетить), новостей пользователя, ответов, комментариев. Для оптимального использования дискового пространства и ограниченных вычислительных возможностей мобильного устройства при проектировании базы данных нужно привести все сущности к нормальным формам, что позволит избежать нерациональное использование ресурсов. Так, всех друзей пользователя можно вынести в отдельную таблицу t_relations, список личных сообщений – в таблицу t_dialogs, данные о самих сообщениях – в таблицу t_messages, о вложениях в сообщения – в таблицу t_attachments. Мероприятия, интересные пользователю, могут быть обособлены в таблице t_events, а его новости – в таблице t_news. При таком проектировании базы данных различные сущности находятся в различных таблицах, и каждая сущность может иметь свой уникальный идентификатор. Так же сущность в одной таблице может иметь связи с сущностями в другой таблице (например, записи в таблице t_attachments могут быть связаны с записью в таблице t_messages). SQL-код запроса, создающего таблицу для хранения сообщений, приведен в листинге 3.10.Листинг 3.10. Запрос на создание таблицыCREATE TABLE t_messages (id INTEGER PRIMARY KEY, sender_id INTEGER NOT NULL, dialog_id INTEGER NOT NULL, message_text TEXT, message_time TEXT, message_type INTEGER NOT NULL, additional_data_id INTEGER NOT NULL);Конец листинга 3.10В процессе реализации функциональности, требуемой заказчиком, база данных приняла вид, приведенный на рисунке 3.1. Расширение обосновано введением большого количества новых функций, которые и привели к необходимости расширения и усложнения изначально запланированной структуры.Рисунок 3.1. Структура базы данныхПри первом запуске приложения файл таблицы должен быть создан в энергонезависимой памяти устройства. Для этого можно скопировать существующую базу данных из т.н. bundle-ресурса приложения. Включение пустой базы данных со всей необходимой структурой непосредственно в файл приложения позволит сократить время установки приложения, так как при этом будет скопирован уже готовый файл. Код, отвечающий за проверку наличия файла базы данных, и выполняющий копирование в случае его отсутствия, приведен в листинге 3.11.Листинг 3.11. Работа с файлом базы данныхNSFileManager *fmngr = [NSFileManager defaultManager]; NSError *error;NSString * localPath =[NSString stringWithFormat:@"%@/Documents/cache.sqlite", NSHomeDirectory()];if (![fmngr fileExistsAtPath:localPath]){ [fmngr copyItemAtPath:[[NSBundle mainBundle] pathForResource:@"cache" ofType:@"sqlite"] toPath:localPath error:&error];}Конец листинга 3.11Для дальнейшей работы с базой данных можно использовать класс FMDB. Код, необходимый для подключения к SQLite базе данных с использованием FMDB, приведен в листинге 3.12.Листинг 3.12. Открытие базы данных в классе FMDBFMDatabase _cacheDB=[FMDatabase databaseWithPath:[[NSBundle mainBundle] pathForResource:@"cache" ofType:@"sqlite"]];[_cacheDB open];Конец листинга 3.12Кэширование данных происходит при получении их с сервера социальной сети. Для записи в базу данных используется метод executeUpdate, что отображено в листинге 3.13.Листинг 3.14. Выполнение запроса INSERT[db executeUpdate:@"INSERT INTO friends (id, name, surname, phone) values(?, ?, ?, ?)", 1, @"Name1", @"Surname1", @(12345), nil];Конец листинга 3.14Для создания отзывчивого пользовательского интерфейса имеет смысл комбинировать возможности FMDB и технологии GCD, то есть производить запросы к базе данных не в главном потоке программы. Это позволит избежать блокировки интерфейса и предоставит пользователю приложения ощущение мгновенной реакции на его действия. Например, в случае поиска по друзьям, такой подход позволит выводить подходящий список прямо по мере набора имени или фамилии друга. В общем виде асинхронная работа с базой данных заключается в следующем:Создается блок кода, который должен быть выполнен асинхронно;Создается блок кода, который должен быть выполнен в главном потоке после выполнения асинхронной части;С помощью GCD оба блока ставятся в очередь на выполнение.Пример кода, реализующего такое поведение, приведен в листинге 3.15.Листинг 3.15. Асинхронное выполнение запроса SELECT dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0ul); dispatch_async(queue, ^{ FMResultSet * selectResult=[_cacheDB executeQuery:str]; NSMutableArray *results= [[NSMutableArray alloc] init]; while ([selectResult next]){ NSDictionary *dict = [[NSDictionary alloc] initWithObjectsAndKeys:[selectResult stringForColumn:@"id"], @"id",[selectResult stringForColumn:@"name"],@"name", [selectResult stringForColumn:@"surname"],@"surname",nil]; [results addObject:dict];} dispatch_sync(dispatch_get_main_queue(), ^{ [self searchCompletedWithResults:results]; }); });Конец листинга 3.15После окончания любых операций с базой данных соединение с ней необходимо закрыть с помощью метода close.3.3. Геолокация в клиентской части программной системы обеспечения работы социальной сетиИспользование высокоточных геоданных пользователя в мобильном приложении социальной сети организации учебных и развлекательных мероприятий является одной из самых приоритетных задач, так как именно эти данные позволяют сети подбирать и предлагать пользователю самые актуальные и интересные ему места, показывать корректные расстояния до объектов, полноценно использовать дополненную реальность.Для задач, связанных с определением положения устройства ОС iOS предлагает библиотеку CoreLocation, с помощью которой можно получить доступ ко всем датчикам устройства – GPS/Glonass, акселерометру, гироскопу и компасу.Для обработки всех данных геолокации в мобильном приложении был реализован специальный класс AIMDevicePositionManager, который, взаимодействуя с библиотекой CoreLocation, решает несколько задач:Запрос разрешения на определение местоположение и проверка статуса этого разрешения;Непосредственный сбор геолокационных данных;Наблюдение за требованиями приложения к точности геолокации и автоматическое переключение в наименее энергозатратный режим (например, использование максимальной точности при просмотре пользователем карты, и минимальной – при просмотре личных сообщений);Фоновая отправка геолокационных данных на сервер.Для того, чтобы начать получение геолокационных данных, требуется создать объект класса CLLocationManager и установить AIMDevicePositionManager в качестве его delegate-объекта. При обновлении координат устройства фреймворк Corelocation будет автоматически вызывать у такого объекта методы, определенные в протоколе CLLocationManagerDelegate. Создание и настройка точности объекта класса CLLocationManager показано на листинге 3.16.Листинг 3.16.