Guillermo Orellana

Maintaining and restoring window arrangements in MacOS

Wed, 18 Dec 2019 12:37:00 +0000

Frustrated about your MacOS forgetting all your beautiful screen arrangements? Dealing with the neck pain of so much head tilting searching for where the screen settings are? This page is for you.

Install Homebrew

Go to https://brew.sh/ and follow instructions

Install displayplacer

Instructions from the GitHub repo are

brew tap jakehilborn/jakehilborn && brew install displayplacer

Copy your layout configuration

After installing the tool, execute displayplacer list in a terminal. Copy the output, that will look something like:

displayplacer "id:0BF37642-C36D-6E90-01B5-9C8D747DA7F5 res:2560x1440 scaling:off origin:(0,0) degree:0" "id:E8102887-70FC-9A98-8839-157ACFB40B52 res:1440x2560 scaling:off origin:(-1440,-404) degree:90"

Create a Quick Action in Automator

Open Automator, and create a new Quick Action. If you can’t find Automator, you can do Cmd+Space and type its name.

Add a `Run Shell Script` action

Paste the output of the layout configuration step

Put an absolute path to displayplacer if you have issues with the shell path (if it complains about not finding the displayplacer executable)

If you need to know the full path to displayplacer, execute which displayplacer.

Save the Quick Action and give it a memorable name

Memorable as in you will have to find it later in a different place.

Create a shortcut

Open Shortcut settings

It’s in System Preferences > Keyboard > Shortcuts

Find your saved Quick Action

It usually is right at the end of the list, so scroll away.

Assign a key binding to it

Make sure it’s not one that is already defined in the system (you can disable it if it is) or one that you would use regularly on your day-to-day.

I’ve used Cmd+Alt+Shift+R but your mileage may vary.

Happy rotating

Try it out next time your screens go bonkers and if it saved you any time say thanks!

Your own personal Heroku

Thu, 14 Jun 2018 12:37:00 +0000

I’ve just finished doing a talk at the Milan Kotlin Community Conference about a recent pet project of mine: Keynotedex.

Keynotedex (code here) is a project that I created to experiment with Kotlin multiplatform in platforms I am not that confident with, such as web and backend.

One of the most frequently asked questions was “how do you deploy your server code?”. I get it, it is all nice and beautiful in the examples, but they never go over the “production” case.

Finding a home for our backend code

At the end of the day, your Kotlin server code is just a JAR file. You could use the war Gradle plugin to generate a standard container you could drop in a server such as Apache Tomcat. But that’s scary, or at least it seems like overly complicated for a pet project.

Heroku is a PaaS that lets you deploy apps with git commands. Although more popular within the JavaScript and Ruby communities, they fully support JVM as well. Deploying your code by just doing:

$ git push herkou master

It’s priceless. Actually no, there are some limitations on what you can get from Heroku for free. Your service will have some hours of runtime allowed, then capped unless you switch to the paid tier. That’s fair enough, but what if you want the flexibility of deploying from git commands, and you already have a spare server from, say, a weird Black Friday shopping rampage? (True story, by the way)

Enter Dokku and Heroku(ish)

Honouring the Depeche Mode reference at the title, somebody already had figured out that question. You can install your own version of Heroku, in your own servers, and use that great workflow.

There are two tools that take part in that: herokuish emulates Heroku build and runtime tasks in containers, and Dokku manages such containers using Docker. And it’s lightweight. They claim to be “The smallest PaaS implementation you’ve ever seen”.

That’s a lot of DevOps jargon, show me how to do it

Nobody is going to be able to teach you how to get Dokku up better than their own docs (and those won’t go out of date as quick as this article).

Preparing our code to run on Heroku(ish)

Even if I did go for Dokku, everything here applies to a Heroku deployment as well. I will be basing my examples on code written using Ktor. Other frameworks for some of the techniques may work, but your mileage may vary.

Remember what I mentioned at the beginning, our code is bundled into just a JAR file. In theory, we could just run java -jar server.jar. However, doing that will point out one thing: regular JAR files don’t really carry their dependencies over.

Stuffing all your deps inside a JAR

In order for our dependencies to be in the classpath at runtime, we need to carry them over and create what is known as a fat JAR or uber JAR. You will understand the naming when you check the size of that new JAR. There’s a Gradle plugin that will do it for you, called shadow.

Applying it to our backend module will create new tasks that will take the outcome of our jar task and fill it up with the classes from our dependencies. If you run ./gradlew server:shadowJar you will find in your build/libs a new JAR file with the suffix -all. That’s the one!

There are lots of things you can customise in this process. If you are up for it, the best way is to create a task of type ShadowJar, the same way you would create one of type Jar.

As an example, this is the task I created to have a release style shadow JAR, with the purpose of adding some extra sources not present in the regular JAR.

task releaseJar(type: ShadowJar) {
    manifest {
        attributes "Main-Class": "keynotedex.backend.ServerKt"
    }
    classifier = 'release'
    from([sourceSets.release.output, sourceSets.main.output])
    configurations = [project.configurations.compile]
}

Since had a new task created, I had to define where my main class is. This way, the JAR file can be run from the terminal. This is not necessary if you are just using the output of the shadowJar task, it will pick whatever the application plugin says.

Note that the property classifier is what will be appended to your JAR file name, so in this case a file with the name backend-0.0.1-release.jar will be generated. Now, take a moment to test that, when running the JAR file, your server spins up.

IKEA instructions, but for your PaaS

Now we are able to build a shadow JAR that contains our dependencies, but is our service able to do so? Unless we want to commit our build output (please don’t), we will have to tell our service how to reach that goal state.

According to the official Heroku docs (and Herokuish follows them as expected), when it detects a Gradle project, Heroku will attempt invoke one command:

$ ./gradlew stage

We can take advantage of that and use that hook to trigger the whole shadow JAR process. You do not need to write a fully fledged shiny new task, you can just make it depend on your backend tasks like this:

task stage() {
    group "distribution"
    dependsOn(':backend:shadowJar')
}

Remember, this task must be defined inside the root Gradle project for it to work.

How do you turn this on

Now that the service knows how to build it, we have to tell it how to run it. In our case, we create a file at the root of our repository called Procfile, which contains all the services we define and how to run them. Mine looks like this, but remember my JAR classifier is release:

web: java -Dserver.port=$PORT $JAVA_OPTS -jar backend/build/libs/*-release.jar

$PORT and $JAVA_OPTS will be defined by the service at run time, so make sure to pass those on and use them in your code, otherwise your backend may not be able to reach the internet.

Ship it! :shipit:

Write the aforementioned command, play your favourite tune, sit back, relax.

$ git push dokku master

Here is a little eye candy showing how it looks like to deploy Keynotedex:

Bonus stage: easy HTTPS with Letsencrypt

Until now, both Heroku and Herokuish environments are able to do what I describe, but this one is exclusive of Dokku.

HTTPS is very important, I am not even going to discuss it here. And Let’s Encrypt has enabled many people to obtain what used to be an expensive luxury: SSL certificates.

Fear not, you can use dokku-letsencrypt: a dokku plugin for automagically obtaining SSL certificates for your domain, and enabling HTTPS. And it is as easy as deploying a new version. This is how I renew my certificate in Keynotedex:

$ dokku letsencrypt keynotedex

Final thoughts

The Heroku style of deployment has made publishing a backend service as easy as deploying an APK into an Android phone. This is great because makes backend less scary and confusing.

In addition, Dokku allows you to have full control over the system, and use it in environments where you would not be allowed to put things into a public cloud.

This should not be thought as exclusive for human-triggered deployments, as this simplification will surely make systems for deploy-on-merge way simpler.

Thanks to Jose A. Corbacho and Pablo Guardiola for taking the time to review this article.

Avoiding the clean boilerplate: Welcome Project Lombok

Mon, 17 Oct 2016 13:00:40 +0000

This blogpost is from 2016. If you are reading this today, there are way better solutions than Lombok, for instance Kotlin

Looks like nowadays, clean is the trend. Clean eating, clean lifting, clean architecture…

Let’s have a look at the list of topics for the latest DroidCon in Spain:

Notice that there is a check mark for every talk mentioning or speaking about Clean Architecture. And opposite to what it might look like, the MAD in the name is not because they are MAD about Clean Architecture, but because it took place in Madrid. It is everything but a new concept, but seems to have drawn a lot of attention in the Android community during the past few months.

With such a huge resonation in the community, it must be our NextSilverBullet™, let us make all our code life and things clean! Layers of abstraction, pluggable, replaceable and testable components, immutable data models, one data model per layer…

So after x time refactoring or rewriting (where x approaches infinity), we end up with 10 times more boilerplate than actual code. How did we get here?

The pain

Java is a very flexible language. Some of the concepts in Clean Architecture introduce a lot of restrictions and requirements. Such restrictions and requirements need code to be expressed in Java. Other languages may not need so much code since they allow you (or require you) to be as restrictive (like, Kotlin and immutability), but if it’s Java what you have in your toolset, for instance to achieve immutability you need to define all args constructors, setters and builders to spice it up. Stuck with boilerplate you are. Or are you?

Meet Project Lombok

Project Lombok is magic made code. Or code that makes magic. Or… Well, it’s actually an annotation processor that generates code, but instead of creating derivate clases we have to guess (I am looking at you, Dagger2), it injects the generated code in our class. Told you, Magic!

How does it achieve its magic properties? Well, Lombok is not your typical annotation processor. Its annotations are processed at development time, injecting code so it’s immediately available for the developer. This requires some sort of collaboration from the IDE though.

Project Lombok and Android

In order to use it in you Android project, head to the project download webpage and get the coordinates to the latest version. If you are using the Gradle apt plugin, you might need to add its entry as well. It might look like this:

provided "org.projectlombok:lombok:1.12.6" // or latest version
apt "org.projectlombok:lombok:1.12.6" // only if using gradle-apt

Project Lombok needs little to no configuration, but there are some special cases we need to consider when using it in Android. In order to customise the behaviour of Lombok, we can put a file named lombok.config in one of the roots of our project. I usually have it at the root of the module or modules that actually make use of Lombok, since we might choose not to use it in all of them.

In order to comfortably develop with it, you will want to add a plugin that supports Lombok generation at dev time. In Android Studio, this can be done installing the Lombok plugin, which is available from the plugins menu.

Generating way too many things

java.beans.ConstructorProperties

Android lacks of the beans package (thankfully), so when you try to use one of the constructor family annotations, you will get a compile time error similar to this one:

Error:(9, 1) error: cannot find symbol class ConstructorProperties

In order to disable such annotations from generating, just add this line to your lombok.config:

lombok.anyConstructor.suppressConstructorProperties = true

javax.annotation.Generated

Yes, there is an annotation to say that something was generated by an annotation processor (Inception sound). Of course, there is a reason for this: Annotation processors are applied in rounds, so the output of one annotation processor may be processed by other annotation processors or even by itself on further rounds! (more Inception sound). In order to avoid going too many levels deep, generated code is annotated so the processors can distinguish it and decide wether process it or not.

The problem is, Android does not bundle this one either. You can go for the easy solution, which is not generating them at all:

lombok.addGeneratedAnnotation = false

Or the probably correct one, which is adding a dependency that contains this annotation to your build. Don’t worry, it’s retention is SOURCE, which means it won’t go to your class files (and eventually your DEX files).

provided "javax.annotation:jsr250-api:1.0"

Comparison

Probably my favourite comparison to do is the use of the @Data annotation. Consider this example taken from the Lombok project page:

@Value 
public class ValueExample {
    String name;
    int age;
    double score;
    protected String[] tags;
}

Just one annotation, @Value, will trigger:

Marking the class final
Like the @ToString annotation, generating a toString() with all the fields present
Like the @EqualsAndHashCode annotation, generating valid equals() and hashCode() methods
Like the @AllArgsConstructor annotation, generating a constructor with all the fields as arguments
Like the @Getter annotation, generating a getter for each field (the @Getter annotation would be required at each field otherwise)

So it’s like a super-annotation (or a shorthand for all the above). This would generate the following Java code. 70 lines of code generated by Lombok after writing just 7 lines. That’s 10 times the amount of code!

Alternatives

Is Lombok all what is out there? Is this a crazy isolated idea? Not really, there are many other options. Let’s explore two: first, a more moderated approach to code generation, without injection. Second, if you would rather turn it up to 11, a way to inject code for even more things.

AutoValue

@AutoValue
abstract class Animal {
  static Animal create(String name, int numberOfLegs) {
    return new AutoValue_Animal(name, numberOfLegs);
  }

  abstract String name();
  abstract int numberOfLegs();
}

If you want a more traditional and less hacky experience, Google’s AutoValue does that for you. However, since it does less magic tricks, it does not feel nearly as easy to use. You need to declare your classes abstract and your values as abstract methods. It still allows you to reference the original class when instantiating, but you will work with a derived type.

Android Annotations

@Fullscreen
@EActivity(R.layout.bookmarks)
@WindowFeature(Window.FEATURE_NO_TITLE)
public class BookmarksToClipboardActivity extends Activity {
  @ViewById
  ListView bookmarkList;
  @ViewById
  EditText search;
  @App
  BookmarkApplication application;
  @SystemService
  ClipboardManager clipboardManager;
  
  @Click({R.id.updateBookmarksButton1, R.id.updateBookmarksButton2})
  void updateBookmarksClicked() {
    //[...]
  }
}

If code being injected is not a scary idea for you, but rather an exciting one, then why not inject all the things? Taking the concept of Project Lombok to the next level, with Android Annotations you can do things like @SystemService to inject services from the current context. A bit too much for me, but always worth the try.

It even comes with a REST client that reminds me a lot of Retrofit:

@Rest("http://www.bookmarks.com")
public interface BookmarkClient {
  @Get("/bookmarks/{userId}?search={search}")
  Bookmarks getBookmarks(@Path String search, @Path String userId);
}

Conclusion

Project Lombok is a very powerful tool, and like all powerful tools it can get out of hands pretty quickly. But if you keep its usage down to a reasonable level, it can help you a lot to go through the most tedious parts of elaborated architectures: boilerplate code.

And if at some point you decide to get rid of Lombok, you can rest assured, they provide a system to de-Lombok your code and make the generated code persist instead of the annotations.

I am personally using this tool among others to help me in my rewrite of Travis for Android, more on that task to come soon!

RxJava - FlatMap tricks

Tue, 27 Sep 2016 08:00:40 +0000

Quick one: Have you ever had to convert one layer model to the next one, and iterate through all the child elements to convert them as well? Not saying there is something wrong with that, but with a bit of RxJava magic we can make it look so much cooler.

Say you have your VeryCleanArchitecture™ data source

@NonNull
@Override
public Single<List<InmojiGroup>> get() {
    final List<InmojiCampaignCategory> stuff = StuffSDK.getStuff();
    final List<InmojiGroup> networkStuff = new ArrayList<>();
    for (InmojiCampaignCategory stuffCategory : stuff) {
        List<InmojiItem> items = new ArrayList<>();
        for (StuffItem stuffCategoryItem : stuffCategory.getStuffItems()) {
            items.add(NetworkStuffItem.from(stuffCategoryItem));
        }
        networkStuff.add(new NetworkStuffGroup(stuffCategory.getTitle(), 
                                                  items));
    }
    return Single.just(networkStuff);
}

Nice and easy. But it is not reactive enough. With a bit of salt and pepper, we can make it look VeryCleanMuchReactiveArchitecture™ worthy. However, notice that we need to access to some property of the original parent to compose our NetworkStuffGroup. A simple flatMap won’t do it, since we would only have access to the child items.

But what about doing like this:

@NonNull
@Override
public Single<List<NetworkStuffGroup>> get() {
    return Observable.from(StuffSDK.getStuff())
        .flatMap(
            stuffCategory ->
                Observable.from(stuffCategory.getStuffItems())
                    .map(NetworkStuffItem::from)
                    .toList(),
            (stuffCategory, networkStuffItems) 
                -> new NetworkStuffGroup(
                    stuffCategory.getTitle(), 
                    networkStuffItems)
        )
        .toList()
        .toSingle();
}

What the heck was that? Calling flatMap with two arguments? Well, it is not straightforward, but one of the flatMap overloads has a resultSelector as a second parameter.

We can use as resultSelector a function that takes the item before the flatMap and the grouped collection after the flatmap. This way we can easily create our network model group, without any confusing usage of Pair<T,U>.

And that’s all folks! May your code be reactive and your Observable never randomly unsubscribe.

How to convince your PM into refactoring tests

Tue, 16 Aug 2016 11:00:40 +0000

I know, the two words your (Product Owner|Product Manager|Project Manager) hates the most, tests and refactoring together! Those don’t burn points in the chart! Am I trying to make them have a heart attack? Well, not really. It all depends on how you pitch the idea to them.

The case

For instance, if we take a test file with this header:

It is recognisable that this is an Android Instrumentation Test. Nothing wrong with them, but I believe RxJava has nothing to do with the Android framework itself, so why is this an instrumentation test? I can think about many reasons. Legacy structure, old build tools, inertia… But we can do better now.

What about this other header:

You can quickly spot this is the same class, but is now running as a pure JUnit test. Why even bother doing it?

Speed

One of our current main issues in the Badoo Android team is our build speed (see more on that in our AMA follow-up blog post). Android instrumentation tests definitely do not help with it.

The exact same test cases (8 to be exact) run in 22% of the time when done as a pure JUnit test. Most of this drop comes from the required instrumentation steps such as dexing, installing both the application and the instrumentation APK and bootstrapping them. This causes a significant overhead. It is true that this overhead does not grow too much with the number of test files and cases, but think about how many times you run just a handful test cases to ensure you don’t break something while modifying it.

I agree that 25 seconds is still far away from perfect, but in our huge Badoo project that number is bliss!

Temptation free

Your unit tests must not interact with the Android framework. If you can’t mock it, then you have a design problem. But this same PM that you are trying to convince needs this new feature super quick, and oh the tests are failing, and it would be so easy to just pass some Context around… Nope, not today.

It’s not that difficult

Providing it is already a decoupled from Android framework test, it only takes you moving it from src/androidTest to src/test and adding a few @RunWith, @Test, @Before and @BeforeClass annotations. How long would it take you, half a minute? Even if it took a couple of minutes, the second time you ran this test you would already have a benefit out of it.

Let’s do the math

Until now, it’s all benefits for the dev team, but maybe your (PO|PM|PM) won’t see that just yet. Let’s add some numbers. Say you have 200 instrumentation tests. Out of those, 100 are easily converted to pure JUnit tests. Say they take 2 minutes to run, and let’s be conservative and say you save 50% of the time, that’s 1 minute.

What value adds 1 minute? If the tests are ran 16 times a day (say once every half an hour in an ideal 8 hour work day), that’s 16 minutes per developer per day. 10 devs in your team, 2 week long sprints (thus 10 working days), it adds up to 1600 minutes or 26.6 hours. That’s more than 3 of those developer days that (PO|PM|PM)s love so much to talk about. How about that!

Wrap up

There is no lost cause if there is data backing it up. Numbers don’t lie - although they can be presented in very suggestive ways…

Of course, your mileage may vary, and in this example numbers are totally made up, but is not an unreasonable reasoning. next time you want to justify something to management, just tell them what they want to hear (backed up with actual data 😉)

Integrating React Native in an existing application

Tue, 05 Jul 2016 21:37:40 +0000

Updated 11/04/2017: Added some of the API changes and updated the React Native version used in the article

As I promised by the end of my previous article, “Writing an Android component for React Native”, here is the second approach for React Native and native Android code to live together ~~in peace and harmony~~ and not blow apart. Since this is a follow-up to the previous article, I will jump straight into matter. If you need a brief introduction on React Native and how it’s organised on Android side, please visit the aforementioned link.

Getting it to work

After following the docs sample, you copy the snippets, run the commands… Et Voilá! Well… Not really. Actually the docs do not reflect the current state of the API, which is v0.42.3 when I ~wrote~ updated this paragraph. I will try to expose my issues and the ways I worked around them, but YMMV.

An slightly updated version of the activity showing the React Native content would look like this:

public class ReactActivity extends AppCompatActivity 
    implements DefaultHardwareBackBtnHandler {

    private ReactRootView mReactRootView;
    private ReactInstanceManager mReactInstanceManager;
    private LifecycleState mLifecycleState 
        = LifecycleState.BEFORE_RESUME;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mReactRootView = new ReactRootView(this);
        mReactInstanceManager = ReactInstanceManager.builder()
            .setApplication(getApplication())
            .setBundleAssetName("index.android.bundle")
            .setJSMainModuleName("index.android")
            .addPackage(new MainReactPackage())
            .setUseDeveloperSupport(BuildConfig.DEBUG)
            .setInitialLifecycleState(mLifecycleState)
            .build();
        mReactRootView.startReactApplication(mReactInstanceManager, 
            "ReactSample", null);

        setContentView(mReactRootView);
    }

    @Override
    protected void onPause() {
        super.onPause();

        mLifecycleState = LifecycleState.BEFORE_RESUME;

        if (mReactInstanceManager != null) {
            mReactInstanceManager.onHostPause();
        }
    }

    @Override
    protected void onResume() {
        super.onResume();

        mLifecycleState = LifecycleState.RESUMED;

        if (mReactInstanceManager != null) {
            mReactInstanceManager.onHostResume(this, this);
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();

        mReactRootView.unmountReactApplication();
        mReactRootView = null;

        if (mReactInstanceManager != null) {
            mReactInstanceManager.destroy();
        }
    }

    @Override
    public void onActivityResult(int requestCode, int resultCode, 
                                 Intent data) {
        if (mReactInstanceManager != null) {
            mReactInstanceManager.onActivityResult(this, requestCode, 
                resultCode, data);
        }
    }

    @Override
    public void onBackPressed() {
        if (mReactInstanceManager != null) {
            mReactInstanceManager.onBackPressed();
        }
        else {
            super.onBackPressed();
        }
    }

    @Override
    public void invokeDefaultOnBackPressed() {
        super.onBackPressed();
    }
}

The snippets for index.android.js and package.json seem fine for now at least 😎

So you try to run it but…

Troubleshooting time

These are the problems I found, but as always, YMMV.

java.lang.UnsatisfiedLinkError: could find DSO to load: libreactnativejni.so

Uh Oh! This sounds scary! What happened here? Well, I decided to test it on a Samsung Galaxy S7 (running Marshmallow, that also will be important in a second or two)… Which happens to be a 64 bit phone. And React Native does not provide a 64bit version of its binary. Usually Android would do a fallback, but this does not happen if you have a 64bit dependency in theory, but in practice I found it happening in a blank modern project.

Solution

To avoid this, we will have to use some deprecated API in the gradle plugin in order to tell it to build exclusively for non-64-bit targets.

ndk {
    abiFilters "armeabi-v7a", "x86"
}

Did I mention it’s a deprecated API? Android Gradle Plugin will not like it. Just do as the warning says and add android.useDeprecatedNdk=true in your local gradle.properties.

Better solution

There is a better (and not deprecated) way of doing this:

packagingOptions {
    exclude '/lib/mips64/**'
    exclude '/lib/arm64-v8a/**'
    exclude '/lib/x86_64/**'
}

This way you ensure you get rid of the unsupported ABIs, instead of explicitly supporting a few.

So you hit the “Run” button again and…

BadTokenException: Unable to add window – permission denied for this window type

One very cool thing about developing in React Native is that you get to see the exceptions overlaid on top of your app if you are in debug mode.

One very cool thing about Android Marshmallow is its new permission system, which allows you to take the power back and have a granular control on what you allow your app to do or not.

One very not cool thing about our empty app is that we do not request permission to draw over apps, but React Native will attempt to use it anyway, resulting on this beautiful stacktrace.

Solution

A short snippet like this one, carefully placed in onCreate, will quickly ease your pain and show the app overlay permissions dialog instead of randomly crashing each time your app needs for it. You will still have to scroll through the whole list of apps that have that permission and manually enable our lovely React Native one by hand, but remember, this is only for debugging. Production apps do not require this permission.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    if (!Settings.canDrawOverlays(this)) {
        Intent serviceIntent = new Intent(
            Settings.ACTION_MANAGE_OVERLAY_PERMISSION);
        startActivity(serviceIntent);
    }
}

Module 0 is not a registered callable module

This one was especially frustrating to get, since every piece of advice I could find was pointing out to an outdated React Native version. But that could not be! I was using the highly discouraged by lint little + at the end of my Maven coordinates…

compile "com.facebook.react:react-native:+"  // From node_modules

So then I tried to change it to match the version I stated in my package.json file, but hey, this is interesting!

Digging a bit deeper, found out that the plus coordinates were pulling an outdated artefact from Maven Central. Digging even deeper, I found out my local Maven repo to be wrong.

Solution

Change this

maven {
    url "$projectDir/node_modules/react-native/android"
}

To this

maven {
    url "$projectRoot/node_modules/react-native/android"
}

Since $projectDir is referencing the app/ subdirectory. D’oh! 🙈

“This must be it” you naively think. But what happens if you try to open the debug menu?

android.content.ActivityNotFoundException

So, if you are debugging in a real device and not bundling the JS file, you can shake the phone in order to access the debug menu and…

Seriously? AGH!

Solution

Throw this into your <application> tag, as our friendly exception suggests. Yep, as simple as that.

<activity 
    android:name="com.facebook.react.devsupport.DevSettingsActivity" />

Result and conclusions

After all these bumps and efforts, we finally got an Activity to launch. Phew! What a long way! It was definitely not a bed of roses, and some issues did not appear to have an obvious fix after a quick Google search - but hey, maybe that’s just me being bad 🙈

And this is not the end of the road. You will still have to integrate the React Native toolchain into your build process (there is a nice Gradle plugin helping with that I believe) which adds complexity and build time.

On the other hand, is a fair enough way of experimenting on an already existing application without taking the risks that a complete rewrite brings.

But this was too simple, what about interactions between both sides? I guess I already have topic for the next React Native themed article… 🤔

As always, code available in GitHub.

Writing an Android component for React Native

Sun, 12 Jun 2016 15:37:40 +0000

(Updated 13/04/2017: Bumped to React Native 0.42.3 and updated code)

One of the cool things I like from working at Badoo (we are hiring!), is that we are free to propose, test and promote new or different techniques, technologies and libraries. React Native has been the buzzword for a while now, but it has recently gained our attention.

Main concerns that came to our mind were the size of the existing codebase (let’s say, sizeable), our highly customised classes to fit our needs and easiness of integration. I decided to test the middle one, and try to write a custom Android component to use in React Native.

React Native

Probably almost everybody has already heard about React Native, but if you have not, TLDR: it makes use of JavaScript and React but builds a native UI thanks to some clever bridge techniques.

You can find all about it in the project page.

If you generate a demo project by invoking react-native init, you will get a working skeleton, which is the one I will base the post on.

Let’s attempt to extend it by adding a simple ProgressBar. This is already implemented as part of the standard React Native distribution, but will serve us as an easy sample.

Android side

Extensions to the existing bindings are made by implementing the ReactPackage class. It can be done in three different ways:

1. Native Modules

They provide an inteface for JavaScript code to call native Java methods. For instance, exposing the Toast API as done in the documentation examples.

C++ native modules are provided in a different way, so they can be fully cross-platform.

2. JavaScript Modules

Basically the opposite way around: When you call on a method of a class implementing this interface, the equivalent will be called on the JavaScript realm.

3. ViewManagers

Native views are provided through implementations of the ViewManager class, responsible of instantianting and updating views of a given type. This is the one we are interested in for now.

Since we are only setting up a native view component, we will need to go from the ViewManager all the way up through several layers.

The ViewManager

All ViewManager instances need to report two things: a name to be mapped to a React class, and a way to create an instance of the view they manage. For our ProgressBar example, this is quite easy.

public class ProgressBarViewManager
        extends SimpleViewManager<ProgressBar> {

    public static final String REACT_CLASS = "ProgressBar";

    @Override
    public String getName() {
        return REACT_CLASS;
    }

    @Override
    protected ProgressBar createViewInstance(
            ThemedReactContext reactContext) {
        return new ProgressBar(reactContext);
    }
}

Here, ThemedReactContext is just a wrapper on top of the Android Context we all know (and perhaps hate).

With this done, React Native is able to instantiate a ProgressBar each time it finds the JSX tag for it.

The Package

At the package level, we do not need to return anything but our brand new ViewManager

@Override
public List<ViewManager> createViewManagers(
        ReactApplicationContext reactContext) {
    return Collections.<ViewManager>singletonList(
            new ProgressBarViewManager()
    );
}

The rest of methods can return empty collections safely for now, since we do not need anything from them.

The entrypoints: ReactNativeHost

The boilerplate output of react-native init generates a subclass of ReactApplication (generally MainApplication). This wires the native Android calls down to the library. We need to add the new package to the list of packages reported to the JavaScript side, and we are more than done with Java world. This is done in the getReactNativeHost() method, but we usually declare a field for it:

ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
    @Override
    public boolean getUseDeveloperSupport() {
        return BuildConfig.DEBUG;
    }

    @Override
    protected List<ReactPackage> getPackages() {
        return Arrays.<ReactPackage>asList(
            new MainReactPackage(),
            new ProgressBarPackage()
        );
    }
};

JavaScript (React) side

This step is quite simple, since most of it is handled by the React and React Native code. The only thing left for us to do is to describe the propTypes and export the module.

'use strict';
import { 
  NativeModules, 
  requireNativeComponent, 
  View 
} from 'react-native';

var iface = {
  name: 'ProgressBar',
  propTypes: {
    ...View.propTypes // include the default view properties
  },
};

var ProgressBar = requireNativeComponent('ProgressBar', iface);

export default ProgressBar;

You might be wondering what are those default view properties. Since we inherited SimpleViewManager (which extends BaseViewManager) when creating our own ViewManager, we can take advantage of that to have all the basic mappings from CSS to View properties solved for us. Those include properties such as opacity, backgroundColor and flex. Full list available here.

What if we want to expose our own? Well…

Exposing view properties

In the Java side, we need to create our setters in the ViewManager implementation and annotate them with @ReactProp. There we note the name of the property coming from JSX world, and optionally we can define a default value.

@ReactProp(name = "progress", defaultInt = 0)
public void setProgress(ProgressBar view, int progress) {
    view.setProgress(progress);
}

@ReactProp(name = "indeterminate",
        defaultBoolean = false)
public void setIndeterminate(ProgressBar view,
                             boolean indeterminate) {
    view.setIndeterminate(indeterminate);
}

This setter will be called every time the property of our React component is updated. In case of the property being removed, then the default value is used.

Then, we need to add it to the React Native interface. Back in the js file, at our module’s iface we should describe the properties we exposed in the ViewManager, both with name and type.

var iface = {
  // ...
  propTypes: {
    progress: PropTypes.number,
    indeterminate: PropTypes.bool,
  },
  // ...
};

This way, both native and React sides will speak in the same terms. In the end, our module’s JS file would look something like this:

'use strict';

import { PropTypes } from 'react';
import { 
  NativeModules, 
  requireNativeComponent, 
  View 
} from 'react-native';

var iface = {
  name: 'ProgressBar',
  propTypes: {
    progress: PropTypes.number,
    indeterminate: PropTypes.bool,
    ...View.propTypes // include the default view properties
  },
};

var ProgressBar = requireNativeComponent('ProgressBar', iface);

export default ProgressBar;

All together

Kickstart the react-native server, deploy the APK to your favourite emulator or real device, and if nothing is missing the million gear machine will produce something that looks more or less like this.

Aftermath

React Native, more than a year after its public release (and not even one after the Android release), is in a way more mature state than the last time I attempted anything on it. You can have a working boilerplate project with one command. Docs are very helpful and community content is great.

However, it still feels very cumbersome to integrate it with complex modules.

There is, nevertheless, an alternative approach. Instead of having a brand new React Native application adopt native components, there is the possibility of doing the complete opposite - having a mature production application integrate one simple React Native component.

From reading the docs, it looks more complicated than it sounds, and I have some concerns about the build process - speed and reliability. But that’s food for another thought, and most likely another post. Stay tuned!

Links

GitHub repo with the final code

#YAGIOR - Yet Another Google I/O Recap

Thu, 02 Jun 2016 22:38:06 +0000

TL;DR: It was my first time in Google I/O, my first time in the Bay Area, my first time in California, my first time in the US… And I came back with a very different opinion on all of them.

The long version

I am writing a very late recap. I could blame it to the fact that I am lazy and Spanish, but the ones who know me well would point out that’s not usually an obstacle for my punctuality. It is a late one, because I have had experienced many things and have had a lot to assimilate. But let’s do it one part at the time, shall we?

Google I/O: The conference festival

Yes. The festival. If it looks like a festival, smells like a festival, tastes like a festival, you get sunburnt like in a festival… It is a festival, isn’t it? FestivalTyping™ at its finest!

It was hard to get into the sessions. Places were limited, so you had to queue. People queueing were kissed by a quite strong californian sun. So people got sunburnt. And angry, but mostly sunburnt.

Don’t get me wrong, I loved the concept. I also do not think Google was unprepared or careless about it. They could have transmitted the message a bit better, provided a bit more of shade… But it was very clear it was going to be a festival. And festivals are hard to manage. Not NP-hard, but sure it’s right about there.

On the other hand, my opinion is that the last things that matter in a big event such as Google I/O are the actual sessions. It’s 2016 people. Most of the sessions are live-streamed, and all of them are available on demand 24 hours after. So if you want to attend just to listen to it, well… It is not a concert, you will not find the difference between attending in person or through YouTube in the comfort of your sofa - wait, maybe you will find it different.

The important bits are the people you meet there. I met fellow developers from all over the world (and a lot based in London I did not happen to have met yet!), writers from the tech media I consume daily. But the most valuable opportunity for me, was to meet the googlers that make the tools I use on a daily basis as part of my job. I was able to express my frustrations, doubts and problems. And some of them happened to be important enough!

Coming back to the unhappy people, my overall impression was that they were so used to in-building conferences and perhaps not too familiar with the place and the way the sessions were run, that they underestimated the sun of the Bay Area. Which brings me to…

The Bay Area

The whole area is crazy. From the window of my ride to the conference, I did not stop counting big names: Electronic Arts, Oracle, Tesla, Motorola… Every single one of them. Of course I knew it already, but still impacted me being there. Oh, and of course Google. But I have talked already enough about them.

California

I did not have much free time out of the conference, so no fancy road trip to LA - I will leave that for the next visit. However, from the small sample I had from San Francisco to San Jose, I did notice a couple of things.

I missed that sustained amount of sun - even if I ended up getting sunburnt.
People are much nicer than in London.

Every american I talked about this with mentioned that I might have been a bit spoiled, since other states are not as nice apparently. That does not keep me from wanting to visit them all!

And don’t get me wrong, people in London are not mean in general, but they are not as warm and open, by a long shot.

The United States

Thanks to countless TV Series and movies, in Europe we have a strong stereotype of what you might find on your arrival to the US.

Awkward wedding proposal taking the mic from the band? Check.
Shitty public transportation? Check.
Twin Peaks? Check.
Crazy ass shopping malls? Check.
In-n-out burger? Check.

Final thoughts

I have had way too many first time experiences on this one in order to make a comparison or thoughtful evaluation. I am very happy that I had the opportunity to join this year’s Google I/O and I am looking forward to the next one!

Keep tuned for follow up posts for some of the things I have learned and discovered during my time in California.

Testing Android's AlarmManager

Thu, 24 Sep 2015 10:41:06 +0000

When I joined Coniq, I had to maintain and extend an existing Android application, which I did not really understand deep enough to feel safe to make big changes that it needed. So I decided to put some scaffolding around in shape of tests, in case everything decided to fall down. One of the parts I found most difficult to deal with, was Android’s AlarmManager related code.

What is AlarmManager?

AlarmManager is an old friend. It has been available in the Android API literally forever, starting Android 1.0 (API Level 1)

It is very useful when you want to schedule a task in the future and do not want to involve nasty Handlers or native Threads which can make your code practicably untestable together with many other concerns.

AlarmManager is a system service, thus you need a Context to instantiate it from.

AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

How to use alarms in Android?

Simple! You create a PendingIntent for your favourite service, activity or broadcast and pass it to the AlarmManager instance through the appropriate method. In this example I used setInexactRepeating but you can use whichever you find suitable. Full list as always in the docs.

alarmMgr.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP, // type: wake if device asleep
        SystemClock.elapsedRealtime(), // first repetition: asap!
        AlarmManager.INTERVAL_HALF_HOUR, // consequent repetitions: every half hour
        alarmIntent // PendingIntent to launch on alarm
);

And that’s it! The Android system will call your PendingIntent once the timeout has been met. Bear in mind that for apps targeting API 19 and higher alarms are no longer exact, and they can (and will) be deferred under OS discretion with the purpose of saving battery. This is, if your application is compiled against KitKat or higher, you cannot rely on the accuracy of any method which is not setWindow or setExact.

How to test alarms in Android?

Such a nice system functionality. You create the alarm, set it up and forget about it. Err but… How to test it?

Nowadays Robolectric is a de-facto standard in Android unit testing. However, for AlarmManager I decided to make my tests instrumentation tests, since it is a functionality that relies heavily on Android System features. I might rewrite it for Robolectric when 3.1 is out.

How to check if an alarm is set?

The only access to system alarms in Android is some nasty adb command that dumps the whole system status. That does not sound right, does it? But don’t panic. As this StackOverflow question points out, there is a clever way of checking for your pending intents.

private boolean isAlarmSet() {
    Intent intent = MyAlarmReceiver.getTargetIntent(context);
    PendingIntent service = PendingIntent.getService(
            context,
            0,
            intent,
            PendingIntent.FLAG_NO_CREATE
    );
    return service != null;
}

Note the flag, PendingIntent.FLAG_NO_CREATE. As per documentation, this flag will make the method call return null if the PendingIntent is not found in the system. This way we can check for our PendingIntent in the system, and thus our alarm.

In order for this to work, the Intent used in the call must pass the Intent.filterEquals() test. This is, must have same action, data, type, class and categories. Any extra data is ignored. Additionally, you need to call the same getter, e.g. if you created it calling getService, you must use it for the check as well.

What could I test?

Well, you will want to test that your alarm is actually set when you want it to be.

@Test
public void testSetAlarm() throws Exception {
    MyAlarmReceiver receiver = new MyAlarmReceiver();
    receiver.setAlarm(context);
    assertThat(isAlarmSet()).isTrue();
}

That is not set automagically…

@Test
public void testCancelAlarm_notSet() throws Exception {
    MyAlarmReceiver receiver = new MyAlarmReceiver();
    assertThat(isAlarmSet()).isFalse();
}

And that you are able to unset it!

@Test
public void testCancelAlarm_set() throws Exception {
    MyAlarmReceiver receiver = new MyAlarmReceiver();

    receiver.setAlarm(context);
    assertThat(isAlarmSet()).isTrue();

    receiver.cancelAlarm(context);
    assertThat(isAlarmSet()).isFalse();
}

Be careful here. For these tests to work, you have to cancel both the alarm and the pending intent.

public void cancelAlarm(Context context) {
	[...]
    if (alarmMgr != null) {
        alarmMgr.cancel(alarmIntent);
    }
    getPendingIntent(context).cancel();
    [...]
}

Clean up before you leave!

Have you ever heard of the Boy Scouts’ rule? Well, in tests it is quite important to clean up your mess!

@After
public void tearDown() {
    if (receiver != null && receiver.getAlarmManager() != null) {
        receiver.getAlarmManager().cancel(receiver.getAlarmIntent());
    }
}

Make sure you cancel any alarm that might have not been cancelled already by the end of the test. Uncle Bob would be proud!

Further testing

That should be it for alarm setting and cancelling. But there are many many more things we can test! For instance, enforcing that we only set up one alarm at the time, that the alarm gets the right pending intent or what happens when the pending intent is invalidated before alarm goes off.

Guillermo Orellana

Maintaining and restoring window arrangements in MacOS

Install Homebrew

Install displayplacer

Copy your layout configuration

Create a Quick Action in Automator

Add a Run Shell Script action

Paste the output of the layout configuration step

Save the Quick Action and give it a memorable name

Create a shortcut

Open Shortcut settings

Find your saved Quick Action

Assign a key binding to it

Happy rotating

Your own personal Heroku

Finding a home for our backend code

Enter Dokku and Heroku(ish)

That’s a lot of DevOps jargon, show me how to do it

Preparing our code to run on Heroku(ish)

Stuffing all your deps inside a JAR

IKEA instructions, but for your PaaS

How do you turn this on

Ship it! :shipit:

Bonus stage: easy HTTPS with Letsencrypt

Final thoughts

Avoiding the clean boilerplate: Welcome Project Lombok

The pain

Meet Project Lombok

Project Lombok and Android

Generating way too many things

java.beans.ConstructorProperties

javax.annotation.Generated

Comparison

Alternatives

AutoValue

Android Annotations

Conclusion

RxJava - FlatMap tricks

How to convince your PM into refactoring tests

The case

Speed

Temptation free

It’s not that difficult

Let’s do the math

Wrap up

Integrating React Native in an existing application

Getting it to work

Troubleshooting time

java.lang.UnsatisfiedLinkError: could find DSO to load: libreactnativejni.so

Solution

Better solution

BadTokenException: Unable to add window – permission denied for this window type

Solution

Module 0 is not a registered callable module

Solution

android.content.ActivityNotFoundException

Solution

Result and conclusions

Writing an Android component for React Native

React Native

Android side

1. Native Modules

2. JavaScript Modules

3. ViewManagers

The ViewManager

The Package

The entrypoints: ReactNativeHost

JavaScript (React) side

Exposing view properties

All together

Aftermath

Links

#YAGIOR - Yet Another Google I/O Recap

The long version

Google I/O: The conference festival

The Bay Area

California

The United States

Final thoughts

Testing Android's AlarmManager

Add a `Run Shell Script` action