Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Аналіз інструментів та технологій для розробки мобільного додатку перелік та огляд основних інструментів для розробки мобільного додатку

Скачати 351.45 Kb.

Аналіз інструментів та технологій для розробки мобільного додатку перелік та огляд основних інструментів для розробки мобільного додатку




Скачати 351.45 Kb.
Дата конвертації16.03.2017
Розмір351.45 Kb.

группа 48


2. АНАЛІЗ ІНСТРУМЕНТІВ ТА ТЕХНОЛОГІЙ ДЛЯ РОЗРОБКИ МОБІЛЬНОГО ДОДАТКУ
2.1. Перелік та огляд основних інструментів для розробки мобільного додатку

Apple забезпечує нас всіма інструментами , необхідними для створення додатків. Цей набір інструментів відомий як Xcode і доступний безкоштовно в Mac App Store . Також ви можете завантажити його з розділу розробників на веб- сайті Apple.

Xcode - інтегроване середовище розробки програмного забезпечення під OS X і iOS , розроблена корпорацією Apple. Перша версія випущена в 2001 році, остання стабільна версія - 5.0.

Xcode - це інструмент з безліччю властивостей , що включає в себе середовище розробки , набір компіляторів , а також додаток для створення графічних інтерфейсів - Interface Builder .

Пакет Xcode включає в себе змінену версію вільного набору і підтримує мови C , C + + , Objective - C , Objective - C + + , Java , AppleScript , Python і Ruby з різними моделями програмування , включаючи (але не обмежуючись ) Cocoa , Carbon і Java. Сторонніми розробниками реалізована підтримка GNU Pascal , Free Pascal , Ada , C # , Perl , Haskell і D. Пакет Xcode використовує GDB в якості back - end'а для свого відладчика .
Елементи вікна Xcode

Панель інструментів (англ. « toolbar » ) - сама верхня частина вікна , де розташовані всілякі налаштування . Також там зазначено назву нашої програми , її стан (наприклад « компілюється » ) і кількість помилок ( якщо вони взагалі є).

Панель навігації. Ця панель, яка знаходиться зліва, вікна спочатку показує список файлів відкритої програми , але завдяки перемикачу (угорі панелі) тут також можна переглянути структуру нашої програми , здійснити пошук по ній , поглянути мережу чи помилки , відкрити дебаггер , знайти точки зупинки і т. д.

Редактор коду. Це саме серце Ікс -код , саме тут проходить процес написання програм.

Інспектор - верхня права панель. Там можна подивитися і змінити властивості поточного файлу і самого коду.

Дебагер . Ця необхідна частина будь-якого середовища програмування знаходиться у нижній частині вікна , видає результат програми і показує значення змінних .

Бібліотека . Саме там ми беремо такі корисні речі для нашої програми як кнопки , лейбли , слайдери , форми і т. д.

Розробникам так само доступний симулятор iPhone . Симулятор відкривається після натискання кнопки Build & Run у верхньому меню головного вікна .

У симуляторі правда, не можливо працювати з деякими функціями , наприклад такими як камера , акселерометр , компас , гіроскоп . Симулятор можна повертати в різні боки , струснути , навіть просімулювати дзвінок .
Interface Builder

Процес створення будь-якої програми можна умовно розділити на три етапи : створення інтерфейсу , безпосереднє написання коду та налагодження . Interface Builder (далі просто IB ) - засіб для візуального створення та тестування інтерфейсів , що входить до складу SDK розробника під Mac OS.

Interface Builder спрощує створення користувальницького інтерфейсу ( UI ) . З його допомогою можливо легко , без написання коду , створити шари з вікон , різні кнопки , повзунки та інші елементи управління.

Рис.5. Схема шаблону Model-View-Controller


Потім у вас є можливість перетворити цей прототип UI в реальний додаток , додавши нові можливості. Xcode працює з Interface Builder в режимі реального часу , так що ви бачите в графічному інтерфейсі ( Interface Builder ) те, що ви пишете в Xcode .

Ви маєте можливість легко створювати користувацькі інтерфейси , оскільки Cocoa був побудований з використанням шаблону Model -View - Controller (рис. 4 ) . Насправді , UI фактично є архівами об'єктів Cocoa , які не вимагають генерації коду. Зміни в інтерфейсі користувача ( UI ) не вимагають перекомпіляції коду , а зміни в коді , не вимагають перекомпіляції UI .

Cocoa Touch

Cocoa Touch framework - і , які управляють IOS додатками мають багато перевірених закономірностей , виявлених на Mac , але були побудовані і оптимізовані з особливою увагою до сенсорних інтерфейсів. UIKit забезпечує базові засоби , необхідні для реалізації графічних , керованих подіями додатків в IOS. UIKit спирається на ті ж Foundation framework - і, що і Mac OS X , в тому числі файлові заголовки , мережеві можливості , рядкові класи , і багато іншого.

Унікальний інтерфейс IOS означає , що Cocoa Touch має унікальний дизайн . Використання UIKit надає доступ до спеціальних графічних інтерфейсів управління , кнопок і повноекранних зображень на IOS. Ви також можете контролювати додатки з акселерометром і жестами на сенсорному екрані.

Велика частина Cocoa Touch реалізована в Objective - C , об'єктно -орієнтованої мови , який компілюється для запуску з неймовірною швидкістю , а використання дійсно динамічного виконання робить його унікально гнучким. Оскільки Objective - C є підмножиною С, то легко змішувати C і навіть C + + в додатках Cocoa .

Як працює додаток? Середа виконання Objective - C створює об'єкти , засновані на виконанні логіки , а не тільки способами певними під час компіляції. Наприклад , працююче Objective - C , додаток може завантажити інтерфейс ( nib файл , створений в Interface Builder ) , підключити Cocoa об'єкти в інтерфейсі до коду програми, а потім запустити потрібний метод одим натисканням кнопки на екрані. Немає необхідності повторної компіляції .

На наступному малюнку висвітлюються різні шари в Cocoa Touch Framework і деякі з ключових технологій і рамок , які включені в кожній з них:



Рис.6. Схема шарів в Cocoa Touch Framework
Повний асортимент Framework – ів.

На додаток до UIKit , колекція Cocoa Touch framework - ів включає в себе все необхідне для створення світового класу IOS додатків , від 3D - графіки до професійного аудіо , роботи в мережі , і навіть спеціальні API , пристрої доступу для управління камерою , або отримання місця розташування з GPS. Cocoa Touch включає в себе потужні Objective - C framework - і , які виконують всі завдання лише кількома рядками коду , забезпечуючи при цьому основоположні C мовної - API , щоб дати прямий доступ до системи , коли це необхідно. Прикладами таких структур є:

Core Animation

Використовується Core Animation для створення багатьох користувальницьких інтерфейсів з легкої моделлю програмування на основі композиції незалежних верств графіки.

Core Audio

Core Audio є професійною технологією для відтворення , обробки і запису звуку , що дозволяє легко додавати потужні звукові функції до додатка.

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

ICloud


У першу чергу це, звичайно, можливості, вбудовані в IOS SDK, об'єднані під загальною брендом ICloud: ICloud зберігання документів, ICloud ключ-значення магазин і ICloud основних даних.

Синхронізація основних даних працює поверх тією ж технологією, що і синхронізація документів. Додаток отримує доступ до спеціальної директорії, окремої від пісочниці додатку, куди вiн може зберігати дані. Ця директорія синхронізується з ICloud операційною системою, а фреймворк основних даних здійснює запис локальних змін в ICloud і злиття змін, отриманих з ICloud, з локальною базою даних.

Для синхронізації через ICloud основних даних рекомендується використовувати тип бази даних SQLite, так як це дозволяє мінімізувати пересилання даних по мережі за рахунок відправки інкрементальних змін. При цьому на кожному пристрої зберігається власний екземпляр бази даних, а через ICloud пересилається тільки журнал змін.

При роботі з ICloud необхідно пам'ятати про низку можливих нестандартних ситуацій та передбачити в додатку відповідну реакцію на них: ICloud може бути недоступним у момент запуску програми або в принципі, користувач може переключитися на інший обліковий запис ICloud, при одночасній роботі з різних пристроїв можуть виникати конфліктуючі зміни. При налагодженні необхідно стежити за об'ємом пересилаються даних і при необхідності внести в логіку роботи програми відповідні виправлення. Крім того, накладається обмеження на використання деяких можливостей основних даних: міграції за допомогою Mapping Model і впорядковані відносини. Більш докладно ці особливості описані в розділі документації Testing and Debugging Your iCloud App.

Objective - C

Objective - C , відомий також як Objective C , ObjC або Obj -C - компільована об'єктно- орієнтована мова програмування корпорації Apple , побудована на основі мови Сі та парадигм Smalltalk . На відміну від C + + , мова Objective - C повністю сумісна з Сі ( мова Objective - C є надбезліччю мови Сі ) і код на Сі компілюється . Об'єктна модель побудована в стилі Smalltalk , тобто об'єктам надсилаються повідомлення . Компілятор Objective - C входить в GCC і доступний на більшості основних платформ. Мова використовується в першу чергу для Mac OS X ( Cocoa ) і GNUstep - двох реалізацій об'єктно- орієнтованого інтерфейсу OpenStep .

ObjC був створений Бредом Коксом на початку 1980х в його компанії Stepstone .

Ще однією з особливостей мови є те , що вона message - oriented в той час як C + + - function - oriented . Це означає , що в ньому виклики методу інтерпретуються не як виклик функції (хоча до цього зазвичай все зводиться ) , а саме як посилка повідомлення ( з ім'ям і аргументами ) об'єкту , подібно до того , як це відбувається в Smalltalk -е. Такий підхід дає цілий ряд плюсів – так, будь-якому об'єкту можна послати будь-яке повідомлення . Об'єкт може замість обробки повідомлення просто переслати його іншому об'єкту для обробки ( так зване делегування) , зокрема саме так можна легко реалізувати розподілені об'єкти ( тобто об'єкти , що знаходяться в різних адресних просторах і навіть на різних комп'ютерах) . Прив'язка повідомлення до відповідної функції відбувається безпосередньо на етапі виконання .

У мові є нормальна підтримка протоколів (тобто поняття інтерфейсу об'єкта та протоколу чітко розділені) . Для об'єктів підтримується спадкування (Не множинне ) , для протоколів підтримується множинне спадкування . Об'єкт може бути успадкований від іншого об'єкта і підтримувати відразу декілька протоколів .

Протоколи в Objective - C описують методи , які повинні реалізувати класи приймаючі ці протоколи . Методи описані в протоколі не мають власної реалізації , вони реалізуються в приймаючому протокол класі. В інших мовах програмування протоколи відомі як абстрактні класи та інтерфейси.

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

Структура іменування файлів: файли з розширенням - h є заголовками з описом класів , функцій також як в С і С + + , файли з розширенням - m відповідно містять реалізацію класів і методів.


Swift.

Swift - це нова мова програмування для розробки iOS і OS X додатків, який поєднує в собі все краще від C і Objective-C, але позбавлений обмежень, накладених на догоду сумісності з C. У Swift використовуються патерни безпечного програмування і додані сучасні функції, що перетворюють створення додатка в простій, більш гнучкий і захоплюючий процес.

Основою нової мови програмування послужили існуючі компілятор, відладчик і фреймворки. Спрощений процес управління пам'яттю за допомогою механізму автоматичного підрахунку посилань - Automatic Reference Counting (ARC). Фреймворки також зазнали серйозної модернізації. Objective-C почав підтримувати блоки, літерали і модулі - все це створило сприятливі умови для впровадження сучасних технологій. Саме ця підготовча робота послужила фундаментом для нової мови програмування, який буде застосовуватися для розробки майбутніх програмних продуктів для Apple.

Розробникам Objective-C Swift здасться знайомим. Він поєднує в собі читабельність іменованих параметрів і міць динамічної об'єктної моделі Objective-C. Він відкриває доступ до вже існуючих фреймворков Cocoa і сумісний з кодом, написаним на Objective-C. Побудований на цій загальній основі мова пропонує безліч нових можливостей і уніфікує процедурні та об'єктно-орієнтовані аспекти мови програмування.

Swift підтримує так звані playground-и, які дозволяють програмістам експериментувати з кодом, бачачи результат в режимі реального часу без необхідності компілювати й запускати додаток.

Swift увібрав в себе все найкраще від сучасних мов і розроблений з урахуванням великого досвіду компанії Apple. Компілятор - синонім продуктивності, мова оптимізована для розробки без оглядки на компроміси. Він спроектований таким чином, щоб программісти змогли легко розробити і перший додаток «hello, world!», І навіть цілу операційну систему. Все це робить Swift важливим інструментом для розробників і для самої компанії Apple.




2.2. Огляд та аналіз шаблонів проектування

Шаблон проектування або патерн в розробці програмного забезпечення - повторювана архітектурна конструкція, що представляє собою рішення проблеми проектування в рамках деякого часто виникає контексту.

Зазвичай шаблон не є закінченим зразком, який може бути прямо перетворений в код; це лише приклад вирішення задачі, який можна використовувати в різних ситуаціях. Об'єктно-орієнтовані шаблони показують відносини і взаємодії між класами або об'єктами, без визначення того, які кінцеві класи чи об'єкти додатка будуть використовуватися.

«Низькорівневі» шаблони, що враховують специфіку конкретної мови програмування, називаються ідіомами. Це гарні рішення проектування, характерні для конкретної мови або програмної платформи, і тому не універсальні.

На найвищому рівні існують архітектурні шаблони, вони охоплюють собою архітектуру всієї програмної системи.

Існують декілька типів патернів проектування, кожен з яких призначений для вирішення свого кола завдань:

- породжуючи патерни, призначені для створення нових об'єктів в системі.

- структурні патерни, які вирішують завдання компонування системи на основі класів і об'єктів.

- патерни поведінки, призначені для розподілу обов'язків між об'єктами в системі.

Model - view - controller ( MVC , « модель -представлення - поведінка», « модель - подання-контролер » , « модель - вид -контролер » ) - схема використання декількох шаблонів проектування , за допомогою яких модель даних програми , користувальницький інтерфейс і взаємодія з користувачем розділені на три окремих компонента. Таким чином , щоб модифікація одного з компонентів надавала мінімальний вплив на інші. Дана схема проектування часто використовується для побудови архітектурного каркаса , коли переходять від теорії до реалізації в конкретній предметній області.

Спрощено ми можемо уявити взаємодію елементів MVC як дані ( Model ) , які ми відображаємо в нашому інтерфейсі (View ) за допомогою контролера ( Controller ) .

Таким чином ми поділяємо всю нашу програму на три « табору» :

• Model - що представляє із себе додаток , але не як воно відображається.

• Controller - як додаток відображається. Так , наприклад , якщо створюється універсальний додаток для iPhone / iPad , буде одна модель , але різні контролери .

• View - в загальному сенсі багато разів використовуваний інтерфейс - те, що контролер використовує для виконання своїх завдань.

Програмна ієрархія MVC

Щоб було легше зрозуміти , розберемо кожний об'єкт:

Модель ( Model ) - Вміщає всі логічні і основні дані . Це : змінні , підключення до зовнішніх RSS - каналах або зображення , докладні функції і числову інформацію. Цей шар повністю відділяється від візуального оформлення , так що можна легко змінити вид дисплея , і все одно залишаться ті ж дані .

Вид (View) - екран або стиль відображення програми . Список таблиць , профіль сторінки , статті , аудіо-плеєр , відео плеєр - всі ці приклади екранів. Можна змінити стиль і видаляти елементи , але ми будемо працювати з тими ж даними в моделі.

Контролер ( Controller ) - виступає в якості посередника між ними. Ми підключили об'єкти виду в ViewController , який передає інформацію моделі . Так що користувач може натиснути на кнопку , і зареєструватися в моделі. Потім виконати вихід з системи , і через той же контролер передати повідомлення « ви успішно вийшли з системи! »



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




Рис.7. Програмна ієрархія MVC

Існує три способи, для взаємодії, спрямованої від View до контролера.

Перший називається Цільова Дія. У контролері ми визначаємо мету (Target), наприклад, натискання кнопки. І коли ця подія відбувається View відправляє дію (Action) нашої мети (Target):
Другий спосіб називається делегування (Delegate). Він використовується коли нам необхідно синхронізувати дані View з нашим Controller. Багато View мають інстанси-змінну, яка називається делегат, і контролер відправляє повідомлення View про те, що він буде його представником (Delegate). Як правило в даному випадку View отримує інформацію про трьох станах: повинен зробити, зробив, зроблю.

View ніколи не зберігають відображенi ними дані. І для цього є кілька причин:

- Швидкість роботи - екран, особливо екран iPhone, обмежений за розміром і відображає незначну частину інформації.

- Вид є простим (незалежним від конкретної реалізації), контролер його створює, використовує і, як тільки він стає непотрібний, знищує (звільняє з пам'яті). Якби вид зберігав всі дані, довелося б зберігати їх при знищенні об'єкта, а при необхідності відновлювати і їх з пам'яті.
Третій спосіб називається Data Source, він схожий на попередній. Як зрозуміло з назви, таким чином View отримує дані у контролера, який в свою чергу бере їх у моделі. Самостійно контролер також не зберігає дані. Цей спосіб використовується, наприклад у Контактах на айфоне, коли View відображає інформацію про загальну кількість записів або хоче отримати дані з певної комірки таблиці.
Створення інтерфейсу за допомогою Interface Builder зазвичай включає в себе: створення nib файлу , який являє собою не просто сховище інтерфейсу програми , а й зберігає зв'язки між об'єктами .
2.3. Методи поширення додатків

App Store - магазин додатків , розділ онлайн- супермаркету iTunes Store , що містить різні додатки для мобільних телефонів iPhone , плеєрів iPod Touch і планшетів iPad , а також для персональних комп'ютерів iTunes і дозволяв їх купити, або скачати безкоштовно.

App Store пропонує більш 900 тис. додатків для iPhone і iPod Touch , близько 375 тис. для iPad ( на 12 червня 2013), число завантажень перевищило 50 мільярдів , а база користувачів складає близько 575 мільйонів чоловік. У числі додатків безліч категорій , включаючи ігри FreeCell і Sudoku , програми Facebook , MySpace , The New York Times , Pandora , PayPal і Twitter.

Вартість більшості продаються додатків становить від $ 0,99 до $ 9,99 , деякі професійні програми коштують істотно більше. У Росії оплата приймається з кредитних карт , а з грудня 2008 року - і з дебетових . Через App Store також поширюються безкоштовні програми .

Власникам iPhone 3G доступ до магазину додатків був відкритий відразу в момент початку продажів цієї моделі. Володарям апарату попереднього покоління для доступу до магазину потрібне оновлення ПЗ до другої версії. Доступ до App Store також можна отримати за допомогою iTunes починаючи з версії 7.7 .

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

Доходи від продажів додатків розподіляються наступним чином - автори отримують 70 % , Apple забирає 30 %. Для того щоб підтримувати магазин офіційно Apple стверджує , що не має наміру робити гроші на продажах . У розробників також є можливість випускати безкоштовні програми . Цікаво й те , що всі куплені програми можна прописати в iTunes , щоб завантажувати все нові оновлення .

У iPod Touch сервіс App Store працює при підключенні до інтернету через Wi -Fi. Так що користувачі можуть купувати і завантажувати додатки по бездротовій мережі , перебуваючи в будь-якому місці. Додатки доступні або безкоштовно, або мають певну вартість , яка записується на рахунок користувача в iTunes Store . App Store своєчасно сповістить користувача у міру появи оновлень для його додатків. Сервіс App Store доступний в програмі iTunes як для комп'ютерів Mac , так і для PC , де відбувається синхронізація додатків з iPhone або iPod Touch по інтерфейсу USB.

Станом на 2015 рік додатки в магазині App Store представлені в таких категоріях:

Книги

Бізнес

Освіта

Розваги

фінанси

Ігри

Кіоск

Здоров'я та фітнес

Спосіб життя

Медицина

Музика

Навігація

Новини

Фото і відео

Продуктивність

Словники , довідники

Соціальні мережі

Спорт

Подорожі

Утиліти

Погода
Рейтинг додатків

« 4 + »

Не містить неприйнятні матеріали.

« 9 + »

Можуть міститися матеріали насильницького характеру , реалістичні сцени насильства , який не прийнятний для дітей у віці до 9 років.

« 12 + »

Можуть міститися нецензурна лексика , сцени насильства і інші не приятні матеріали не придатні для дітей 12 років.

« 17 + »

Можуть міститися сцени насильства , непристойна лексика , можливо зміст сцен з сексуальним змістом , нецензурної лексики та інше , які , не підходить для дітей віком до 17 років. Кожен раз , коли додаток цього рейтингу пропонується для завантаження , з'являється повідомлення , для перевірки , чи є користувачеві 17 років , з проханням підтвердити покупку.

3. ПРОГРАМНИЙ ПРОДУКТ
3.1. Опис програмного продукту

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

Дизайн мобільного додатку складається із графічного оформлення і скрупульозної проробки логіки навігації. На стадії розробки створюється матриця екранів , де покроково простраіваются окремі екрани - розділи програми. Важливо не тільки зрозуміти структуру та зміст екранів , а й продумати інтуїтивно - зрозумілу , очевидну будь-якому користувачеві логіку переходів між ними.
Стадії проектування (за Верпланку )

Білл Верпланк представляє процес проектування, який складається з чотирьох кроків :

1 . Мотивація (англ. motivation ) : наявність проблеми і блискуче рішення

2 . Задум (англ. meaning ) : які метафори можна застосувати і в якому контексті

3 . Образ (англ. modes ) : створення концептуальної моделі

4 . Схема ( англ. mapping ) : проектування відображення інформації та управління


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

Недоліком такого методу був відрив від контексту фізичного пристрою , тому був придуманий також спосіб « папір - на - екрані» (англ. paper - in - screen ) , який працює з відсканованими начерками інтерфейсу , що демонструються на цільовому пристрої .

Нарешті , більш дорогим , але менш гнучким способом є високоякісне прототипування на цільовому пристрої .

Використання шаблонів

Слідом за Крістофером Александером дизайнери взяли на озброєння метод патернів ( шаблонів ) взаємодії . Співтовариством веб- дизайнерів вироблено безліч шаблонів , які можна класифікувати , наприклад , за потребами користувачів : базова взаємодія , вибір , введення , навігація , пошук , робота з даними , персоналізація , шопінг та інші.

Каркасні моделі

На ранніх стадіях проектування інтерфейсу взаємодію з системою може бути позначено за допомогою каркасних моделей (англ. wireframes ) - чорнових макетів інтерфейсу , що складаються з простих ліній , форм , позначень - без вказівки подробиць. Ознайомлення замовника з чорновим варіантом дизайну допомагає запобігти переробки на більш пізніх стадіях проектування . Моделі можуть бути виконані від руки , за допомогою спеціалізованих програм або за допомогою графічного редактора.

При розробці дизайну обов'язково використовуються гайдлайни.

Гайдлайн в загальному розумінні - це документ, який випускає компанія, і за яким дизайнери і розробники розуміють принцип побудови взаємодії додатки з користувачем. Умовно кажучи, для iOS кнопки треба робити круглими, а для Windows Phone - квадратними. Однак використовуються і внутрішні гайдлайни для розробників. Таким чином результат роботи дизайнера найчастіше складається з макетів, гайдлайн і нарізки графіки.
Макети найкраще подавати «облінкований», наприклад за допомогою ProtoTypr, щоб була зрозуміла логіка переходів. Гайдлайни містять у собі інформацію про відступи, розміри, візуальнi ефекти, механіці анімації та ін. Третя частина результату - нарізка графіки - повинна містити мінімум необхідних графічних ресурсів (піклуємося про вагу додатку), мати версії для різних дозволів екранів.

Після отримання макетів, гайдлайн і нарізки, починається робота розробника. Передається в розробку все те, що придумали, і очікується ранній результат. Це не означає, що робота над архітектурою і інтерфейсом користувача закінчена. Іноді у розробників з'являються цікаві ідеї, які вносять коректи ви в початковий план. Коли розробка закінчена, настає стадія тестування.



Рис.8. Процес розробки мобільного додатку

Мистецтву домашньої бухгалтерії потрібно вчитися окремо і тільки набиваючи власні гулі, в «університетах», на жаль, цьому не навчать. Однак маючи в руках доброго помічника у вигляді додатку «Coin», заздалегідь боятися за те, що щось піде не так, не потрібно.

Додаток складається з трьох ключових розділів: Витрати, Категорії і Статистика.

Перше, що бачить користувач при запуску додатку – це заставку.

За замовчуванням, iOS надає механізм відображення картинки завантаження програми у вигляді вказівки png - файлів під певні дозволи.

Заставка , або splash screen - стандартний графічний файл , що завантажується / показуваний iOS на мобільний пристроях iPhone , iPad , iPod touch в той час поки запускається сам додаток .
Перш, ніж почати вписувати покупки і грошові надходження, слід заповнити розділ «Категорії».

КАТЕГОРІЯ - це систематизація ваших статей витрат і доходів за напрямками. Розподіл особистих фінансів на категорії потрібно для того, щоб впорядкувати рух ваших грошей. Також категорії дозволяють відстежити рух ваших грошей і направити їх у потрібне русло (спланувати). Стаття витрат або доходів - це безпосереднє джерело виникнення витрати або доходу. Наприклад, ви купили палицю ковбаси. Ковбаса в даному випадку буде (Статтею витрати), Категорія -> (Продукти). 

Як визначити категорії

Категорії визначаються таким чином. Протягом певного часу необхідно вести облік своїх витрат і доходів. Тобто, кожен день записувати, куди і скільки ви витратили. Тримайте всі ці дані в одному місці. Бажано на одному аркуші паперу, або в одному файлі. Можна використовувати Excel. Не зберігайте ваші записи на різних клаптиках паперу, в кишенях, сумках, тумбочках і т.д. Інакше ви просто їх втратите. Після того, як ви склали повний перелік ваших статей витрат і доходів, припустимо за місяць, необхідно їх структурувати за загальними ознаками. Наприклад, все що витратили на продукти харчування, ми відносимо до категорії Продукти. Все, що пов'язано з автомобілем (бензин, ремонт, страховка, податки), відносимо до категорії Автомобіль і т.д.


Рис.9. Список категорiй


Рис.10. Додавання категорії

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

Рис.11. Список расходов


Наступним заповнюється поле «Витрати», натиснувши знак «плюс» у правій верхній частині екрана. У діалоговому вікні потрібно послідовно ввести дані в порожні поля: витрата, сума, категорія. Зберегти.

Рис.12. Додавання витрат

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

На цій таблиці відображаються наступні дані:



  • назва витрати

  • сума

  • категорія

  • дата


Рис.13. Заповнена таблиця з расходами


Так само користувач може:

- Відредагувати запис

- Видалити запис

- Подивитися детальну інформацію

Для цього необхідно натиснути на кнопку "Редагувати" у лівому верхньому куті екрану. Після натискання кнопки з правого боку біля кожного запису з'являться "-", при натисканні яких запис буде видалений.

Рис.14. Видалення запису


Формування звітів.

Це дуже важлива частина ведення сімейного бюджету. Додаток дозволяє швидко сформувати потрібні вам звіти для подальшого аналізу. Аналіз вашого бюджету дозволяє розробляти стратегію й виробляти план подальших дій, або вносити коректування в уже існуючий план.

Екран із зображенням діаграми, власне, створює кругову діаграму, грунтуючись на даних, введених користувачем раніше.

"Coin" розрахує скільки грошей було витрачено за категоріями, а також видасть відсоток витраченого від загальних витрат. Можна задати різні інтервали часу, а також дивитися детальну інформацію по конкретним операціям.

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

За піктограмою «Діаграма» йдуть «Категорії», по них можна розсортувати всі свої доходи або витрати, і вибрати конкретну категорію для детального вивчення.



Рис.15. Відображення статистики

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

Рис.16. Бокова панель. Меню



3.2. Алгоритм роботи програмного продукту

Мобільні пристрої загалом і пристрої на базі ОС iOS зокрема є окремим класом пристроїв характеризующимся істотними обмеженнями ресурсів і специфічною моделлю використання. Суть обмеженості ресурсів полягає в тому що мобільний пристрій з причини малого розміру і підвищеними вимогами до економного витрачання батареї не може володіти обчислювальною потужністю, обсягом і швидкістю пам'яті доступним персональним комп'ютерам і ноутбукам . Модель використання даних пристроїв також обумовлена ​​їх мобільністю і , у випадку з iPhone , - основною функцією телефону а не мобільного комп'ютера. Перераховані вище фактори обумовлюють наступні вимоги до ПЗ розробляється для пристроїв на базі ОС iOS :

- Підвищена увага до швидкості інтерфейсу користувача ( UI )

- Використання економічних з точки зору процесорного часу алгоритмів

- Інтерфейс спроектований насамперед з позицій зручності і швидкості використання

- Позбавлення програмного засобу другорядних функцій, задля підвищееня зручності використання основних

Нижче розглянемо яким чином деякі з описаних вимог були реалізовані в додатку Coin. Для ілюстрації правильного підходу до розробки UI і проектування взаємодії опишемо загальну схему та алгоритми які використовуються при заповненні форм для додавання нових подій у додатку , для пояснень же ролі економії ресурсів та забезпечення швидкодії додатка розглянемо проблему оновлення інформації в базі даних, без видимого впливу на користувача інтерфейсу і відчуття користувача від роботи з ним.
1 . Перевірка даних введених користувачем.

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

На щастя інструментарій, який надається компанією Apple для полегшення розробки додатків ( iOS SDK ) якнайкраще підходить для вирішення такого роду завдань.

Ідея патернів виникла 40 років тому у архітектора Крістофера Александера:

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

Програмісти це побачили і сказали:

Хоча Александер мав на увазі патерни, що виникають при проектуванні будинків і міст, але його слова вірні і відносно патернів об'єктно-орієнтованого проектування. Наші рішення виражаються в термінах об'єктів і інтерфейсів, а не стін і дверей, але в обох випадках сенс патерну - запропонувати вирішення певної задачі в конкретному контексті.

Патерн - це зразок рішення деякої проблеми. Рішення, яке можна повторити в іншому проекті. Патерни спрощують розуміння коду. Вони допомагають писати слабо-зв'язаний код (loosely coupled) - такий код, в якому можна легко модифікувати компоненти, або замінити цілий компонент на його аналог, майже не чіпаючи іншу частину проекту.



Модель-Представлення-Контролер (Model-View-Controller або просто MVC) - одна з основ Cocoa і, безсумнівно, найбільш часто використовуваний патерн. Він класифікує об'єкти згідно з їх ролі в додатку і допомагає чистому розділенню коду (що це таке - обговоримо нижче).

Три ролі:

Модель (model) містить дані програми і визначає механізми маніпуляцій над ними. У нашому додатку моделлю буде клас Album.

Представлення (view), іноді говорять «вид» - відповідає за візуальне представлення моделі, а також елементів управління, з якими користувач може взаємодіяти. Як правило, це UIView і його підкласи. У нашому додатку уявлення - це AlbumView.

Контролер (controller) координує всю роботу. Має доступ до даних моделі, відображає їх у виставах, підписується на події та маніпулює даними. Який клас у нас буде контролером? Правильно, ViewController.

Правильна реалізація патерну MVC означає, що у вашому додатку кожен об'єкт потрапляє тільки в одну з цих груп.

Модель повідомляє контролер про будь-які зміни в даних. У свою чергу, контролер оновлює дані в поданнях.

Подання повідомляє контролер про дії користувача. Контролер по необхідності оновлює модель або отримує запитані дані.

У даному випадку перевірка даних здійснюється контролером форми , сама ж форма є видом (View) , тобто компонент відповідає лише за відображення інформації але не її обробку .

Для витонченої і легкомасштабуємиї реалізації з точки зору архітектури валідації даних нами був обраний паттерн «Мета - Дія » ( Target - Action) . Суть такого підходу в тому що кожен об'єкт представляє собою те чи інше поле у формі заповнюється користувачем пов'язаний із згадуваним контролером форми. Даний зв'язок об'єкти форми використовують для оповіщення контролера про відбулися з ними події серед яких нас цікавить зміна введених в поле форми даних . Кожен раз коли рядок тексту в поле змінюється ( користувач друкує наступну букву , стирає попередню, вставляє деякий текст з буфера і т. д.) - контролер форми отримує сповіщення про зміну того чи іншого поля і обробивши поточну інформацію - реагує . Як приклад розглянемо введення адреси електронної пошти. Адреса вважається правильно введенною якщо мае формат @"[A-Z0-9a-z\\._%+-]+@([A-Za-z0-9-]+\\.)+[A-Za-z]{2,4}" Відстежуючи введення адреси пошти користувачем , контролер чекає введення символу , як тільки користувач завершив введення, створюеться об'єкт класу NSPredicate, з правилом @"SELF MATCHES [A-Z0-9a-z\\._%+-]+@([A-Za-z0-9-]+\\.)+[A-Za-z]{2,4} "

Предикат є логічним оператором, який повертає логічне значення (істина чи брехня). Є два типи предикатів; предикати порівняння, і складові предикати:

Предикат порівняння порівнює два вирази за допомогою оператора. Вирази вказуються з лівого боку, а з правого - предикат (з оператором в середині). Предикат порівняння повертає результат виклику оператора з результатами оцінки виразів.

Складовою предикат порівнює результати оцінки двох або більше інших предикатів, або зводить нанівець інший предикат.



Після перевірки предикатом строки, введенної - контролер повідомляє формі що введену адресу можна вважати правильною і об'єкт форми поміщає відповідну іконку біля поля вводу. Таким чином користувач вже в процесі введення данних розуміє що зробив помилку в наборі або що адреса введена правильно і можна переходити до наступного поля . Цей підхід демонструє компроміс між ресурсоемкостью алгоритму роботи і забезпеченням зручності користувача. Альтернативний варіант - перевірка даних після заповнення всіх полів форми і натиснення кнопки «Зберегти» , математично швидше , так як перевірка проводиться всього один раз а не по кожному введеному символу , але з точки зору користувача є менш зручним і дружнім , так як при здійсненні помилки змушує користувача повертатися до вже введених раніше даним , перемикаючись між полями і втрачаючи тим самим час .
2 . Звернемося тепер до частини програми де основна увага була приділена забезпеченню швидкодії інтерфейсу .

Як описувалося раніше програма надає можливість користувачеві переглянути списки витрат та надходжень до бюджету . Архітектура програми розроблялася з урахуванням роботи в умовах великої кількості даних так як додаток буде безкоштовно доступне всім користувачам iPhone у світі. Саме тому було прийнято рішення використовувати для відображення записів шаблон « Ледачої завантаження » ( Lazy Loading ) . Суть даного шаблону проектування в тому що завантажувати в пам'ять пристрою необхідно лише ту інформацію яка потрібна для відображення в даний момент або знадобиться найближчим часом. На прикладі таблиці із запрошеннями - це ті записи які в кожний окремий момент видно на екрані пристрою і 2-3 записи перед і після видимих ​​. Звертаючись до шаблону MVC подгрузка потрібних даних є обов'язком спеціального контролера пов'язаного з одного боку з базою даних для отримання записів і з іншого з самою таблицею отображающей записи для отримання подій про прокрутку вгору або вниз. Реагуючи на дані події контролер завантажує необхідні дані з бази і звільняє пам'ять зайняту не видимими більше на екрані записами . Такий підхід дозволяє реалізувати плавну і чуйну прокрутку таблиці при порівняно економному використанні пам'яті пристрою і є пріоритетним в порівнянні з спробою завантажити всі дані в пам'ять відразу. Саме завдяки використанню такої схеми завантаження в нашому додатку в принципі немає місць де користувач змушений чекати поновлення того чи іншого елемента інтерфейсу .

Окремо варто згадати про рішення дозволяє оновлювати дані в базі додатки скачивая нові з серверу не блокуючи при цьому перегляд даних з цієї ж бази користувачем. Для забезпечення такої схеми роботи було прийнято рішення використовувати багатопоточну архітектуру доступу до бази даних. Головний потік додатку який використовується операційною системою для отрисовки користувальницького інтерфейсу використовується для отримання даних призначених для відображення в списку на екрані. Окремий же потік виділений під завантаження даних з мережі . Так як сама база на ОС iOS є однопоточному , тобто доступ до неї на запис можливий одночасно тільки з одного потоку , алгоритм збереження даних побудований таким чином щоб зберігати як можна частіше якомога менші обсяги даних. Таким чином основний потік блокується досить часто (кожні 3-5 секунд ) але на порівняно невеликі інтервали часу (порядку 10-15 мс). Таке співвідношення було підібрати виходячи з рекомендованої компанією Apple частоти оновлення екрану ( 60 кадрів в секунду) і справляє враження плавною і безперервної роботи інтерфейсу .

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

Стратегія - поведінковий шаблон проектування, призначений для визначення сімейства алгоритмів, інкапсуляції кожного з них і забезпечення їх взаємозамінності. Це дозволяє вибирати алгоритм шляхом визначення відповідного класу. Шаблон Strategy дозволяє змінювати обраний алгоритм незалежно від об'єктів-клієнтів, які його використовують.

Деякі з переваг патерну:

- Дозволяє вибирати алгоритм динамічно

- Виклик всіх алгоритмів одним стандартним чином

- Спрощує процес додавання нових стратегій (алгоритмів)

- Позбавляє від множинного використання перемикачів (if, else)

Мотиви використання:

- Програма повинна забезпечувати різні варіанти алгоритму або поведінки

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

- Необхідно змінювати поведінку об'єктів на стадії виконання

Ми використовуемо стратегію для відображення динамічної заставки переходу від екрану завантаження до інтерфейсу програми.

Алгоритми, що входять до стратегії зберігаються в блоках, які, в свою чергу, знаходяться в словнику.

_strategies = @{

@480 : ^{

NSLog(@"TABLE IMG 45 - %@", [UIImage imageNamed:@"titleTablei45"]);

NSLog(@"TABLE IMG 6 - %@", [UIImage imageNamed:@"titleTablei6"]);

NSLog(@"TABLE IMG 6p - %@", [UIImage imageNamed:@"titleTablei6p"]);

NSLog(@"DETAIL IMG 45 - %@", [UIImage imageNamed:@"titleDetail45"]);

NSLog(@"DETAIL IMG 6 - %@", [UIImage imageNamed:@"titleDetail6"]);

NSLog(@"DETAIL IMG 6p - %@", [UIImage imageNamed:@"titleDetail6p"]);

_titleImage.image = [UIImage imageNamed:@"titleTablei45"];

Anim4View *anim = [[Anim4View alloc] initWithFrame:[UIScreen mainScreen].bounds];

[self.view addSubview:anim];

[anim addAnimationAndRemoveOnCompletion:YES];

NSLog(@"anim iphone 4");

__weak Anim4View *weakRef = anim;

dispatch_after(2, dispatch_get_main_queue(), ^() {

[weakRef addAnimationWithCompletion:^(BOOL finished) {

weakRef.hidden = YES;

[weakRef removeFromSuperview];

}];


});

},

@568 : ^{



NSLog(@"TABLE IMG 45 - %@", [UIImage imageNamed:@"titleTablei45"]);

NSLog(@"TABLE IMG 6 - %@", [UIImage imageNamed:@"titleTablei6"]);

NSLog(@"TABLE IMG 6p - %@", [UIImage imageNamed:@"titleTablei6p"]);

NSLog(@"DETAIL IMG 45 - %@", [UIImage imageNamed:@"titleDetail45"]);

NSLog(@"DETAIL IMG 6 - %@", [UIImage imageNamed:@"titleDetail6"]);

NSLog(@"DETAIL IMG 6p - %@", [UIImage imageNamed:@"titleDetail6p"]);

_titleImage.image = [UIImage imageNamed:@"titleTablei45"];

Anim5View *anim = [[Anim5View alloc] initWithFrame:[UIScreen mainScreen].bounds];

[self.view addSubview:anim];

[anim addAnimationAndRemoveOnCompletion:YES];

NSLog(@"anim iphone 5");

__weak Anim5View *weakRef = anim;

dispatch_after(2, dispatch_get_main_queue(), ^() {

[weakRef addAnimationWithCompletion:^(BOOL finished) {

weakRef.hidden = YES;

[weakRef removeFromSuperview];

}];

});


},

@667 : ^{

NSLog(@"TABLE IMG 45 - %@", [UIImage imageNamed:@"titleTablei45"]);

NSLog(@"TABLE IMG 6 - %@", [UIImage imageNamed:@"titleTablei6"]);

NSLog(@"TABLE IMG 6p - %@", [UIImage imageNamed:@"titleTablei6p"]);

NSLog(@"DETAIL IMG 45 - %@", [UIImage imageNamed:@"titleDetail45"]);

NSLog(@"DETAIL IMG 6 - %@", [UIImage imageNamed:@"titleDetail6"]);

NSLog(@"DETAIL IMG 6p - %@", [UIImage imageNamed:@"titleDetail6p"]);

_titleImage.image = [UIImage imageNamed:@"titleTablei6"];

Anim6View *anim = [[Anim6View alloc] initWithFrame:[UIScreen mainScreen].bounds];

[self.view addSubview:anim];

[anim addAnimationAndRemoveOnCompletion:YES];

NSLog(@"anim iphone 6");

__weak Anim6View *weakRef = anim;

dispatch_after(2, dispatch_get_main_queue(), ^() {

[weakRef addAnimationWithCompletion:^(BOOL finished) {

weakRef.hidden = YES;

[weakRef removeFromSuperview];

}];

});


},

@736 : ^{

NSLog(@"TABLE IMG - %@", [UIImage imageNamed:@"titleTablei45"]);

NSLog(@"TABLE IMG - %@", [UIImage imageNamed:@"titleTablei6"]);

NSLog(@"TABLE IMG - %@", [UIImage imageNamed:@"titleTablei6p"]);

NSLog(@"DETAIL IMG - %@", [UIImage imageNamed:@"titleDetail45"]);

NSLog(@"DETAIL IMG - %@", [UIImage imageNamed:@"titleDetail6"]);

NSLog(@"DETAIL IMG - %@", [UIImage imageNamed:@"titleDetail6p"]);

_titleImage.image = [UIImage imageNamed:@"titleTablei6p"];

Anim6pView *anim = [[Anim6pView alloc] initWithFrame:[UIScreen mainScreen].bounds];

[self.view addSubview:anim];

[anim addAnimationAndRemoveOnCompletion:YES];

NSLog(@"anim iphone 6p");

__weak Anim6pView *weakRef = anim;

dispatch_after(2, dispatch_get_main_queue(), ^() {

[weakRef addAnimationWithCompletion:^(BOOL finished) {

weakRef.hidden = YES;

[weakRef removeFromSuperview];

}];

});


}

};

Алгоритм визиваеться одразу після завантаження шляхом перевірки програмної роздільної здатності:



void (^action)(void) = _strategies[[NSNumber numberWithInt: [UIScreen mainScreen].bounds.size.height]];
3. Алгоритм заповнення комірок у таблиці.

Таблиці є базою для більшості списків вибору на iOS. Пошта, список контактів, останні дзвінки - всі ці додатки використовують можливості класу UITableView. Найчастіше таблиці використовуються разом з UINavigationController, який забезпечує навігацію між таблицею і детальним поданням елемента, але бувають і винятки про які я розповім пізніше. Xcode містить вже готовий шаблон (Navigation-Based Application) в якому є пов'язані контролер навігації і табличне представлення.

Таблиця має три основних складові: саму таблицю, розділи таблиці (або угрупування) і елементи таблиці (окремі рядки в таблиці). Дані в таблиці помещяются в чергу з джерела даних таблиці. Джерело даних - це об'єкт, що дає таблиці інформацію про те, які дані відображати, наприклад, імена файлів, повідомлення електронної пошти і т. Д.

Щоб створити джерело даних в інтерфейсі класу RootViewController треба оголосити змінну і вказати їй тип NSArray. Потім додаємо для цієї змінної властивості і методи доступу.

У методі viewDidLoad ініціалізіруем масив на підставі п'яти об'єктів строкового типу, а панелі навігації даємо ім'я.

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


- (NSInteger) numberOfSectionsInTableView: (UITableView *) tableView

{

    return 1;



}

 

Щоб "сказати" таблиці скільки в ній буде рядків (а їх буде стільки ж, скільки і елементів в джерелі даних) використовується метод numberOfRowsInSection:



 

- (NSInteger) tableView: (UITableView *) tableView numberOfRowsInSection: (NSInteger) section

{

    return [students count];



}

 

Заповнюємо осередки таблиці. Для заповнення використовуємо метод cellForRowAtIndexPath. Він надає нам "indexPath" (тип "NSIndexPath"). За допомогою даного значення ми зможемо з'ясувати поточний номер рядка, щоб заповнити її елементом джерела з таким же індексом. У самому методі cellForRowAtIndexPath вже є код, який відповідає за пошук і створення осередку. Більше того, Xcode вставив коментар в тому місці, де слід змінювати клітинку ("// Configure the cell.") Замінюємо цей коментар на код. Тепер метод cellForRowAtIndexPath виглядає так:



 

- (UITableViewCell *) tableView: (UITableView *) tableView cellForRowAtIndexPath: (NSIndexPath *) indexPath

{

    static NSString * CellIdentifier = @ "Cell";


    // Пошук осередку

    UITableViewCell * cell = [tableView dequeueReusableCellWithIdentifier: CellIdentifier];

    

    // Якщо комірка не знайдено



    if (cell == nil) {

        // Створення осередку

        cell = [[[UITableViewCell alloc] initWithStyle: UITableViewCellStyleDefault

                                       reuseIdentifier: CellIdentifier] autorelease];

    }

    


    cell.textLabel.text = [students objectAtIndex: indexPath.row];

    


    return cell;

}
3.3. Інструкція з використання та покращення програмного



продукту

Щоб встановити будь-який додаток з магазину App Store, навіть безкоштовний, необхідно насамперед зареєструватися в App Store (зареєструвати аккаунт). Після цього ви зможете встановити будь-які додатки для вашого пристрою з офіційного магазину Apple.

 Інструкція по завантаженню додатку з App Store:

1. Відкрийте програму App Store на айфоне.

2. У рядку пошуку введіть "Coin".

3. Натисніть кнопку FREE (або ціну) біля іконки програми.

4. Натисніть кнопку INSTALL (або BUY NOW).

5. Далі введіть дані облікового запису: ім'я (якщо просить) і пароль.

Встановлення програми.

Коли процес буде завершений, додаток можна запускати, натиснув на іконку Coin.

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

З'являться поля для введення наступних даних:

- Сума;

- Назва;


- Вибір категорії.

Після натискання кнопки зберегти у списку об'єктів на головній сторінці з'явиться доданий користувачем об'єкт. Щоб видалити об'єкт, необхідно тривалим натисканням на ньому викликати контекстне меню і підтвердити видалення.

При натисканні на будь-який доданий запис відображається детальна інформація про нього, а так само є можливість по необхідності відредагувати дані (вартість, назву, категорію).

 У лівому верхньому кутку знаходиться кнопка «Меню», яка відкриває бічну панель з додатковими можливостями програми:

- Категорії;

- Статистика.

 Вибравши зі списку пункт меню "категорії", користувач потрапляє на вікно зі списком доданих категорій. У ньому відображається список вже спочатку доданих категорій, а так само є можливicть додати необмежену кількість необхідних користувачу категорій.

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

- Яким кольором позначена категорія;

- Процентне співвідношення витраченої суми до загальної за місяць;

- Вказана витрачена сума на певну категорію.
Подальше поліпшення програми.

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

Грунтуючись на багаторічному особистому досвіді обліку і контролю витрат ми спроектували систему такою як нам би хотілося бачити її в ідеалі. На жаль зробити все і відразу неможливо, особливо враховуючи обмежені людські ресурси і час. Тому нами було прийнято рішення йти шляхом послідовних релізів, поступово нарощуючи функціонал, додаючи нові можливості та вносячи зміни до вже існуючих на підставі відгуків наших користувачів. У попередніх розділах ми вже докладно зупинилися на тому функціоналі який було вирішено включити в першу версію програми. Перший реліз дозволяє вести самостійний облік фінансів, розділяючи їх за категоріями а так само вiн включає просту систему статистики. Розглянемо докладно плани розвитку програми та якi ідеї стоять за ними.
1. Спільний доступ.

Одна з ключових особливостей програми виділяє його на тлі конкурентів і аналогів це можливість вести спільний облік. Управляти витратами коли кошти використовуються у великій родині в рази складніше ніж самостійно. Спільний доступ передбачає можливість одночасного використання певних категорій витрат декількома користувачами. В основі реалізації спільного доступу лежать списки користувачів пов'язані з кожною категорією. Додавши іншого користувача в один зі списків Ви отримуєте загальну категорію витрати в яку можуть додавати всі зі списку. Розмежування прав доступу влаштованої таким чином що видалити саму категорію може тільки людина, яка перша додала іншого користувача, що зменшує ймовірність випадкового видалення загальних категорій. Інтерфейс програми спроектований таким чином що загальні категорії виділяються на тлі Ваших особистих, дозволяючи легко оцінити які статті бюджету використовуються декількома людьми, а які особисто вами.


2. Інтелектуальна статистика.

Проектуючи додаток ми розуміли що не настільки важлива сама статистика витрат, як її аналіз дозволяє ефективно контролювати скільки і на що було витрачено. Тому в наступних версіях планується дати користувачам можливість вибирати довільний період часу для побудови графіків а так само вибирати окремі категорії для включення в звіт. Самі ж звіти (поєднання періоду часу і обраних категорій витрат) можна буде зберігати і порівнювати один з одним, це дозволить відповідати на такі питання як "Як змінюються щотижневі витрати на мобільний зв'язок протягом останнього року".


3. Інтеграція з іншими інструментами.

Дуже важливим при використанні програми ми вважаємо спокій користувачів і їх впевненість в тому що їх дані не будуть скомпрометовані, пошкоджені або загублені. У поточній версії був реалізований захищений обмін даними додатку з серверами. В майбутньому ж ми вважаємо важливим дати користувачам можливість імпорту та експорту своїх даних у цілий ряд відкритих форматів, таких як звичайний текст, CSV і XML і сторонні додатки, наприклад Evernote. Ці можливості додадуть користувачам впевненість у тому що їхні дані можуть бути використані поза нашої системи а так само можуть бути самостійно зроблені резервні копії даних в зручному користувачам форматі.


4. Інтернаціоналізація.

Не дивлячись на те що поточна версія буде запущена з підтримкою лише російської мови, ми плануємо переклад інтерфейсу додатку на декілька найбільш популярних мов. Для цього в додатку з самого початку використовуються файли спеціального формату містять всі строкові значення вимагають перекладу. Даний підхід значно спростить передачу текстів для перекладу третім особам і підключення локалізованих версій до системи. Другим дуже важливим аспектом інтернаціоналізації є без сумніву використання різних валют. Ми плануємо дати користувачам можливість вводити витрати вибираючи будь-яку з доступних валют (більше 200), більше того в рамках одного облікового запису можна буде використовувати кілька валют які будуть крос-конвертуватися при побудові звітів.


Монетизація мобільного додатку.

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

Використовуючи найбільш ефективні схеми монетизації мобільних ресурсів в першу чергу ми добиваємося:

1. Високої прибутковості за рахунок умілих маневрів.

2. Можливості не знижувати зручність користувачів додатку.

3. Легкість впровадження засобів розробки ПЗ.



4. Зниження відтоку користувачів додатку.



Скачати 351.45 Kb.

  • 2.2. Огляд та аналіз шаблонів проектування
  • 2.3. Методи поширення додатків
  • 3. ПРОГРАМНИЙ ПРОДУКТ 3.1. Опис програмного продукту
  • 3.2. Алгоритм роботи програмного продукту
  • Модель (model)
  • Контролер (controller)
  • 3.3. Інструкція з використання та покращення програмного продукту