Mocking @AuthenticationPrincipal with Spring Security in Unit tests using MockMVC

Do you rely on getting information based on an AuthenticationPrincipal with Spring Security and want to use MockMVC for Unit-testing? Do not worry, we got you covered.

Use this Security Interceptor file in your Unit tests:

And here is how to setup your MockMVC instance and how to make sure your AuthenticationPrincipal is passed along:

Performing recurring tasks in Android (Periodically refreshing location)

When writing an Android app, you often need to perform periodical tasks, such as calling a (remote) API, getting the current (last known) position of the device, or notify the user of something.

First step: Schedule an Alarm

You'll want the Alarm to look something like this:

What this will do, is make sure, that the AlarmManager fires the defined Intent (PendingIntent) in a scheduled timeframe. In our example, it is fired roughly every minute. You should prefer setInexactRepeating() to multiple setExact() calls whenever possible, as this will reduce battery strain, at the cost of some inaccuracy in the wanted interval. Also, if you can allow even more inaccuracy in the frequence of Alarm calls, make sure to use ELAPSED_REALTIME (or RTC as needed) instead of ELAPSED_REALTIME_WAKEUP to further prolong battery life.

Now, this code still needs to be called from somewhere. A place to start would be if the user opens the App in the current session, so the onCreate() method of your Activity opened on App start would be a good place to start. Make sure to unregister the Alarm appropriately if you only need it active while your App is open or in the foreground. Since we need to know the user's location even if he did not start the App on that day yet, we furthermore register an Alarm at Bootup of the device, which will requre a special permission:

Second step: Start your service

Make sure to add the required permissions in your AndroidManifest.xml, as well as register both the BootReceiver, and an AlarmReceiver which will trigger whenever the Alarm goes off.

Third step: Do your work in your service

We use Google's FusedLocationProvider, which takes several factors into account to give you the last known location. Set Intervals, number of Updates you want and Accuracy according to your needs and connect the client. You can then go ahead and perform your work (like FusedLocationApi.getLastLocation()) in the onConnected() method of your service.

Additional comments

Schedule your Alarm once: Make sure to register your Alarm only once, either at startup or when the app is launched. The Android system handles it well if you schedule the alarm multiple times accidentally, and does not schedule it more than once for you, but still you should not rely on this behaviour staying the same for all future Android versions.

One word of caution regarding network API Calls: Do not perform brainless polling, as you'll stress out the network and battery very quickly. Make sure you determine in your logic, wether an API request is needed, and only then perform the call. Also make sure to add some randomness or different intervals for scheduled API calls, as you do not want to have all your users (and hopefully you'll have a lot) hit your API at the same time.

Using Spring Cloud and Hystrix for an api gateway

If you are using a microservice architecture for your backends you have many services. Maintaining them all in the client application can lead to a big amount of additional work. The state-of-the-art avoiding this is by introducing a new service called the api-gateway. This service is responsible for mapping requests from a client to the desired service endpoint. More about api-gateways can be found at: http://microservices.io/patterns/apigateway.html.

A basic example

In the java world the common approach is to use Spring with a circuit-breaker, in most cases this would be Hystrix. A short example would be:
But as you can see, even for simple mappings that don't have a fallback or other special mechanism provided by Hystrix, you have to write a bunsh of code. For each mapping there has to be a method in the RestController class, a service method in form of an interface and an implementation and at last all required models. For small apis this is not really a problem, but when the api is growing it becomes harder and harder to maintain.

Our solution

We thought it would be easier to create annotations that simplifies the mapping process. With them you can define which url of the api-gateway is mapped to which url on another service. If you need fallback methods it is still possible to define them like in the example above. Our implementation of such annotations looks like this:
Now you are able to concentrate on the implemenation of methods in the RestController, that do more than just mapping one endpoint to another.

The implementation

Now you might be interested how we got that work. First we created our own implementation of the abstract class RequestMappingInfoHandlerMapping. There we create a mapping for each annotation we find and apply a handler to it:
The handler then gets called when a client requests an url and it creates and executes a hystrix command. This command needs a unique name in order to use a seperate threadpool for each endpoint url of the api-gateway (the default behaviour of using the simple class name is not sufficient because all enpoints use the same class). The command then simply propagates the request forward to the desired service:
And that's all. Only ensure that you include the right dependencies to get this work.