Sharing POJOs between Java backend and an Android application

Question

I am developing an Android application with my friend. I am currently responsible for the backend while she is working on the Android part. The backend is developed in Java using Lambda functions running in AWS Amazon Cloud‎. The frontend and the backend are totally decoupled (Lambda functions are exposed via REST APIs) except for the POJOs used on both sides. POJOs are serialized by the application into JSON when calling an API and deserialized again into POJOs (very same ones) by the backend when handling API requests.

We want to keep POJOs on both sides exactly the same for obvious reasons but we are wondering what the proper way to do it is. We see the following two options:

1) Simply copy code on both sides. This has the disadvantage of changing common code independently which, sooner or later, will lead to a misallignment.

2) Move POJOs out to a separate library and include it as a dependency on both sides. This seems like a more proper way to solve this issue but how do we ensure that both me and my friend know that a POJO has been changed? Let's say I remove one field from a POJO and create a new version of the shared library. I push changes to our repository and then... tell my friend that I made some changes so she should pull them, build the new version and include it in her project?

Is there a different (better) way to address this issue? Currently the backend is built with Maven but I can switch to Gradle if this would help automate things and make our code consistent (Android Studio forces Gradle builds).

I found similar questions of other people but they were either a bit different or remained unanswered:

Sharing POJOs between Android project and java backend project

Sharing one java library between Android and Java backend (gradle)

Sharing code between Java backend and Android app

Answer 1

There are certainly lots of other ways of doing this and better or not; I will leave that to you to consider.

But before going to sharing the POJOs, I ask you to take a step backwards and take a look at your architecture. You have essentially got:

1. a Java Backend with REST APIs, supporting JSON payload
2. an Android Application, capable of making REST calls and deserialising the JSON payloads.

If you note, above, the tech stack does not involve POJO on any level. You see what I mean? POJO is an implementation detail for you and it is not wise to share it among your components.

How about looking into the future where you add more components to your architecture, say:

3. iOS application
4. Kotlin support for Android application

Will your inclination to share POJO code still be intact? Perhaps not.

From what I see, you should design and develop for a REST backend and a REST capable client. Thats all. That should be the bottomline.

So with that, coming back to your requirements of sharing the updates between the backend and the client, you can share the JSON schema between the two, instead of sharing the POJOs. And thereafter, employ an automated system (say, a simple script) to generate POJOs in the backend and the client.

This approach can have certain benefits. For instance:

1. You will be able to share updates now and in the future, as per your requirements.
2. This makes your modularity (or decoupling) better too because the backend and the client is not bound by the requirements to use POJOs. For instance, you can use Data class if you decide to use Kotlin in your client.
3. You can use versioned schema for future, for the times where the client cannot keep up with the backend, or the backend needs to update independently.
4. and more