6

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

parsecer
  • 4,758
  • 13
  • 71
  • 140
tomomomo
  • 157
  • 2
  • 13

2 Answers2

11

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:

  1. iOS application
  2. 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
codeFood
  • 1,241
  • 16
  • 16
  • This is exactly the mature response I was hoping for. Thanks a lot, you are totally right. – tomomomo Dec 02 '18 at 19:01
  • ...except that it doesn't answer the question.I do agree that you dshouldnt even be exposing class code outside of class let alone the application, but when I hear POJO i think of the interface not the implementation. – Nate T Dec 25 '20 at 05:05
0

Adding to the answer above, I would take advantage of the fact that both languages use Java compilers and apis. Whether the front end uses Java or Kotlin, you can call any of these api libraries directly from your code.

One api in particular, Json-B, provides methods for transforming your Java (or Kotlin) objects into Json for transport, then transforming the Json response back into Java/ Kotlin on the other end.

One caveat: I recently heard that at least parts of the javax.* package were scheduled for deprecation. They should work on Java 14 or lower, but if you are planning on updating in the future, this is something that you will want to consider.

For Java versions 9 or newer, you should also read this first. It will save you some time.

EDIT: Json-B is, in fact, disabled by default in newer Java versions (the package is included but 'hidden'), but the last article linked in the paragraph above talks about acceptable workarounds. IMO it is still the preferred option for working with Json in Java.

Nate T
  • 727
  • 5
  • 21