BangBits

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

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å

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

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