Home Budget Manager – мобилна апликација за вградливи уреди

Содржина

1 ВОВЕД (INTRODUCTION)

2 КОРИСТЕНИ ТЕХНОЛОГИИ

3 ФУНКЦИОНАЛНОСТИ НА АПЛИКАЦИЈАТА

3.1 ACCOUNTS (ПРОФИЛИ НА КОРИСНИЦИ)

3.2 INCOMES (ПРИХОДИ)

3.3 EXPENSES (ТРОШОЦИ)

3.4 BILLS (СМЕТКИ)

3.5 CATEGORIES (КАТЕГОРИИ)

3.6 TRANSFERS (ТРАНСФЕРИ)

3.7 SUMMARY (РЕЗИМЕ)

3.8 ДОПОЛНИТЕЛНИ СЕКЦИИ (КАЛКУЛАТОР И ПОМОШ)

4 ЗАКЛУЧОК (CONCLUDING REMARKS)

---

1 Вовед (Introduction)

Целта на проектот е да се развие мобилна апликација со која секое семејство ќе може да врши управување на својот домашен буџет, а при развојот да се користи библиотеката jQuery Mobile. Во овој опис накратко ќе бидат опишани користените технологии за развој и како тие се интегрирани меѓусебно за како крајна цел да се добие апликација која корисниците ќе може да ја инсталираат на своите мобилни уреди и да вршат увид во својот буџет.

---

2 Користени технологии

Во согласност со поставеното барање, развојот на апликацијата е во форма на web програмирање. Бидејќи целта е таа да работи на клиентска страна и да не побарува интернет конекција за да ги извршува своите функционалности, комплетниот развојот на истата се темели на HTML скрипти и соодветни JavaScript функции. Користењето на PHP е со намера изоставено, бидејќи истото не може да се интегрира во конверирањето на апликацијата како апликација за мобилни и вградливи уреди. За конверзија на скриптите се користи PhoneGap технологијата http://phonegap.com/ од каде што е искористена готовата алатка за конверзија во мобилна апликација. Притоа целиот процес на конверзија се одвива во неколку чекори. Најпрво целиот проект е прикачен на репозиториум на https://www.github.com. На следниов линк: https://github.com/ivan0071/test е прикажан пристап до проектот од каде што преку секцијата “commits” може да се следи целокупниот развој на апликацијата од самото нејзино прикачување во репозиториумот па се до нејзината крајна верзија (слика 2.4). Со завршување на секоја одредена етапа од развојот, промените се ажурирани во репозиториумот. Потоа со најава во системот на PhoneGap и поврзување со профилот од GitHub (слика 2.1) се влегува во панел од каде што е овозможена конверзија (слика 2.2). Со клик на Update Code  Pull Latest се земаат најновите промени кои се ажурирани во репозиториумот на GitHub и истите конвертираат во фајл погоден за мобилните уреди. Конвертираните апликации на овој начин може да се инсталираат на платформите на Android, Windows Phone и iOS со напомена дека за да може апликациите да се конвертираат во апликации кои ќе функционираат на iOS уреди, потребен е посебен тип на сертефикат за iOS developers издадаен од Apple и поради таа причина, изработената апликација е достапна само во Android и во Windows Phone. Како што може да се согледа и од самата слика (2.3), по кликањето на Pull Latest, се генерираат копчиња преку кои дирекно може да се превземат .apk и .xap форматите за инталација. Процесот на развој се одвива така што со додавање на секоја нова функционалнот, промените се ажурараат во GitHub репозиториумот (локално, преку командниот промпт на GitBash – слика 2.5), потоа преку PhoneGap алатката се конвертираат во .apk формат и потоа таквиот формат се инсталира на таблет Google Nexus 7 со цел да промените истовремено се тестираат и на мобилен уред. Во првиот чекор од слика 2.5 се проверуваат најновите промени во директоримуот во кој се работи. Во вториот чекор тие промени се зачувуваат проследени со опис на истите, и во послениот чекор истите се поставуваат на серверот на GitHub кој што е поврзан со локалната верзија на GitBash командниот прозорец. Базите на податоци, како технологија во која што се зачувани сите податоци неопходни за работата и функционирањето на истите, се неминовен дел за најголемиот број на апликации. Како тип на базa на податоци кој е искорисен во развојот на “Home Budget Manager” е изберена технологијата IndexedDB. Предноста на оваа технологија во однос на WebSQL е тоа што е развојот и користењето на IndexedDB е се поинтензивно, додека WebSQL е технологија во “изумирање”. Од друга страна пак недостатокот е тоа што поддршката за IndexedDB во моментов е многу помала од поддршката на WebSQL од страна на пребарувачите и опертивните системи. Како што може да се согледа и од линковите, најголемиот недостаток на IndexedDB базите функционираат на Android уреди чиј оперативен систем мора да е најмалку 4.4. Во целиот овој развој, како мобилен уред за тестирање е користен уред со Android верзија 4.4.3 па така да тоа ограничување не претставуваше пречка во развојот на апликацијата. IndexedDB претставува не-ралационен тип на база (NoSql), со што се дава можност да секој “ред” од базата, може да има различен број и различен тип на “колони” во зависност од потребите. Преглед во моменталната содржина на базата се добива со: десен клик на страната  Inspect Element  избор на Resources табот  клик на IndexedDB базата од листата на алатки која се наоѓа на левиот дел од прозорецот. Пристапот до елементите, нивното вментнување и ажирурање е многу покомплициран од релационите бази на податоци, бидејќи овде пристапот се врши преку индекси (еден вид на преглед по колони) и изминување на елементите еден по еден (преку курсори) се додека не се добие пристап до посакуваниот елемент. Структурата на фајловите во апликацијата е таква да, интерфејсот на секоја една секција е имплементиран во HTML скрипта и за секоја една HTML скрипта постои соодветна JavaScript скрипта. Во JavaScript скриптите се извршуваат сите функции и пристапи до табелите од базата и во истите се врши земање и потполнување на HTML таговите со соодветните информации. Може да се констатира дека во JavaScript скриптите се наоѓа главниот дел од кодот на апликацијата и во истите се извршува целата логика и функционалности кои ги нуди апликацијата.

---

3 Функционалности на апликацијата

Како и секоја друга апликација на вградливите уреди, така и апликацијата “Home Budget Manager” има свое лого. Логото е прикажано на слика 3.1 а истото е вметнато преку config.xml датотеката. Како што е споменато и претходно, дизајнот на апликацијата е тестиран на desktop компјутер и на таблет. За секое тестирање на функционалностите од почеток, потребно е да се избрише содржината на IndexedDB базата (за да се добие ефект дека апликацијата е штотуку инсталирана на мобилен уред) преку командите во Google Chrome: да се влезе во cookies и да се избрише содржината за localhost, a потоа да се избрише преку History  Clear Browsing Data  и да се избришат секциите: Cookies and other site and plug-in data, Cached images and files и Hosted app data. При стартот на апликацијата, на почетниот екран се достапни секциите за: кориснички профили (Accounts), приходи (Incomes), трошоци (Expenses), трансфери (Transfers), Сметки (Bills), Резиме (Summary) и категории (Categories). Достапни се линкови и за калкулатор (Calculator) и помош (Help). Секоја од овие секции ќе биде накратко разгледана, проследена со екрански слики кои ќе го водат корисникот низ апликацијата. Пред да се премине кон конкретни примери за тоа како да се управува со домашниот буџет, битно е да се напомене дека целата логика на апликацијата е креирана така да при плаќања, приходи и трансакции, НИКОГАШ да не се изгубат пари кои веќе биле внесени во системот (секако, доколку корисникот сам не одлучи да ги изнесе од системот преку плаќања или ажурирања на состојбата) и НИКОГАШ да не се внесат пари без притоа да се води евиденција од каде пристигнале истите. Според самото име на апликацијата “Управување со домашниот буџет”, основен принцип кој важи е: секогаш да се добиваат детални информации и да се врши следење на сите приходи и сите одливи на средства во едно домаќинство.

3.1 Accounts (Профили на корисници)

Во секцијата Accounts (Профили на корисници) при самата инсталација се сетирани три (системски) профили за кои се смета дека се заеднички за целото семејство: Cash on Hand (пари на рака – парите кои семејството ги има во својот дом т.е. не фигурираат на ниту една сметка), Credit Card (пари на кредитна картичка) и Bank Account (пари кои се наоѓаат на сметка во банка). Овие три стартни профили се заеднички за целото семејство и истите не може да бидат избришани од системот. Основната намена на овие профили е да не се дојде во ситуација да бидат избришани сите профили во системот, а притоа семејството да има заостанати долгови или приходи кои треба да пристигнат во иднина (објаснето во секцијата за трансфери) и со тоа да се изгуби следењето на тие идни долгови/приходи. Средствата кои претставуваат приходи секогаш ќе се маркирани во зелена боја, трошоците во црвена, а неутралните средства во сина боја. Листата од профили е подредена по азбучен редослед, со тоа што трите системски профили се секогаш први во листата, а подредувањето важи за оние кои ги внесува корисникот. Сумата која е внесена во новиот профил (слика 3.1.1) може да биде и позитивна или негативна, на пример: членот во семејството веќе од претходно има долгови (пред да се почне со користење на апликацијата). Профилот кој е внесен како пример кажува дека станува збор за кредитна картична на еден од членовите од семејството. Многу битен дел од отварањето на нов профил е датата на активирање на профилот т.е. од кога да почне да фигурира во системот. Доколку е внесена моменталната дата или некоја дата од минатото, тогаш од истиот момент на креирање, профилот е достапен за користење и во другите секции, но ако се внесе некоја дата од иднината (на пример после 3 дена), тогаш профилот ќе стане достапен за користење во другите секции на датата која што е специфицирана како дата за активирање (на пример, 3 дена после внесувањето). Со клик врз конкретен профил се добива пристап до деталите кои биле внесени при креирањето на профилот, можност за промена на истите (Edit This Account) и можност за бришење на профилот од системот (Delete This Account). При промена на трите системски профили не е овозможена промена на нивното име. Постојат дополнителни линкови во интерфејсот за додавање на приход/трошок кон конкретниот профил. Разликата од нормалното додавање е тоа што, кога се додава приход/трошок обично се појавува паѓачка листа од сите активни кориснички профили, а во овој случај се скратува тој избор бидејќи како профил на приходот/трошокот автоматски е додаден конкретниот профил. Повеќе за тоа во секциите во продолжение.

3.2 Incomes (Приходи)

Во секцијата Incomes (Приходи) се чуваат информации за сите приходи кои влегуваат во семејството (плати, награди, дополнителни приливи во буџетот). На почетокот оваа листа е празна, а внесувањето се одвива како што е прикажано на слика 3.2.1.
При внесувањето на нов приход во системот, се внесува сумата (мора да е позитивен број), се избира корисникот (на чија сметка) каде што ќе пристигнуваат парите од приходот и се избира категорија во која спаѓа приходот. На листата со корисници се појавуваат сите кориснички профили кои се актвини во моментот (вклучувајќи ги и трите системски), а во листата со категории се појавуваат сите категории кои се приходи (поопширно за категории е објаснето во секцијата за нив). Тоа се основните податоци кои се внесуваат за приходите. Дополнително, доколку се помести слајдерот Repeat и со тоа се избере опцијата да пристигнуваат повеќе инстанци од приходот, во различни временски рамки, се појавуваат и други полиња кои мора да бидат потполенети при внесувањето во системот. Се избира временскиот период во кој ќе пристигнува секоја од инстанците и датата кога повторувањето завршува. Во примерот од слика 3.2.1 се избира да на профилот “Ivan” пристигнува приход од 100 МКД, пристигнувањето да се повторува секој ден (на секој 24 часа) – почнувајќи од моментот на креирање и тоа да се повторува до крајот на месец Јуни. Со креирањето, како што се гледа и на листата со профили, веднаш се додадени 100 МКД на соодветниот профил. Со отварање на конкретен приход, корисникот има пристап до сите информации кои биле внесени при креирањето (слика 3.2.3). Доколку семејството не ја отвара апликацијата 5 денови по ред, после 5-тиот ден кога ќе ја отвори, на сметката на приходот ќе бидат пристигнати дополнителни 500 МКД. Тестирањето на ваквите случаи е возможно со промена на датата на компјутерот (или уредот на кој се тестира) и одново стартување на апликацијата. Нека ја тестираме за 5 денови после креирањето на приходот. На слика 3.2.4 се дадени листата со кориснички профили, листата со приходи и деталите за приходот после 5 денови.

Разликата е во прегледот на деталите за конкретниот приход кој на новата дата има примано повеќе инстанци од сумата. Кога има повеќе инстаци, изгледот се менува така што сите инстанци се прикажануваат во листа во која што се прикажани времето и датата на креирање за секоја од нив, како и можност за поединечно отстранување од системот. Доколку се избрише поединечна инстанца, тогаш само таа ќе биде отстранета од системот, а доколку се кликне на Delete This Income од горното мени, тогаш ќе се избришат комплетно сите инстанци на пристигнувања за приходот. Кога приход се брише од системот, тогаш сумата која што тој ја донел на избраниот кориснички профил се одзема од истиот. Како што внесувањето на приход додава пари во буџетот, така бришењето на тој приход ја одзема истата таа сума на пари од буџетот. Една од целите на тоа одземање е да не дојде до злоупотреба на буџетот, т.е. да се внесуваат приходи и потоа да се бришат и со тоа да се нема увид од каде дошле. Еден од принципите на апликацијата е да можат да се следат изворите на приходите, па ако се избрише приходот се брише и евиденцијата за тоа дека тој некогаш бил додаден.

3.3 Expenses (Трошоци)

Во секцијата Expenses (Трошоци) се чуваат информации за сите трошоци кои ги прави семејството (купување храна, купување облека, плаќање сметки). На почетокот оваа листа е празна, а внесувањето се одвива како што е прикажано на слика 3.3.1.

При внесувањето на нов трошок во системот, се внесува сумата (мора да е позитивен број), се избира корисникот (од чија сметка) од каде што ќе се одливаат парите за трошокот и се избира категорија во која спаѓа трошокот. На листата за корисници се појавуваат сите кориснички профили кои се актвини во моментот (вклучувајќи ги и трите системски), а во листата со категории се појавуваат сите категории кои се трошоци (поопширно за категории е објаснето во секцијата за нив). Тоа се основните податоци кои се внесуваат за трошоците. Во примерот од слика 3.3.1 се избира да од профилот “Bank Account” се земаат средства од 50 МКД, одливањето на средствата да се повторува секој ден (на секој 24 часа) – почнувајќи од моментот на креирање и тоа да се повторува до крајот на месец Јуни. Со креирањето, како што се гледа и на листата со профили, веднаш се одземени 50 МКД на соодветниот профил, па ако нема доволно средства се оди во минус. Со отварање на конкретен трошок, корисникот има пристап до сите информации кои биле внесени при креирањето (слика 3.3.2). За слајдерот Repeat (слика 3.3.1) важат истите функционалности како и кај приходите и логиката на креирање на трошоците од страна на системот е комплетно иста (во случајов до 30 Јуни, секој ден да се регистрира трошок од 50 МКД на профилот “Bank Account”). Кога трошок се брише од системот, тогаш сумата која што тој ја земал од избраниот кориснички профил се додава од истиот. Како што внесувањето на трошок зема пари од буџетот, така бришењето на тој трошок ја додава истата таа сума на пари во буџетот. Една од целите на тоа додавање е да не дојде до злоупотреба на буџетот, т.е. да се внесуваат трошоци и потоа да се бришат и со тоа да се нема увид каде се потрошиле парите. Еден од принципите на апликацијата е да можат да се следат изворите на трошоците, па ако се избрише трошокот се брише и евиденцијата за тоа дека тој бил некогаш додаден. Секцијата за трошоците се разликува од приходите по тоа што, самите трошоци се поделени на два типа на трошоци: сметки и останати трошоци. Сметките се категорија која се издвојува од другите бидејќи има дополнителни функционалности, кои ќе бидат разгледани во продолжение.

3.4 Bills (Сметки)

Сметките сами по себе претставуваат трошоци, но од посебен карактер. Тие може да постојат во системот но сепак да не се вбројуваат во сумата која се одлива за трошоци, во зависност од тоа дали се платени или не. Самата апликација е конструирана така да дава преглед во сметките дури и пред тие да бидат платени, за корисникот да може на поефикасен начин да си го планира својот буџет. На почетокот листата со сметки е празна, а внесувањето се одвива како што е прикажано на слика 3.4.1.

Откако ќе бидат внесени во системот сметките се регистрираат како трошоци од категорија ”Bills”. Тие имаат дополнителна категорија која се избира при креирањето, и која е од типот на: “струја”, ”вода”, ”интернет” и слично. Разликата од претходните форми за додавање на приход/трошок во системот е во слајдерот Paid со кој корисникот ја обележува сметката како платена или неплатена сметка. Со тоа е овозможено внесување на сметки, уште пред тие да бидат платени и со тоа се добива подобар увид во моменталната и во идната финансиска состојба на семејството. Ако за состојбата на сметката се избере дека е платена, истата таа сметка се смета за трошок и сумата која што ја има е одземена од профилот со кој е поврзана, а со тоа е додадена и на листата со трошоци во делот на Expenses од претходно. Во листата на трошоци, сметките се поделени во посебна секција која што е на дното на листата за истите да не се помешуваат со секојдневните трошоци (слика 3.4.3). По внесувањето на сметката во системот, корисникот може да ја промени нејзината состојба во секое време, а секоја промена на состојбата ќе ја променува и моменталната состојба на буџетот т.е секогаш кога сметката се менува од UnPaid  Paid сумата на сметката се одзема од профилот е назначен за одговорен за плаќање на таа сметка и секогаш која ќе се променни од Paid  UnPaid сметката не се смета како трошок и средствата кој биле платени за неа, се враќаат на сметката на корисникот кој ја платил. Логиката за повторување е иста како и претходно со таа разлика што: кога приходите/трошоците се автоматски пристигнати поради логиката за повторување, во моментот кога системот ги креира тој самиот ја додава/одзема соодветната сума која ја носи со себе тој приход/трошок. Кога системот креира сметка, сумата на истата таа сметка не е одземена од буџетот и од профилот со кој е поврзана. Сметката е креирана во системот, но е обележана како трошок за кој се чека одобрение за плаќање (pending). Сметката од слика 3.4.4 после четири поминати денови ќе го добие следниов формат: Како што се забележува и од сликите, надојдените сметки сами по себе не се плаќаат, напротив, корисникот сам треба да одлучи кога ќе ја плати сметката и која инстанца од сметката ќе ја плати. Со клик на “Delete This Bill” сметката се наполно брише од системот заедно со сите нејзини инстанци, а со тоа и сите пари кои се платени за сите инстанци, се враќаат на корисничкиот профил кој ги платил истите. Во овој дел (делот за сметките), корисникот ги има сите администраторски права врз сметките т.е. може да ги брише поединечни инстанци од сметката и може поединечно да ги менува состојбите на инстанците (преку listbox како што е и на сликата). Од друга страна, сметките се вид на трошоци и како што е веќе кажано, тие се појавуваат и во таа секција. Во конкрениов случај, листата со трошоци сеуште ќе изгледа како на сликата 3.4.3 бидејќи сеушта е платена само една инстанца. Со клик на деталите за оваа сметка (преку секцијата за трошоци) повторно ќе се добие приказот од слика 3.4.4. Доколку во деталниот приказ од делот за сметки, се променат неколку инстанци како платени (слика 3.4.6 – се плаќаат уште две инстанци), тогаш во системот ќе настанат неколку промени (слика 3.4.7).

Во секцијата за трошоци се прикажани само платените инстанци од сметките и истите можат само да се обележат како неплатени (поедниечно или групно – преку “Mark this Bill as UnPaid”) и истите неможе да се бришат од системот преку оваа секција.

3.5 Categories (Категории)

Корисникот го контролира билансот на својот буџет преку секциите за: приходи, трошоци и сметки. Во претходните делови беа разгледани споменатите секции и кај секоја од нив, корисникот рачно може да внесува приход/трошок/сметка. При додавањето на истите, еден од атрибутите за овие елементи е полето со паѓачко мени од каде што се избира категорија. Како што е прикажано и на слика 3.5.1 за секој тип на внесувања, постојат разични категории во паѓачкото мени: Типовите на категории не се појавуваат случајно и не се фиксни. При инсталација на апликацијата во системот се достапни по неколку категории за секоја од секциите, а на корисникот му е овозможено сам да ги контролира овие особини преку секцијата за категории. На слика 3.5.2 е прикажана листата со достапни категории при инсталација на апликацијата. Додавањето на нова категорија се врши преку клик на “Add Category” како што е прикажано на сликата 3.5.3. Притоа при додавањето на нова категорија, потребно е да се внесе името на категоријата и преку слајдери да се избере во која секција треба да припаѓа, а во која не. Откако е внесена, новата категорија се појавува во листата со веќе постоечките. Понатамошното упрвување со истата е овозможено преку преглед на деталите, со клик врз неа од листата. На пример, нека е внесена нова категоријата “Fee” и иницијално нека сите слајдери се поставени на вредност “Yes”. На слика 3.5.4 е даден прегледот за тоа како изгледаат деталите на оваа категорија. До тој степен оваа категорија ќе биде достапна како категорија за избор при додавањето на приход/трошок/сметка во системот, како што се гледа и од слика 3.5.6. При прегледот на деталите, корисникот може да ги менува слајдерите од “Yes” во “No” и обратно и со тоа да ја менува особината дали категоријата треба да се појавува во одредена секоја или не. Доколку смета дека нема да ја корисни категоријата која ја внел (или некоја од категориите кои доаѓаат со инсталацијата) корисникот во секој момент може да ја избрише, а со тоа да го избрише и секое нејзино следно појавување во било која листа за избор на категорија. Во продолжение е дадено појавувањето на категоријата Fee во постоечките секции, пред и по, нејзината промена од слика 3.5.5.

3.6 Transfers (Трансфери)

Трансферите на средства е една од најмоќните алатки на апликацијата за управување со домашниот буџет. Под трансфер се подразбира префрлувањето на парични средства од еден профил на друг, карактеристика која во пракса е многу корисна. На пример, детето во фамилијата бара пари од родителите и тие му даваат од парите кои ги имаат дома (Cash on Hand) и во апликацијата внесуваат трансфер дека одредена сума му дале на него, а потоа преку неговиот профил внесуваат каде и како тој ги потрошил неговите пари. Со тоа имаат комплетен увид во тоа, каде се одат парите и колку пари има секој член од семејството. При внесувањето на нов трансфер (слика 3.6.1) се внесуваат профилите помеѓу кои се врши трансферот, сумата на средства која се врши и датата на која што е извршен трансферот. Трансферот стапува на сила во моментот на датата која е внесена, притоа доколку е изберена моменталната дата (или некоја дата од минатото) трансферот на средства веднаш се извршува и парите се префрлени од еден профил на друг, а доколку како дата е изберена некоја дата од иднината, информациите за трансферот се евидентираат во системот и парите нема да се префрлат се додека не дојде избраната дата. Кога еден трансфер ќе се изврши тогаш истот не може да биде откажан и парите да се вратат на првобитните профили, но истото тоа може да се спроведе со додавање на уште еден трансфер кој ќе биде извршен во обратна насока. Листата од веќе извршени трансфери кои не можат да бидат откажани се во делот на Passed Transfers, a листата од трансфери кои ќе следуваат во иднина се сместени во делот на Upcoming Transfers. Процесот на додавање на нови трансфери е прикажан во продолжение на слика 3.6.4. Притоа како достапни профили во листата се појавуваат само оние профили кои се веќе активирани, според датата на креирање. По извршувањето на трансферите, финансиската состојба на профилите е прикажана на слика 3.6.3 (десно), а листата со трансфери е прикажана на слика 3.6.5. Како што е веќе споменато, поминатите трансфери не можат да бидат откажани, но трансферите кои се закажани за во иднина може да се откажат пред да бидат извршени и со тоа да се спречат. Отстранувањето на трансфер од листа нема да изврши помени во финансиската состојба, туку само ќе даде подобра прегледност на корисникот во оние трансфери кои му се од најголема важност. Во случај на повеќе трансфери, истите се подредени хронолошки според датите на извршување. Со отстранување на иден трансфер од листата, а без притоа тој да биде откажан, истиот автоматски се откажува и се брише од листата. Со неговото откажување тој не се брише од листата се додека корисникот не одлучи да го избрише. Трансферите имаат голема улога во зачувување на основните принципи на апликацијата т.е. да не се изгуби следењето на парите низ системот па така да: кога одреден кориснички профил е избришан од системот, доколку има некоја сума на пари – без разлика дали е во минус или плус, тие средства не се губат туку се префрлуваат на системскиот профил Cash on Hand. Со тоа е спречено следново сценарио: корисникот влегува во долгови и има негативна сума на неговата сметка. Со бришење на неговиот профил сите долгови се избришани од системот (што во пракса е нелогично) и тој реално има долгови, но апликацијата не му ги покажува и тој нема да е свесен за нив. Поради тоа, со бришење на секој профил, онаа состојба во која се наоѓа профилот, дирекно влијае и ја менува состојбата на профилот Cash on Hand. Доколку станува збор за невнимателност и корисникот не знае од каде му дошле долговите на сметката Cash on Hand, при бришењето на профилот и трансферот на средства, автоматки е креиран нов трансфер во листата на трансфери (генериран од системот) од каде што корисникот може да си провери за тоа кој профил дирекно влијаел на Cash on Hand, колкава сума се префрлила и кога се случил трансферот. По бришењето на профил, неговото име сепак останува во системот со цел да се води евиденција за извршените трансфери помеѓу профили кои веќе не постојат. Губењето на следењето на приходи и трошоци може да настане и при следново сценарио: одреден приход/трошок е поврзан со некој профил од системот и е назначен како приход/трошок кој се повторува на одреден временски период. На пример, сметката за интернет пристигнува на профилот на Niko. Со бришењето на овој профил сметката за интернет сеуште ќе постои и ќе пристигнува како трошок во семејството, но со бришењето на тој профил се губи секаква трага и семејството не е свесно дека има сметки за плаќање. Како цел на спречување на ваквата злоупотреба и губење на трагата за следење на парите, со бришење на профил од апликацијата, не само што моменталната состојба се префрла на профилот Cash on Hand, пристигнувањето на сите идни приходи кои требало да пристигнуваат на веќе извбришаниот профил се пренасочуваат кон системскиот профил Bank Account, а пристигнувањето на сите идни трошоци кои требало да пристигнуваат на веќе извбришаниот профил се пренасочуваат кон системскиот профил Credit Card. Од овде се јавува и основната намена на овие системски профили како и причината за тоа зошто тие не можат да бидат избришани.

3.7 Summary (Резиме)

Во секцијата за резиме, корисникот има појасен увид во сите приливи и одливи на пари во домашниот буџет, по одредени временски интервали, како и во сумираната општа финансиска состојба во која се наоѓа неговото семејство. Во оваа секција се има увид во сумата на сите приливи и сите одливи кои се евидентирале и како такви останале да влијаат врз буџетот во системот заедно со нивната меѓусебна разлика. Се има увид во сумираните состојби од сите кориснички профили заедно. Овие две суми не секогаш се исти (како и на сликата 3.7.1) поради фактот што при креирањето на профил, тој веќе може да содржи одредена сума. Во случајов, при креирањето на кориснички профил во секцијата Accounts, профилот како сума која веќе ја содржеше во моментот на креирањето беше 1000 МКД (слика 3.1.1), па подари таа се појавува разликата од 1000 МКД во крајното резиме. Освен тоа, на корисникот му се нуди подобар преглед во тоа како се движеле приходите и трошоците (и нивната меѓусебна разлика): во текот на денешниот ден (се мисли на денот почнувајќи од 00:00 часот, а не на последните 24 часа), во текот на изминатите 7 дена, во текот на месецот (почнувајќи од првиот ден на моменталниот месец, а не во изминатите 30 денови) и во текот на годината (почнувајќи од првиот ден на моменталната година, а не во изминатите 12 месеци). До секоја од прикажаните суми постои и копече “see all” кое што овозможува, освен прикажаната сума, да се погледне подетално во прикажаниот податок т.е. да се прикаже листата од сите приходи и трошоци кои ја оформиле сумата која што е прикажана и истовремено да може да се управува со нив на исти начин како што тоа се прави преку секциите. На пример, на слика 3.7.1 се гледа дека во текот на денешниот ден сеуште нема пристигнато приливи во семејниот буџет, а се потрошени 170 МКД. Листата за тоа кои се приходи/трошоци влијаеле денес, и деталите за истите, се прикажани во продолжение. Ваквиот приказ е корисен бидејќи корисникот може да си провери: како денес се трошеле парите во семејството.

Во последноте 7 денови, во вид на приходи се пристигнати 700 МКД, а како трошоци се потрошени 610 МКД. Приказот на листата од приходи и трошоци кои ги оформуваат овие суми, како и деталите за секој од приходите и деталите за секој трошоците, се прикажани во продолжение.

На деталниот приказ за приходите се забележува дека приходот од денешниот ден сеуште не е пристигнат и покрај тоа што е очекуван. Причината за тоа е часот на пристигнување. Кога приходите и трошоците пристигнуваат со повторување, се запазува и часот кога тие првично биле креирани. Во моментот на анализа на апликацијата, сеуште не е поминат часот во кој пристигнуваат сите инстанци од приходот. Поради истата таа причина, приходот од денешниот ден го нема ни на листата од слика 3.7.2 Од друга страна пак, трошоците (слика 3.7.6) за денешниот ден се веќе пристигнати, бидејќи часот за нивното пристигнување веќе поминал. Како што се забележува на сите овие прикази, корисникот освен што може да врши преглед во приходите и трошоците, тој истовремено има пристап до копчињата за нивно комплетно бришење/бришење по инстанци од системот. Така да може да провери кои се приходи/трошоци (на пример) се случиле денес и ако некој од нив е внесен по грешка да го избрише. На тој начин се врши бришење од системот т.е. отстранување од сите листи и враќање/земање на парите во профилите кои извршиле плаќање/давање. При бишењето се извршуваат сите оние проверки и ажурирања (трансфери и пренасочување на идните трансакции) кои се објаснети во изминатите секции. Важна напомена при бришењето преку копчето од горното мени е дека: со тоа се врши комплетно бришење на приходот/трошокот од системот, без разлика на тоа колку од инстанците моментално се прикажани. Сите инстанци не секогаш се прикажани преку овој приказ. На листата од инстанци се прикажани само оние кои се активирале во временскиот период кој се разгледува (трошокот од сликата 3.7.3).

3.8 Дополнителни секции (калкулатор и помош)

Home Budget Manager има дополнителни секции чија што намена е да му помогнат на корисникот во извршувањето на пресметки (калкулатор - Calculator) и да му претставуваат водич низ тоа како може да ја користи апликацијата (помош - Help). Тие се достапни во менито на места кај кои е најголема веројатноста дека ќе му бидат од корист на крајниот корисник (калкулаторот е кај резимето и кај трансферите, помошта е на почетниот екран). Приказите за тоа како тие изгледаат се дадени во приодолжение.

Менито за помош е имплементирано во pop-up dialog box за добивање на подобар изглед.

---

4 Заклучок (Concluding remarks)

Мобилните уреди како дел од современото опшество, завземаат огромен дел од ИТ секторот, а паралелно со тоа доаѓа до континуиран раст и развој на апликациите за овие уреди. Секојденвно се работи на развој на апликации кои делуваат во различни сфери од животот на човекот, кои всушност олеснуваат одредени сегменти од сферите на нивното делување (во смисла на пресметки, планирања, графички прикази итн). jQuery Mobile е само еден пример за тоа како веќе познатите техники може да се прилагодат и да се приближат кон развој на нешто сосема ново, со користење на нешто што е веќе видено и веќе познато.