Posts

BangBits Privacy Policy

Welcome to the BangBits Privacy Policy When you use apps and other software developer by BangBits, you trust us with your information. This Privacy Policy is meant to help you understand what data we collect, why we collect it, and what we do with it. It is important to understand, that BangBits operate both as an owner of given software and as a proxy for work developer by Customers. App's published by BangBits but taking part of a specific Customer solution are treated separately in the "Specific Products" section below. Information we collect and why we collect it We collect information to provide better customer experience. This may happen through various forms of remote logging using Google Analytics, Firebase Analytics or similar tool. At no time is personal data directly mappable to an identifiable user being collected. What can be collected is: Device identifiers (DeviceID, IMEI and handset identifiers) in order to black-list and/or white-list oth...

Best-practice Android logging

Image
A blog post about Android logging? Must be a slow news day you are probably already thinking, but hear me out on this one. This is a quick tour around my personal best-practices and you may likely not agree with all of them - if so, let me know in the comments. ;) Android Studio and LogCat On Android, logging has always been an integral part of the development experience, first through the standalone LogCat utility and since through the Android Studio integration. The build-in LogCat now even offers advanced filtering capabilities based on logging level, regular expressions for package names, logging tag and the actual log messages. However, all this power is really only useful if you play along nicely at the source level as well, or you will drown in log messages without really knowing how to specify what you want to see. This is a common problem as the Android OS and any libraries you may use will spit out an obscene amount of logging, especially at the verbose level. Use correct...

Rejsekort, NFC og smartphone kompatibilitet

Image
Det sker ikke så sjældent, at jeg får en mail på noget lignende følgende form: Min telefon har da NFC, hvorfor kan jeg så ikke downloade din app? Hvorfor sker ikke noget når jeg scanner kortet med din app? Jeg savner et sted hvor man kan se om hvilke telefoner der er kompatible med din app (Rejsekortscanner). Jeg kan finde nogle spredte informationer skrevet af dig. Nogle er 2 år gamle på din blog. Hvorfor vedligeholder du ikke bare en liste? Det er jo gode spørgsmål som jeg har svaret på rigtig mange gange de seneste par år. Det siger sig selv, at som udvikler er jeg naturligvis interesseret i, at gøre det så nemt og smertefrit for potentielle brugere som muligt - men Rejsekort og NFC er og bliver bare et kompliceret emne. Herunder har jeg forsøgt at bryde emnet ned i let-fordøjlige bidder. Hvad er NFC? NFC (Near Field Communication) udspringer af envejskommunikation RFID (Radio Frequency IDentification), og tillader kontaktløs tovejskommunikation med et smartcard. Det er ...

Android: Remove a dependency from a build variation

Image
Android's build variations (flavor and buildType) feature is an awesome way of maintaining several cuts from the same source code. I've used it both for white-label branding solutions and for Free vs. Pro versions. However, sometimes you have different dependencies between the versions where you will usually have to live with the fact, that all variations of your app gets the superset of dependencies. There are ways around this however, and I used it to shave over 400Kb off from a Free variation to a Pro variation. The problem Java is a static language, so you can't just go ahead and rely on late-bound linking and have Proguard slice and dice. It's unclear to me, whether the Android variations mechanism extends to Java source code, but I don't think it does. It's also unclear to me, whether an SPI approach could be used, letting the build class-path inject different implementations of some API for use at compile-time. What IS clear to me however, is that ...

Rejsekortscanner Pro

Image
Forleden frigav jeg version 2.0 af Rejsekortscanner, der repræsenterer en væsentlig stabilisering af fortolkningen af rejsekortet samt forbedringer i brugeroplevelsen. Men alt dette blev faktisk sat i gang p.g.a. folk der skrev til mig, at de ønskede en version uden reklamer - en sådan version er nu tilgængelig ! Versionen uden reklamer har jeg valgt blot at kalde Pro, fordi noget skulle den jo hedde der adskilte den fra gratis versionen. App'en henvender sig til folk der bevidst hellere smider en skilling istedet for at være udsat for et reklamebanner. Jeg hader selv reklamer, hvorfor jeg har været tæt på helt at droppe reklamebanneret. Men selv om man ikke ligefrem bliver rig af at have en niche app der er installeret hos 17.000 brugere, så får man trods alt betalt lidt mobilregning mv. og der ligger stadig rigtig mange timers arbejde bag Rejsekortscanner. Spørgsmål og svar Er 25kr ikke lige dyrt nok? Næææ det synes jeg egentlig ikke. Momsen udgør 5kr, Google skal...

Rejsekortscanner 2.0

Image
Jeg har i længere tid arbejdet på en betalingsversion af Rejsekortscanner, til dem der efterspørger at komme af med reklamerne. Men når man lancerer noget man tager betaling for, vil kunder naturligt forvente høj kvalitet og jeg følte ikke helt at den gamle version kunne leve op til dette. Dette betød, at jeg i større grad skulle benytte mig af den dokumentation jeg har fået adgang til fra Rejsekort A/S, ligesom jeg havde brug for en stor pulje af tests for at sikre imod regressioner - for jeg har stadig begrænset adgang til den forretningslogik der ligger til grund for rejsekortet (hvad er den maksimale rejsetid, hvad er den maksimale transit tid, hvordan hånderes vintertid osv.). Derfor besluttede jeg mig for, at både den gratis (med reklamer i) samt kommende betalingsversion, skulle baseres på samme kode og derfor begyndte arbejdet først og fremmest på en version 2.0 af den gratis udgave. Det har taget længere tid end ønsket, men det var dét der skulle til. App'en er altså ...

Beware of SQLite and the Turkish Locale

Image
Today I came across a truly puzzling issue on Android. An otherwise tried and tested application crashed consistently when running on a device using Turkish as the current locale. App crashing on a Turkish device The problem occurs in a large app developed for a customer, inside a proprietary binary component, so no direct debugging was possible. All I had available was a vague stack trace showing the root problem to be a NullPointerException from trying to parse an integer: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Integer.intValue()' on a null object reference Not much to go on, the goal was now to figure out just what could cause such a problem just from running on a device using Turkish Locale. Having spent some time on Google, searching for other people's trouble with the Turkish Locale, it became clear that there are issues with lowercase Strings in Turkish.  I started working on a small isolate...