Rob Napier recently gave a gentle introduction to functional programming in Swift. Even for experienced functional programmers it’s a short but enjoyable talk to watch. The talk was trending on Hacker News a few weeks back and there was some interesting discussion around functional code not always being easier to read than its imperative counterpart, albeit usually being shorter.
Here’s a screen I was recently working on for an app at work:
It’s built with a Fragment containing a ViewPager. Each page in the ViewPager is served by a FragmentPagerAdapter. Pretty straight forward stuff.
On first launch it works as expected, but if the enclosing Activity is destroyed, no pages get recreated by the FragmentPagerAdapter.
Since Google introduced the support annotations library, there’s been an increase in the application of the
@NonNull annotations in APIs. It’s helpful in languages such as Java where optional values are not first class citizens. Static analyzers can infer at compile time if an object has the possibility of being null when passed to (or returned from) a method.
While the benefits of these annotations can certainly be helpful, they may also hinder users of an API. A great case in point would be that of the
findViewById method in Android’s
There are a handful of reasons why you’d want to load in a resource file for a test:
- Input (or output) data is large and complex
- Input (or output) data is not easily mockable, such as a
- Configuration data is preferably externalized
One option would be to place your resources in your app’s
/assets directory. This requires instrumenting your tests so that you can access the resources through the app’s
Context. This can be undesirable for two reasons: