# SystemDotRun Dorian Cussen's Super Blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Application-as-a-Function Thinking DevFeed: [Application-as-a-Function Thinking]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2022-10-11T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Development](), [Code](), [Testing](), [Requirements](), [Object-oriented programming (OOP)](), [race-condition](), [event driven]() Tags: [code](), [development](), [event-driven](), [oop](), [productivity](), [race-condition](), [requirements](), [testing]() ### AI overview The article argues that placing a stateless pure function at the core of an application, within a functional-core imperative-shell architecture, can simplify testing and reduce complexity. It discusses how scattered requirements, weak documentation, poor tests, naming problems, race-prone object-oriented state, low cohesion, and event handling can make systems harder to understand and maintain. ### Source excerpt TL;DR Architecting an application with a pure function at its core can be a first step towards the "functional-core imperative shell" ideal, which can simplify testing and lower an applications complexity bar. Why? Simplification. As a novel alternative to KISS, we start with a quote from The Grug Brained Developer: complexity very, very bad And for completeness: Complexity: a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it For many applications the challenge is how to simply & correctly represent a large number of domain requirements in code, and how to raise the complexity-bar sufficently to enable a high degree of engineer productivity & runtime stability . A low complexity-bar reduces the amount of time it takes for a developer to get to the brain-meltdown-event-horizon-like state after which completion of new work slows down expontentially due to sheer codebase and test suite complexity which results in low grokability (i.e. code which is hard to understand or follow), an increasing degree of emergent behaviour, a higher probability of introducing regressions and generally, just slow development. A high complexity-bar conversely allows a desired order and serenity to take hold and more time spent on adding value as opposed to fire-fighting. I have observed different reasons for a low complexity bar, including: Domain requirements being spread throughout all codebase components Non-existent / incomplete / disorganised domain requirements documentation A non-existent / disorganised / bloated / poorly performing test suite Poor naming Race condition rich OOP state manipulations Low architectural cohesion across a codebase / team In addition if your application is highly event driven (user input / network / OS / peripherals / sensors) not having a simple approach to process incoming events can lead to chaotic code. Multiply this if you are working within a sensitive domain which has strict requirem ## Android Architecture: Runtime Centric Thinking DevFeed: [Android Architecture: Runtime Centric Thinking]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2021-11-08T00:00:00Z Content type: opinion Language: en Sources: [SystemDotRun]() Topics: [Android](), [Testing](), [Test automation]() Tags: [android](), [android-architecture](), [architecture](), [blog-post](), [complexity](), [production](), [test-automation]() ### AI overview This blog post presents a high-level overview of a runtime-centric architecture for Android applications. Drawing on the author's experience using it in two production projects, it discusses Android component lifecycles, instantiation, test automation, threading, fragments, and ways to reduce run, build, and test-time complexity. ### Source excerpt For at least 7 years I have been playing with "alternative" Android architectures in a professional context. This blog post is a brief overview to an architecture I have been using for the last two production projects for which I was Android Lead and outlines a high level introduction to a production-level runtime-centric application. I will note at the start I am not attempting to persuade anyone to use this approach over any other, but rather: Understand my own thoughts better through writing Share something which has worked well for me which others may find interesting I imagine it may raise more questions than it answers, and if so please leave a comment and I can expand any concepts if desired. Motivation My original motivation to think about alternative Android architectures was due to me often feeling there were personally unexplored and advantageous ways to structure certain types of applications on an OS like Android, which has a number of idiosyncrasies including application component lifecycles, application component instantiation, difficulty in test automation and so on. In the 12 years I have been a professional Android developer I have seen some common examples of where complexity has been layered on top of some of these areas in the aim of making them easier to deal with on a day to day basis when often an arguably simpler divergent approach has been overlooked. For some quick fire examples I would include here: Test time OS level faking frameworks vs OS abstraction at build time Complex lifecycle aware asynchronous view-level listeners as opposed to rendering immutable states Complex 3rd party dependencies utilised for threading purposes as opposed to thread abstraction Fragments vs thin views cough I found that there were often common solutions to common problems but which often came with an additional baggage of increased run / build / test time complexity. Instead of thinking in terms of surface level solutions my mind kept wondering back to think ## Android Security: Beware of the default IV! DevFeed: [Android Security: Beware of the default IV!]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2017-09-27T00:00:00Z Content type: tutorial Language: en Sources: [SystemDotRun]() Topics: [Android Security](), [Cryptography](), [Encryption](), [Security](), [Code]() Tags: [android](), [android-security](), [code](), [cryptographic](), [cryptography](), [encryption](), [security]() ### AI overview This Android security article explains why AES encryption should use a random or pseudorandom initialization vector (IV). It reports that Android 4.3's AndroidOpenSSL provider could return an all-zero IV, while newer APIs and the AndroidKeyStore provider appeared to return randomized IVs in limited testing, and recommends explicitly declaring an IV when appropriate. ### Source excerpt A quick one today. A couple of people I have spoken to recently have been unaware of the need to ensure a random IV is being used when performing AES encryption on Android. What is an IV? In cryptography, an initialization vector (IV) or starting variable (SV)[1] is a fixed-size input to a cryptographic primitive that is typically required to be random or pseudorandom. Randomization is crucial for encryption schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same key does not allow an attacker to infer relationships between segments of the encrypted message. For block ciphers, the use of an IV is described by the modes of operation. Wikipedia The unawareness seems to fall into two camps: I didn't know I needed to use an IV I am using the IV that is generated by the Cipher I didn't know I needed to use an IV Yup! I am using the IV that is generated by the Cipher Potentially an Uh oh! Poking around a little, I can see that on old versions of Android (tested 4.3) the AndroidOpenSSL provider can return an all 0 IV with the below, whereas the same code on 7 will spit out seemingly-random IVs. secret_key_iv.java Using the newer KeyGenParameterSpec APIs and the AndroidKeyStore Provider seems to be fine regarding this issue from the small amount of testing I have done. Enforcing a random IV It may be worth explicitly declaring an IV to avoid the potential of the default one zero-ing out, which from the above depends on the providers implementation in use. This can be as simple as: explicit_iv.java Worth being aware of isRandomizedEncryptionRequired() exists if you want to manually ensure the IV is randomised, otherwise cipher.init will throw if an IV is supplied. Some of the Android examples do now suggest this, but I find it can be easy to forget when looking at other example code. If interested in Android security take a look at doridori/Android-Security-Reference ## Android Security: Welcome To Shell (Permissions) DevFeed: [Android Security: Welcome To Shell (Permissions)]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2016-08-16T00:00:00Z Content type: tutorial Language: en Sources: [SystemDotRun]() Topics: [Android](), [Android Security](), [Security](), [Process](), [Kernel](), [POSIX]() Tags: [adb](), [android](), [android-security](), [kernel](), [posix](), [process](), [security]() ### AI overview This article examines whether a shell started by an Android application has the same permissions as a shell accessed through ADB. It explains that Android process privileges depend on UID, GID, supplementary GIDs, and kernel-enforced resource access, then compares shell processes from ADB and an installed application. ### Source excerpt Does a shell started from an application have the same permissions as a shell started via adb? What a good question! ADB is a shell that you get on a PC with the same permissions as if you were to run a shell/terminal app on the phone itself. I came across this statement on Reddit which went against my intuition and I had a quick look into it. It was important for me so I can understand the difference in potential attack vectors surrounding open shells. I started by flicking through the excellent Android Security Internals: An In-Depth Guide to Android's Security Architecture to get an overview about how process permissions worked on android. Most of the overview is just a condensed version of a few pages of this great book. This post will mostly talk about how this stuff works with low-level kernel permissions work in the OS, as opposed to high-level operations that involve the package manager (pm). A brief summary of the low-level stuff is: Privileges are based upon the processes UID, GID and supplementary GIDs Like all POSIX systems [clarification needed] access to system resources regulated by the kernel (files, sockets etc) is based on the owner and access mode of the resource and the UID & GID of accessing process Some permissions on Android are mapped to GIDs data/etc/platform.xml Other permissions are checked via pm and I'm guessing are not checkable by the process outlined in this post. These GIDs are mapped to AIDs android_filesystem_config.h For applications (quick diversion) the package manager will add the GIDs for the application at install time, for permissions that appear in the platform.xml file, to data/system/packages.list for the applications entry. When a process is forked from the zygote process, as it does for new application processes, the UID and GIDs are set. Kernel and system daemons use these to grant access to resources and functions. Relative shell permissions So, does a shell started from an application have the same permissions as a s ## Gradle: Guide to versions (+Android) DevFeed: [Gradle: Guide to versions (+Android)]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2016-06-03T00:00:00Z Content type: tutorial Language: en Sources: [SystemDotRun]() Topics: [Gradle](), [Android Studio](), [Android](), [Homebrew]() Tags: [android](), [android-studio](), [commands](), [gradle](), [guide](), [installation]() ### AI overview A practical guide to checking and updating core Gradle and Android plugin versions. It recommends using the Gradle Wrapper for deterministic builds, explains installation and updates with Homebrew, and identifies where Android build-tool and plugin release information is documented. ### Source excerpt When using Gradle I always forget where to look to make sure I'm taking advantage of the latest core and android plugin versions for my project. Some of the below can be done via Android Studio but I like knowing how to do stuff without the IDE :) Core Gradle [gradle.org] View latest versions release notes [gradle.org] View docs for older Gradle versions [wikipedia] View list of Gradle versions and release dates You can check the version of Gradle installed on your system with gradle --version. Installation & Updating I use brew and for initial installation use brew install gradle and to update brew update && brew upgrade gradle. Core Gradle Android Wrapper You should always run commands via the Gradle Wrapper (gradlew) so you have deterministic builds, regardless of the Gradle core version that's installed on the current build machine. You can check the wrapper version by running gradlew --version. You can update it by editing the gradle-wrapper.properties distributionUrl or by defining a wrapper task (Recommended as the format of the properties file can change) with task wrapper(type: Wrapper) { gradleVersion = '' } and calling gradle wrapper. Gradle Android Plugin The Gradle Android plugin major.minor version tracks the build tools versioning. [tools.android.com] New Build System Tools Release notes [developer.android.com] Android Studio Release Notes AS Versions match tools [developer.android.com] Android Plugin for Gradle Release Notes Also lists Core Gradle version required for each plugin version This is defined in your build.gradle with classpath 'com.android.tools.build:gradle:' ## Android Architecture: Introducing Pilot DevFeed: [Android Architecture: Introducing Pilot]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-10-01T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Android](), [mvc](), [Dagger]() Tags: [android](), [android-architecture](), [architecture](), [architectures](), [controllers](), [dagger](), [fragments](), [lifecycle](), [mvc](), [mvvm](), [project](), [repo](), [view]() ### AI overview This article introduces Pilot, a work-in-progress abstract application stack for Android. It discusses managing presenter lifecycles, application flow, data scoping, and architectures based on views or a mix of fragments and views, while relating the approach to MVC, MVP, MVVM, and Dagger custom scopes. ### Source excerpt An abstract application stack for Android Motivation There are some common questions that keep popping up on the interwebs around the current collective thought on Android Architecture. Some of these questions are: What approach can I use to handle my Presenters Lifecycle? How can Presenters control the flow of an application? How can I scope data within my application? What architecture could I use to support a View only based architecture (or a mix of Fragments / Views) ? The above questions are not easy ones to address and by no means am I suggesting the below is the only solution to these common issues. I have started using a simple abstract application stack which for the kind of applications I have been developing allows a clean & structured base for them to sit on top of. This post and supporting repo is definitely a work-in-progress but Im hoping it will spark some discussion which can be fed back into the project so it's something that is useful to others also. I have been tempted to not write anything about this until I have answered all the pending questions I have myself but I feel more may be gained by publishing early and often. It is probably worth mentioning that if you are not currently using some kind of Presenter / Controller / distinct view logic abstraction in your application at present you probably will not have come across (or asked yourself) some of these questions. The same goes for Dagger (& Dagger Custom Scopes) and View only view implementations. If you have been playing with some of this stuff you may find the below more applicable. In this post I will briefly expand on the above questions and introduce the project. Preliminaries A Note on terminology Presenters are all the rage in the Android world at present. Some call them Presenters, Controllers, ViewModels, PassiveView etc and they are used as part of MVC, MVP, MVVM (with DataBinding), MVA etc and all these terms overlap and have differnt meanings and implementations depending on w ## Java: Bitshifting bytes DevFeed: [Java: Bitshifting bytes]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-04-29T00:00:00Z Content type: tutorial Language: en Sources: [SystemDotRun]() Topics: [Java](), [Code]() Tags: [code](), [java]() ### AI overview This Java tutorial explains how automatic promotion of byte values to int, combined with signed bytes and bit shifting, can produce unexpected results. It recommends masking with & 0xFF before casting back to byte to preserve the intended low eight bits, especially when emulating unsigned-byte operations or porting code. ### Source excerpt TL;DR When bitshifting a byte use a & 0xFF mask Working at the bit level in Java can be very frustrating. This is for two reasons There are no unsigned number primitives Automatic type promotion is not intuitive! Looking at type promotion, whenever you use a bitwise operator on a byte variable it is automatically promoted to an int. This means you have to write casting code such as byte b = (byte) (b ^ 8); or b ^= 8 which does the former under-the-hood. This is not too bad really. But the pain starts when working with signed numbers together with int promotion. For example ex1.java For bByte we would expect the result to be 0b1111_1001 as the right Arithmetic shift operator >> fills the left bit depending on the left most (sign) bit (which is 1 when negative ala 2's complement) so the result is as expected. However for cByte we would expect the result to be 0b0000_1001 as the right Logical shift operator >>> should fill the left most bit with 0, but we still get -7! Why is this happening? Well due to the auto int promotion (as a result of using any bitwise operator), when the aByte is promoted to an int, the left most bits of that int are all 1s. In binary form this is 0b1111_1111_1111_1111_1111_1111_1001_0000 before the shift 0b0000_1111_1111_1111_1111_1111_1111_1001 after the shift Due to how casting works when casting down the last 8-bits will be copied directly, hence still giving 0b1111_1001. Not very intuitive when you see aByte >>> 4 imho. So how can we perform >>> operations and get the "intuitive" result of 0b0000_1001? Note: This is useful as to be able to do as Java does not have an unsigned byte type the above kind of operation would let you use a java byte in place of another languages unsigned byte type. This can useful when porting code, for example, if you want to replicate a ubyte >> 4 call then the below will be useful. The answer is to mask the bitwise result before casting back down to byte. We can do this with & 0xFF. This works by persevering o ## Android Architecture: Introducing Dynamo DevFeed: [Android Architecture: Introducing Dynamo]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-04-03T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Dynamo](), [Library](), [Development](), [Code]() Tags: [android](), [android-architecture](), [app-architecture](), [asynchronous](), [code](), [dynamo](), [libraries](), [lifecycle]() ### AI overview This introductory post presents Dynamo, a small library and wiki for Android application architecture. It focuses on managing application state and asynchronous code, including their interaction with the Android lifecycle, and aims to decouple UI behavior from core application logic. ### Source excerpt Dynamo has been superseded by Pilot Welcome, welcome. Come in, it looks mighty cold out there. The code is laying heavy across the hills, disorder rules the day and the nights are long. We yearn for a day where the suns shines forth once more. This is post #2 of my very short Android Architecture series (can two be a series?). Post #1 was a primer for this post. It contained A brief outline of the problems when defaulting to stock Android architecture. An overview of common general architectural concepts. This post is really a short intro to a small library + Wiki I have created. This library fills an architectural hole which I see in the Android dev world. There is no unified approach to generic Android app architecture and this creates a vacuum which sucks in well meaning devs and results is messy codebases strewn across the land. It is also my reponse to the many MVP blog posts out there, which have really helped me think about this issue but also I have my own take on. Plus, I feel sorry for new Android devs who are turning up later to the party and are overwhealmed by the Android ecosystem and need to get up to speed quickly on what these issues are before even getting to the point of thinking about potential solutions. Some of the issues addressed by this approach are solved by fantastic existing libraries, but again, I think for a large chunk of devs these can be difficult concepts to grasp and get running with. These are mentioned in the projects wiki for further reading. In my experience at least there are two core ideas around the center of most apps codebases. From the codebases I have seen & inherited both ideas seem to have too few brain cycles spent on them. 1. State Most apps and views are state-based however the spaghetti-level that captures the state logic is generally very high. 2. Asynchronous code Pretty much every app involves some asynchronous code. Pretty much every app allows this to touch the Android lifecycle. This always leads to sadness. ## Android Architecture: MV? DevFeed: [Android Architecture: MV?]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-04-01T00:00:00Z Content type: opinion Language: en Sources: [SystemDotRun]() Topics: [Android](), [Code](), [mvc](), [Development]() Tags: [android](), [app-architecture](), [architecture](), [code](), [mvc]() ### AI overview This article examines how MV* architectural approaches relate to Android development. It argues that placing most application logic in Activities and Fragments can produce code that is difficult to test, read, refactor, reuse, and maintain through configuration changes, and introduces several common Android architecture perspectives. ### Source excerpt How do the MV* ways of thinking relate to Android? Why is this now such a popular way of thinking about Android architecture? The Problem I'm a contractor and I'm often brought on to projects have long since passed their first commit. I feel like I have had a good insight how to the average dev approaches Android app architecture from this, and also from open-source projects, android blog posts, the Android developer site and more. One thing that strikes me about most of the code I see is that there is not much of a notion of a clean, overarching application architecture. By this I mean that people seem genuinely happy to shoehorn their code into Activitys & Fragments with the occasional class named something like MyCrazyController. Why is this an issue? The problem with this is that it results in hard to test code hard to read code hard to refactor code hard to reuse code hard to handle-config changes code hard to write asynchronous code hard to not create loads of edge-case code (i.e. its buggy) hard to hand-over code Its an easy thing to fall into doing because ~99% of all Android examples are written in this way It sort of works most of the time there are framework classes (i.e. Loaders) and librarys (i.e. RoboSpice) around now to work around some of the issues that manifest from using this stock approach. While I have used these approaches in the past I find they can make a code base more complicated than it needs to be. People have got used to hearing that "Android is hard to test" or "just lock it to portrait" and "restart / reconnect to the web service call on rotation" and just think "well thats how it is" I admit, I would also include my past-self into this group, which is why I am here, attempting to atone for my coding sins and mine and others unknowingly devout following of the book of anti-patterns. How has this come to be? MV?, who's in control? I believe a big part of this is that not much thought has gone into the actual generic app architecture app ## Android Testing: A Rough Guide DevFeed: [Android Testing: A Rough Guide]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-02-27T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Android](), [Testing](), [Test-driven development](), [Development](), [Tooling](), [APK](), [Emulator](), [test]() Tags: [android](), [android-testing](), [apk](), [architecture](), [automated](), [emulator](), [guide](), [junit](), [jvm](), [tdd](), [testing]() ### AI overview A rough guide to the author's approaches to automated testing on Android, covering testing strategies, TDD, test tooling, device and emulator tests, test APKs, JUnit 4, and JVM tests. The article argues that writing tests encourages developers to think about software architecture. ### Source excerpt Do you have a go-to approach when writing automated tests on Android? Every project I work on has a different testing strategy, and each time I learn something new along the way. This post is a rough outline of my approaches to automated testing on Android (including past, present & future). The post serves 3 purposes: Writing stuff down always helps me think about what Im actually doing and if it makes sense. For others who have less experience writing tests; this will hopefully offer some ideas of paths to explore. For others with more experience; you can give me some hints of what I'm missing! Im not going to talk much (or at all) about how you use the tools, otherwise this post would be huge. This is more on a jumping off point for further exploration :) It there is something you want more info on, investigate it, write a post about it, and I can link to it here! Why test? Automated testing and TDD is one of those things in software development that some love and some hate (actually, what isn't like that in dev?!). Regardless of what side of the fence your on there is one thing thats hard to argue against, writing tests forces you to think about your software architecture. I think actually this is main thing I like about it, but probably not its biggest advantage. Testing on Android In the past I have felt like we were short-changed in the Android world when it comes to testing, compared to other languages or frameworks that have been designed from the start to ease the path of testing (i.e. RoR). But the tools are improving all the time which is fantastic. Edit: After starting this I listened to Episode 1 of the new Fragmented podcast, which is interesting as they echo my thoughts here exactly! Tooling Test Frameworks There are a number of ways to run your tests, the simplest first choice to me seems to run them on a device or emulator via a test apk (see below for emulator choices) rather than using something like Roboelectic (which lots of people do like and