Bankdroid - v1.9.6.4

Att hårdkoda tycker jag inte låter som en särskilt bra idé. Bättre att göra ett gränssnitt som alla applikationer som användaren tillåter kan använda sig av.

 

Får hålla med där. En sång begränsning gör det också väldigt svårt att utveckla appar mot bankdroid.

Jag gillar lösningen där bankdroid poppar upp och kräver manuellt godkännande.

Sent from my HTC Desire using Tapatalk

 

Hur svårt är det att integrera syncning av Bankdroid i androids konto hantering?
Jag tänker mer på om man har appar som stänger ner data trafiken under vissa tider och aktiverar syncning under en kortare stund för att spara batteri. Tex JuiceDefender. Går kanske göra på något annat sätt

 

Varazir: Det blir eventuellt en del designändringar och ganska mycket jobb. Men det är en intressant lösning på att göra bankdroid-funktionaliteten tillgänglig för andra appar.

Exempel
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html

Jag har forkat git-projektet nu iaf och tänker labba lite med att sätta upp en content provider, verkar inte så farligt svårt. Får se om det blir något bra.

 

Hei,

Beklagelig at en slik fin App. kun er for "Swedish banks". Er det planer om en Scandinavisk versjon e.g. Norsk, Dansk etc?

Hilsen
Bjørn

 

Om det finns möjlighet att logga in på andra skandinaviska banker utan e-legitimation, bankdosa eller certifikat så är det självklart möjligt att få med dem i Bankdroid. Följ helt enkelt stegen i första inlägget.

 

Hej igen

Nu har jag lagt till en content provider, den är inte klar ännu dock. Men jag har fått det att snurra någorlunda iaf

Har inte tittat så mycket på säkerhet men det blir nästa steg. Tänker mig permission plus en token som man får kopiera in som sedan används i URI:n som man skickar till content providern.

Ändringarna på bankdroid finns här: https://github.com/magnusart/android-bankdroid/commits/content-provider

Här är klienten (visar bara en lista med alla transaktioner hittills): https://github.com/magnusart/TranStatistics/commits/master

Hoppas att det blir något bra av detta.

Edit: Jag la till så att man kan hämta bank/konton också plus att jag uppdaterade GUI:t i TranStatistics så att det går att testa lite bättre. Nästa steg blir säkerheten.

Edit 2: Säkerheten fixad. Det börjar bli dags att starta en egen tråd nu snart.

 

dum fråga kanske, men vad innebär content provider?

 

Kotten: Att en applikation får tillgång till att läsa data från en annan applikation. Backa nån sida eller två så förstår du vad det handlar om.

 

Nån som har koll på Avanza.... får inte mitt minikonto att funka.
Svaret blir bara:

Kunde ej skapa konto
"Inga konto funna"..

 

Fint, ska ta en titt under kommande veckan.

Om du följer stegen i första inlägget så kan jag ta en titt på vad som kan vara fel.

 

Liato:
Jag har börjat implementera så att all transaktionshistorik laddas för Swedbank, dvs den historik som är tillgänglig för mobilappen. Jag ser att det behövs för att kunna få in så mycket historik när man börjar använda min app för första gången.

Min fråga är om du tycker att BankDroid bör hålla ackumulerad transaktionshistorik?

Om BankDroid appen har ansvar för det så behöver min app bara hämta den information som finns tillgänglig och matcha den. Annars så behövs det ett intent som ber BankDroid att hämta all tillgänglig transaktionshisorik initialt.

Början på historikimplementation ligger som en egen branch "swedbank_transactionhist" på min github.

 

Jag tänkte att all historik kunde hämtas när man först lägger till konotot. Vanliga uppdateringar efteråt hämtar bara transaktioner från första sidan.

För att det ska fungera måste transaktionerna dock ha idn och jag har inte kommit på någon bra lösning för det än.

 

Transaktionsidn

Hmmm ja den är lite lurig. Jag tror jag kom kanske på ett sätt att lösa det. Läs nedan och fundera på om du kan slå hål på det. För att det ska fungera så måste vi nog acceptera vissa begränsningar.

Vi låter transaktioner som tillhör samma datum grupperas som en transaktionsgrupp. Inga transaktionsidn sätts för än följade kriterier uppfylls för alla transaktioner inom gruppen:
1. Vi skapar inga globala transaktionsidn för än dagens datum har passerat transaktionsdatumet
2. Det måste finnas transaktioner innan datumet för transaktionsgruppen, så att vi är säkra på att vi har alla transaktioner för en viss dag
3. Det får inte finnas några reserverade eller skyddade belopp på transaktionsdatumet

Om vi tar vårt tidigare exempel så kan vi skapa ett ID genom att ha en funktion som tar alla delarna och skapar ett värde (exvis en hash, men exakt hur är inte intressant just nu)
För transaktionsgruppen 10-12-27 så kan vi 10-12-28 eller senare generera ID:n genom att dels generera det första värdet och lägga på ett löpnummer för att få en kompositnyckel.

Exempel:
genId(10-12-27, PAYPAL *CITYDEAL, -590,00) => XYZ123 + _5 => XYZ123_5
genId(10-12-27, PAYPAL *CITYDEAL, -590,00) => XYZ123 + _4 => XYZ123_4
genId(10-12-27, SF BOKHANDELN AB, -170,00) => ABA234 + _3 => ABA234_3
genId(10-12-27, FILIPPA K MAN, -720,00) => ASF242 + _2 => ASF242_2
genId(10-12-27, L05 SOLO GÖTEBOR, -500,00) => DDA223 + _1 => DDA223_1

Nu har alla transaktioner unika ID:n som kan återskapas om man tömmer databasen och laddar om eftersom bankerna aldrig ändrar i transaktionsloggarna i efterhand (skulle gissa att det är olagligt). Dock så kan vi tappa vissa transaktioner i slutet om vi tömmer och laddar om, men det är ändå oundvikligt.

Håller det? Det enda jag är osäker på är hur länge efter man har köpt något en ny transaktion kan dimpa in, räcker det med en dag?

 

Det räcker nog inte med en dag. Köp i utlandet är inte ens säkert att de reserveras, som exempel.
ICA-Banken kör också en småunderlig variant med köputrymme och saldo separerat. Köputrymmet = saldo - reservatione exkl köp i utlandet som alltså kan dimpa ner bra långt senare.

 

Hmmm... Swedbank har ju något som heter bokföringsdatum som inte sätts för än transaktionen har bokförts. Undrar om andra banker gör på samma sätt, för på något sätt måste de väl särskilja transaktionerna?

Så länge vi kan gruppera transaktioner utifrån ett liknande kriterium och vet att transaktioner inte kommer att dimpa in i efterhand i den gruppen när den är "stabiliserad" så kan man lösa det på ett liknande sätt.

Antagligen så kanske det blir olika lösningar för olika banker, inte optimalt men så länge ID:na blir unika och kan återskapas ifall de läses in på nytt skulle det fungera.

 

Nordea har liknande skumheter. Där listas nya köp som "Reserverat kortköp" fram tills ett tag (motsv. bokföringsdatum), och då byter den text i transaktionsloggen.

Så att använda texten för ID är nog uteslutet. Inte minst ger det väldigt lite hjälp när ungefär all text hos Nordea består av "Kortköp", "Överföring" eller "Bankomat" (det är naturligtvis mer utförligt om man loggar in med sin e-ID).

 

Jag är inne på samma sak. Kom även på att ID:t måste utgå ifrån banknamn och konto. Detta blir ytterligare en begränsning (ändrar du namn på banken så är det kört), men jag kan absolut se ett fall där man får en kortavgift på flera konton med samma text samma dag, vilket skulle ge samma id.

Mitt förslag skulle då vara ett transaktionsid baserat på följande:
genId( bankname, accountname, accounting_date, order )
genId( "Magnus Swedbank", "VISA-kortet", "2010-12-14", 1 )=> MGNSSWDBNK_VSKRTT_101224_1

Det datum man använder borde vara motsvarande bokföringsdatum för varje bank, och samma begränsningar som innan (transaktionerna måste vara bokförda).

Skulle detta fungera tro? Blir många begränsningar. Med detta så får man fundera på konverteringsmetoder som gör att man kan byta namn på banker och konton.

 

Är det säkert att nya transaktioner på ett datum placeras i ordning på alla banker? Jag tycker ordningen ofta känns rätt slumpvis men det är möjligt att det är listade i bokföringsordning per dag, men jag undrar om inte ordningen kan ändra sig när nya trillar in..

 

Jag hänger inte riktigt med på varför du vill ha banknamnet som en del av identifiern? Raderna behöver ju ändå bara vara unika per konto? Och ordningen förstår jag inte riktigt heller, eftersom den ju ändras kontinuerligt?

liato var däremot inne på något på IRC; att använda även ett par tidigare transaktioner som del av identifieraren.

Och för att skarva den idén; använd bara föregående transaktion, men använd dess checksumma (jag skulle föreslå en md5-baserad sådan):

md5sum("datum" + "summa" + "föregående_transaktions_md5summa") = identifierare