Showing posts from 2016

Best-practice Android logging

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

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

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

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

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

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

Getting the reference address of a variable on Android

In Java, we've always had our share of undocumented fun through the sun.misc.Unsafe class . You can allocate memory, access data fast without range checks and - what this post is about - get the memory address of some object. Motivation So why would you do this in a memory managed language like Java? Well, it's arguably rare you have an actual need, however it can come it handy at times. For instance, I needed it when debugging some weird behavior on Android. I had a strong suspicion that the (insanely complex) Android life-cycle and associated serialization aspects were the cause of me seeing an object instance mutate (I.e. change its hash value). Unfortunately Android Studio doesn't support putting a watch on a variable. What I really needed was a way to document identity equality, just as we can document value equality with the hashCode() mechanism. Android specifics It's not hard to find examples of the use of sun.misc.Unsafe on the Internet . Using it on And

The letdown by Air Canada

This is the personal account of me and my family's recent troublesome journey and treatment by Air Canada, when traveling home to Denmark after having spent christmas in Montreal, Canada 2015. Toronto Pearson airport, my daughter sleeping in a corner while my wife is watching over her. Let me clarify that we are not unaccustomed to international traveling, having crossed the Atlantic at least 80 times over the previous 15 years. I’ve personally experienced my share of cancelled flights, delays and hotel stays etc., some of which I have even blogged about before . However, what I describe in the following takes the price as the worst travel experience ever, not least because it has to do with my infant daughter. I may get a detail or two wrong because of the stressful circumstances, but it has been written down a day after arriving home and cross-checked by my wife so can assumed to be quite accurate. My goal with this is first and foremost, to remember why Air Canada is n