2

I'm new in android development and used to develop in JavaScript. A common practice there is to implement an interceptor to add Authorization header. In my current application is not different. In this new world to me, SharedPreferences is quite equivalent to LocalStorage. But to access the first one I have to use a Context.

Here is my problem: to get a token, stored in SharedPreferences, being inside the intercept method, I must pass a Context to the Interceptor, but the flow 'til there has many classes: a service, a Retrofit handler, a okhttp3 client, and just then Interceptor itself.

I'm digging it for awhile, and the two approaches I've found are: pass the Context through all this flow as parameter or create a "God" class only to keep the Application Context at hand as static method.

For now, I'm using the first one as you can see below.


public class APIRESTInterceptor implements Interceptor {

    private static final List<String> noAuthRequirements =  new ArrayList<>(Arrays.asList("/api/app/login", "/api/app/token/refresh"));
    private static Context context;

    public APIRESTInterceptor(Context context) {
        setContext(context);
    }

    public static void setContext(Context context) {
        APIRESTInterceptor.context = context;
    }

    @Override
    public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
        String requestPath = request.url().encodedPath();

        if (!noAuthRequirements.contains(requestPath)) {
            String accessToken = SessionUtils.readOfSharedPreferences(context).getAccess();
            request = request.newBuilder().addHeader("Authorization", accessToken).build();
        }

        return  chain.proceed(request);
    }
}

What I want from you, people: a simpler strategy, more like what is done in JavaScript to access LocalStorage, despite the mess there (sorry). Sumarizing, I don't want to pass it as parameter neither this "God" class. Is there a third approach?

phsa
  • 61
  • 7
  • The 'God' class you are referring to is just the application class that stores all relevant global variables and initializes things when your application starts. So It makes sense to have a reference to your application context there. NOTE: the class needs to extend the Application class. – philoez98 Jul 11 '19 at 05:06
  • @philoez98, this kind of resource shouldn't be set using some gradle injection? IMHO, it seems an alternative way out to the lack of an "officially" accepted approach. But, thanks, and I will use your suggestions.If you let me, may I ask your thoughts in [this](https://stackoverflow.com/a/38967293/11757100) answer to a similar, but not equal, topic? – phsa Jul 11 '19 at 12:08
  • the answers to the post you mentioned are exactly the way I told you about. The major apps around do that, so I guess it's the safest (?) way to go about. – philoez98 Jul 11 '19 at 12:33
  • So, thanks for the response. I think I'll follow your suggestion. – phsa Jul 11 '19 at 14:22

0 Answers0