Podla potreby podpory kariet MF standard je mozne vyhladat telefon v zozname telefonov. Je potrebne aby mal telefon podporu mifare standard kariet (stlpec 'Mifare 1k').

Overenie podpory citania kariet Mifare standard je mozne na konkretnom telefone pomocou nasledujuceho postupu.

Uzivatelsky manual sa nachadza na ceste:

/DokumentaciaTD/VyvojovyUsek/VyvojSW/TransFare/TransFare_Inspection/Uzivatelska prirucka.pdf

Instalacia zariadenia, vytvorenie pristupu do google play privatneho kanalu, nastavenie uctov sa vykonava podla nasledovneho postupu.

Popis postupu instalacie

Popis postupu pre aktualizaciu

Popis postupu pre pridanie noveho zakaznika

Aplikacia sa z pohladu pouzivatela cisluje v 3 cislach Major.Minor.Bugfix. Major sa meni pri vyznamnych zmenach. Kombinacia Major.Minor sa pouziva na planovanie verzii v redmine taskovaci. Bugfix sa meni podla nahlasenych chyb pre konkretny planovany release verzie.

Je potrebne zdvihnut verziu kodu aplikacie v build.gradle. V sekcii 'android', v podsekcii 'defaultConfig' zdvihnut versionCode a versionName:

    defaultConfig {
        applicationId "sk.sm.nfcauditor"
        minSdkVersion 18
        targetSdkVersion 22
        versionCode 23
        versionName "1.20.1"
    }

toto sa pravdepodobne prepracuje na kompilovanie podla kompilacneho servera jenkins

Generovanie apliacneho instalacneho balicka sa robi tak, ze v android-studiu zvolime 'Build' → 'Generate Signed APK Wizard'. Pouzijem transdata.jks certifikat na podpis aplikacie. Transdata.jks je certifikat generovany pre TransData na podpis aplikacie. V pripade potreby mena a hesla sa obratte na spravu siete

Princip nasadzovania novsich aplikacii je v tom, ze sa udrzuju .php skripty na serveri, komunikujuce s TransOffice a so zariadeniami, spatne kompatibilne s jednou starsiou verziu komunikacneho protokolu. V spojeni s tym, ze je zapnuta automaticka aktualizacia aplikacie a ze sa udrziava jedna verzia pre vsetkych zakaznikov, by nemalo nastat, ze nebude zariadenie schopne komunikacie so serverom.

Mozu nastat tieto pripady nutnosti update:

1. Update aplikacie, bez zmeny databazy a bez zmeny komunikacneho protokolu. Dojde iba k otestovaniu alfa verzie aplikacie, presunutie do beta testingu pre zakaznika.
2. Zmena struktury DBS na serveri, teda aj zmena .php skriptov. Dojde k otestovaniu servera a aplikacie.
3. Zmena struktury DBS v TransOffice, teda aj zmena DBS na serveri, zmena .php skriptov. Kompletny postup nizsie

Postup nasadenia je potom nasledovny:

• Dojde k otestovaniu aplikacie podla postupu testovania aplikacie
• Upravi sa DBS testovacieho uctu androidTariffSystem na novsiu verziu (ak sa upravuje) a porovna sa obsah s vyvojarskou testovacou DBS (doublecheck struktury)
• Upravia sa DBS a .php skripty na ostrom serveri (stop appache, upload, start appache). Overi sa ich beh.
• Skontroluju sa voci DBS na ostrom serveri androidTariffSystem
• Updatuju sa jednotlivi dopravcovia v ich TransOffice (ak sa meni komunikacia)
• Vyskusa sa manualny update dat z TransOffice na server (ak sa meni komunikacia)
• Promotuje sa aplikacia z alfa do beta testingu. Po schvaleni zakaznikom do produkcnej verzie.

Prihlasime sa na domenu: google play developer console

Zvolime aplikaciu, ktoru pozadujeme nahrat:

Zvolime upload APK:

Nahrame instalacny balik a pockame par hodin :)

Android SDK version VS. Android OS version

Android studio version VS. gradle build tool version

Na generovanie skalovatelnych a roztahovatelnych obrazkov sa pouziva pre android aplikaciu asset studio, ktory upravuje PNG subor, tak aby aplikacia vedela, ktore casti obrazku maju moznost byt roztiahnute a ktore hrany obrazku maju byt zachovane.

Asset studio okrem toho, ze definuje oblasti v obrazku, ktore maju byt skalovatelne generuje aj obrazky v roznych DPI pre rozne velke obrazovky: Google vyvojarska dokumentacia pre rozne velkosti obrazoviek

Tool na generovanie 9.png formatu: Android Asset studio

Este netreba zabudat na optimalizaciu vekosti obrazkov pouzitych v aplikacii. Viac na tejto stranke

Revizorska citacka komunikuje s back-endom (server v telekom cloude) pomocou HTTPS 'POST' a 'GET' requestov.

Prvy sposob autentifikacie ktory bol pouzity bola pomocou BKS, ten uz vsak neupouzivame. Momentalne sa pouzivaju bezne verejne kluce vo forme .crt suboru, ktory je potrebne mat v instalacnom baliku (APK). Pre kazdy server s ktorym revizorska citacka komunikuje, je potrebne mat osobitny .crt subor. V pripade ze sa pridava novy, je potrebne upravit aj kod aby ho aplikacia pouzivala. Certifikaty sa nahravaju do projektu na cestu:

NFCAuditor/app/src/main/res/raw

Vyvojove diagramy ako usecase, class, state, component, class diagram business logik je mozne najst na tejto stranke

Link: https://fabric.io/login
Meno: user@transdata.sk

V menu zvolime

Tools->Structure Synchronization

1. navolime zdrojovu DB a schemu (vzorovy stav aky chceme dosiahnut) a cielovu DB a schemu (vychodzi stav, ktory upravujeme)
2. v compare options nastavime co chceme porovnavat (a z toho budu aj vytvarane SQL prikazy)
3. v execution options nastavime ake sql prikazy sa budu vytvarat (naposledy boli ponechane predvolene nastavenia, teda SQL to create/change/drop, Create inheriting parent)
4. spustime Compare tlacidlom vpravo dole

Navicat nasledne zobrazi v com sa navolene db (schemy) lisia a na spodku je zoznam prislusnych SQL prikazov ako dosiahnut taky stav. Pozadovane prikazy oznacime (ctrl+lava mys), nasledne cez pravu mys (kontextove menu) zvolime moznost copy a skopirujeme zvolene prikazy do textoveho editora v ktorom vytvorime rozdielovy skript.

ValidTicket(0),
InvalidCard(1),
CardIsBlocked(2),
CardIsBlockedOnBlackList(3),
PrepaidTicketIsNotActivated(4), // not implemented in evaluation logic
TicketBeforeStartValidity(5), // not implemented in evaluation logic
TicketPastValidityEnd(6),
ForeignPrepaidTicket(7),
NotValidSpatialUnit(8),
NoTicketsOnCard(11), // not implemented in evaluation logic
AnotherProtectNumber(15),
NotValidBusStop(16), // deprecated value, use CurrentBusStopBeforeCheckInBusStop or CurrentBusStopAfterCheckOutBusStop
UnlabeledPrepaidTicket(17), // not implemented in evaluation logic
NotValidLineTypeOnPrepaidTicket(18), // not implemented in evaluation logic
AnotherLine(19),
WithoutDiscount(20),
AnotherTrip(21),
CardDataMissing(22),
CardIsNotSold(23),
NoValidCustomerProfile(24),
NotValidAnymore(25),
NotValidDiscountAnymore(26),
TicketWithInvalidStatus(27),
CurrentBusStopBeforeCheckInBusStop(28),
CurrentBusStopAfterCheckOutBusStop(29),
FreeCard(30),
NotAllowedCompany(31), // card company (provider number) is not in allowed companies
UbianTicketNoData( 32 ),
UbianTicketProcessingError( 33 ),
UbianTicketTimeStampNotValid( 34 ),
UbianTicketNotActivated( 35 ),
UbianTicketCancelled( 36 ),
UbianTicketNotFound( 37 ),
UbianTicketNotValid( 38 ),
UbianTicketVerifyError( 39 );

Organizacia testovania aplikacie je postavena na prostriedkoch poskytovanych prostrednictvom google play. Umoznuje testovanie interne, testovanie zakaznikom, aj nasadenie do privatneho produkcneho prostredia. Interne testovanie prebieha na aplikaciach v alfa verzii. Pouzivaju sa na to testovacie ucty priradene v telefonoch: test1.transdata@gmail.com az test<X>.transdata@gmail.com (pripadne sukromne ucty na sluzobnych telefonoch IBA zamestnancov TD). Po uspesnom dotestovani sa aplikacia presuva do beta testingu, kde je k dispozicii iba emailu beta.transdata@gmail.com (pripadne sukromne ucty IBA zamestnancov TD), ktory maju nastaveny niektore zariadenia u zakaznika. Nasledne sa presuva do produkcnej verzie, kde je k dispozicii privatnym kanalom iba pre ucet customer@transdata.sk, ktory je nakonfigurovany na beznych zariadeniach.

1. Na vyvojarsku testovaciu databazu (phoenix) sa nahraju nove .php skripty a vykona sa test update sql servera (ak sa upravuju)
2. Vyskusa sa starsia aplikacia komunikujuca s novsimi skriptami (ak sa upravuju) – primarne pre overenie statistiky
3. Vyskusa sa update starym skriptom z TransOffice (ak sa menil)
4. Vyskusa sa update novym skriptom z TransOffice (ak sa upravuje)
5. Vyskusa sa starsia aplikacia nad novou strukturou (ak sa uploadovali nove data) – primarne pre overenie struktury novych vstupnych dat
6. Nahra sa novsia aplikacia do alfa testingu na google play
7. Vyskusa sa novsia aplikacia nad testovacim serverom

Testovacie google ucty

Existuje uzivatelsky manual so screenshotmi obrazoviek, nie je bohuzial uplne aktualny, ale celkom pouzitelny aspon pre ilustraciu. Nachadza sa na ceste:

\Dokumentacia\Projekty_ISO\02_PlatobnySystem-Intel\005-RevizCitackaIPAQ\Documents\Manuals\ 

Kazdy novy kus novej revizorskej (m3) treba najprv inicializovat - inicializacia robi dve podstaten veci - instaluje command line (lebo windows mobile 6 ho uz by default nema) a tiez uklada na zariadenie jeho 'seriove cislo'. Vsetko potrebne pre inicializaciu je na mamute/kronose/hadese:

\Dokumentacia\Projekty_ISO\02_PlatobnySystem-Intel\005-RevizCitackaIPAQ\InitRC\Inicialize\ 

Davam do pozornosti ReadMe.txt

\Dokumentacia\Projekty_ISO\02_PlatobnySystem-Intel\005-RevizCitackaIPAQ\Documents\InternetSettings\ 

- logy sa osobitne zapinaju pre aplikaciu a pre platobny.

• pre aplikaciu sa zapinaju v Settings.xml resp SettingsM3.xml (je dobre si uvedomit, ze Settingy sa prehravaju spolu s datami pri kazdom vlozeni zariadenia do kolisky, takze ich treba modifikovat na serveri, nie na zariadeni, inak uprava nebude mat dlhe trvanie)

LogMode="1"

• pre plaotbny sa zapinaju v PTConfigu ako

LogType="0xFFFFFFFF"