You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great for better programming to have proper super classes for the model classes. For example, all WhatsApp model classes have fields like "from", "to", "messageId", "callbackData" and notfiyUrl (Inlcuding getters).
This also applies to the SendWhatsApp<...>Request classes and the object they return with the executeMethod.
For example, I want to have a method which sends the request to do some processing which is not dependent on the type of request, but using the current classes I have to do a lot of method overriding, duplicating code and e.g. using lamdas to send the requests instead of handling an abstract request.
The text was updated successfully, but these errors were encountered:
I apologize for the delay in my response. I appreciate your patience.
Could you kindly provide the code snippet related to processing the classes in question? Additionally, please specify the version of the infobip-api-java-client library that we should review.
Thank you for using our library, and I look forward to assisting you further.
Thanks, but I already solved the problem for me. The version was 4.0.0, it is hard to share a snippet for this, because is is more of a broader problem / suggestion
It would be great for better programming to have proper super classes for the model classes. For example, all WhatsApp model classes have fields like "from", "to", "messageId", "callbackData" and notfiyUrl (Inlcuding getters).
This also applies to the SendWhatsApp<...>Request classes and the object they return with the executeMethod.
For example, I want to have a method which sends the request to do some processing which is not dependent on the type of request, but using the current classes I have to do a lot of method overriding, duplicating code and e.g. using lamdas to send the requests instead of handling an abstract request.
The text was updated successfully, but these errors were encountered: