Java Question Constructor/initializer approach

[JordiCP]

One of the classes I am adapting extends an abstract class which extends a View. But this thread is also valid for other classes in the same project (not necessarily involving views but also with non-empty constructors)

As said, this class has a couple of non-empty constructors. Also, it has some private members.

With only BA annotations, I can't Dim a var of that class since, as it doesn't have any empty constructor, throws an error.

So I opened about 30 tabs in my explorer with forum threads regarding library wrapping/developing. I have seen different coding styles and solutions optimal for different cases, and have learned a lot from it

At the end I did something which I find "optimal" for my case but not sure if it is recommended

• Declare an empty constructor for the class --> So, the object can already be dimmed in B4A

• Initialization: I have declared an inner static constructor/builder class with a couple of methods (equivalent to the original constructors) that return a new instance of my class. So, in BA, I do:

Dim myObj as OCVJavaCameraView
Dim myConstructor as OCVJavaCameraViewConstructor      'a static inner class used for building purposes
myObj = myConstructor.createNewInstance(...)      ' call one of the constructor methods

'The constructor approach allows to instantiate new objects "on the fly"
' e.g.
callSomeSub( myConstructor.createNewInstance(...), myOtherParams.... )

or even, declaring a couple of helper methods in the same class which do the same work as the inner constructor class methods.

myObj=myObj.createNewInstance(...)     'internally makes use of the constructor

'The only difference is that we must use syntax above instead of
myObj.createNewInstance(...)     'initialize method

I think it is a good solution since all the classes work, each one of them making use of the others in B4A and Java, with no need of wrapping/unwrapping.

The other approach would be encapsulating the view and the other fields in an outer class. So we could have direct Initialize methods. But I can see no other real advantages.

My question is: am I missing something which makes this solution not valid or not optimal?

 

[Erel]

Sounds good.

I would not use such a solution for a public library because it is not standard. Developers will find it easier if they need to call Initialize to prepare the object. You can also add an Initialize method(s) to the original class and move the logic from the constructor to the Initialize method.

 

[JordiCP]

Yes, I agree.
I will add the initialize methods but also leave the constructor so that these objects can also be declared "on the fly". It can always be ignored or even hidden if it turns out not to be useful.