Створення iOS додатки. Уникайте танців на граблях

Я хочу не просто розповісти історію, як ми створювали мобільний додаток, але й поділитися досвідом, щоб ви не повторювали наших помилок, дати рекомендації стартаперам, авторам та всім зацікавленим у розробці iOS додатків особам.



Ідея


Окрилені успіхами простого додатка Yo і сімейством його послідовників, ми з радою ініціативних колег розмірковували на тему, що можна зробити такого ж простого і цікавого. З урахуванням того, що мода на ввічливість і увагу до близьким людям не пройшла, і ми продовжуємо писати «Добрий ранок» в листах, виставляти статуси в соц. мережі, писати sms з побажаннями, зародилася ідея нашого мобільного додатку.

З чого починається ранок? З людей. Саме так я починаю будь свій день

Функціональність

Накидавши список, що має вміти додаток, зробивши перший начерк екранів, ми зійшлися на тому, що цього цілком вистачить для початку, але все змінюється, коли приходить вони… детальна проробка концепції і розробка продукту. Початковий задум виглядав так:



1) Авторизація через соц мережі: Facebook, Twitter, Vk, OK та інші;
2) Відправлення повідомлення, шляхом натискання на ім'я одного або групи, результат – користувач або учасник групи відразу отримає push-повідомлення «добрий ранок»;
3) Чорний список користувачів;
4) Шарінг через соц. мережі.

Дизайн

При створенні інтерфейсу, ми намагалися дотримуватися рекомендації iOS Human Interface Guidelines. Стояло завдання зробити інтерфейс як можна більш дружнім і зрозумілим для користувачів, тому перебрали безліч колірних схем, шрифтів і іконок. Оскільки в нашій практиці не раз стикалися з тим, що в інтерфейсах при взаємодії з користувачем не опрацьовані області для тапа, ми вирішили приділити особливу увагу цьому питанню.

Що б зробити продукт краще, а роботу користувача з них — простою і зрозумілою, ми кілька разів збирали фокус — групи. Отримані відгуки, допомогли зрозуміти, що ще варто поліпшити, а що зовсім переробити або прибрати. Рекомендація — не нехтуйте залученням фокус-груп.

Колірна гамма всього додатки підбиралася безліч разів, і коли думки команди і фокус-груп по кавовій версії і версії з соковитим помаранчевим кольором розділилися, вирішили дати користувачеві самому зробити вибір і впровадили налаштування теми.



Ми вибирали між 40 варіантами іконок, підсумкову версію вибрав відділ маркетингу за такими параметрами: простота, зрозумілість, яскравість, контрастність.

Розробка

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

Загальне
В якості мови для розробки, було вирішено використовувати Objective-C. Для управління залежностями підключаються бібліотек, ми використовували CocoaPods. Core Data — використовувалася для локального зберігання даних, це дозволяло проглядати вже отримані записи і зменшити кількість споживаного трафіку. Для реалізації бічного меню, використовувався фреймворк MMDrawerController. Він здався нам досить зручним і з ним не виникло проблем в процесі розробки.

Щоб мати можливість проаналізувати дії користувача в додатку, ми використовували Google Analytics. Для спрощення процесу тестування і налагодження ми рекомендуємо Jenkins CI (для забезпечення безперервної інтеграції) і Crashlytics (для збору crash-логів), розібратися з роботою сервісів зовсім не складно.

Вибір рішення для серверної частини
Як backend для програми, був обраний Parse. Він дозволяє використовувати базу в 20Gb і 30 запитів в секунду, а також 1 млн. унікальних одержувачів безкоштовно, це рішення нам ідеально підійшло для випуску MVP. При роботі з push-повідомленнями потрібно розуміти, що, на жаль, немає жодної гарантії доставки такого повідомлення користувачу. Так само перед заливкою в маркет, потрібно не забувати додати релізний сертифікат в parse (звичайно, якщо ви не зробили це раніше).

Пошук рішення для авторизації користувачів
При виборі способу авторизації, нам потрібно було враховувати можливість простого отримання номера телефону користувача. Тому передбачувана спочатку авторизація через соціальні мережі або логін/пароль нас не влаштовувала. Було вирішено зробити авторизацію за допомогою sms-коду, це вирішувало всі наші проблеми і запити. В якості сервісу для розсилки смс-повідомлення з кодом, нами був обраний smsc.ru сервіс сподобався, як простим і зрозумілим api, так і прийнятними розцінками, в порівнянні з якістю послуг.

У нашому додатку, користувач має 2-е спроби авторизації в день, щоб не витрачалися марно кошти компанії. Що б забезпечити роботу цієї умови, необхідно було вирішити проблему перекладу дати на самому пристрої. Для це ми вирішили використати час з інтернету. Оскільки знайти готове осудна рішення у нас не вийшло, ми реалізували свій NTP-клієнт і як сервер синхронізації часу використовували ntp.org.

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

В якості тимчасового рішення, ми додали в профіль користувача зіставлення імені користувача в додатку, з ім'ям, як він записаний в телефонній книзі.

І все одно така реалізація не зовсім зручна, користувачам потрібно зробити додаткові рухи, щоб подивитися, хто з 5 Іванов в списку надіслав «Добрий ранок». Думаємо, як можна вирішити цю проблему, будемо вдячні за ваші пропозиції і рекомендації.

У нашій реалізації інтерфейсу і логіці авторизації, ми не вважали за необхідне додавати в поле вводу номера плейсхолдер з прикладом. Це призвело до питань користувачів у якому форматі вводити номер, починаючи з 8 або +7, або зовсім не зазначати код країни. Наступивши на ці граблі, надалі будемо приділяти увагу цьому, щоб спростити процес взаємодії користувача і додатки.

Чорний список
Важливо для додатків, які передбачають отримання повідомлень/повідомлень від інших користувачів передбачити захист від настирливих повідомлень або спаму. Тут фантазії є де розгулятися, а чи потрібно зберігати повідомлення від користувачів з чорного списку, показувати їх в статистиці, а можна такому користувачу відправляти повідомлення і так далі. Розробляючи подібні програми не забудьте опрацювати всі ці сценарії.

Шарінг
Для шарінга програми в соціальних мережах, ми вирішили використати стандартний компонент UIActivityViewController і UIActivityItemProvider. Це дозволило впровадити функціональність за мінімальний час. Компонент легко налаштовується, це допомогло нам використовувати різний текст для різних соц.мереж.

При реалізації шарінга, ми зіткнулися з проблемою отримання посилання на програму в маркеті без перезаливки. Для вирішення цієї проблеми ми використовували сервер, який повертав нам посилання на наш додатку.

Також ми зіткнулися з особливостями роботи FB, за правилами якого програма не може предзаполнять поля для шарінга, користувач повинен зробити це сам.

Цікаві моменти
В процесі тестування, був помічений цікавий момент. У випадку, якщо пристрій підключено до Wi-Fi, але без доступу в інтернет, всі компоненти, які взаємодіють з мережею будуть нескінченно намагатися отримати дані, при цьому, запити не перервуться по таймауту з'єднання. При такому розкладі всі додатки в системі будуть вічно чекати завантаження даних.
Також зверніть увагу на авто заміну першої малої літери на заголовну при введенні даних в поля. (Ім'я, Прізвище, Група)

Висновок

У процесі розробки програми, ми отримали досвід, це була репетиція танцю і більшою мірою танцю на граблях. Тепер, маючи цей досвід, ми плануємо створення такого ж програми під Android. Хотілося б побажати розробникам вчитися не тільки на своїх помилках, але і на чужих. Будемо раді будь-яким ваших зауважень та пропозицій.Спасибі!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.