Excellent post, yet again. Well done for figuring that lot out - the jni implementation is indeed a mixed bag.
I am not sure of the logic behind some of the namespace choices - I have had to do much grepping to find where various bits of the android api are buried, although calling constructors is simple enough - the init methods are the Java class constructors, this is not something EMB have done - its how they are stored in the jars. I was able to call a different constructor in my dexloader example, it took some lateral thinking though!
I think that they have done just enough to get android working, much will change in future releases - including getting Brian longs jarbridge into the code base I hope.
Cheers. Those init() initialisation methods then don't so much represent what EMBT have done as what they haven't done.
As you say, they've done just enough to get it working and since they really don't intend people to be using the SDK unless they absolutely have to I suppose it makes sense that they wouldn't put much effort into making it convenient to do so.
Honestly, I think this is a case of meeting a release date rather than anything else. At least theynbare actually doing something - unlike codegear :-)
The init calls offer up the Java platform versions of what the Java constructors 'compile' down to. In the case of a parameter-less constructor, the Create class function of the Java bridge import class deals with calling the base init for you. The interfaces surface stuff that's in the Java byte code of the classes concerned. init constitutes part of that stuff.
Sorry, I'm unclear on what you're saying there. Basically the init methods are like Create in Delphi - they are the construction initializers and are called when Java calls a constructor on a class. What are you saying - that all is good in this realm? Or the bridge class Create vs JNI init methods is or is not an issue?
I didn't find the bridge class create vs init an issue at all, it created a properly encapsulated JNI object without issue for me. I had though by using class.javaclass.init(someparams) that I would be bypassing the JNI bridge bits to create a java object without the associated JNI additions, I was (fortunately) wrong
I would hope that any developer with half a brain and an ounce of curiosity has used grep to search the RTL for code examples of things that they need - its the biggest single resource you have of "how the heck do i do this?" (or indeed, how NOT to, depending on your point of view - or indeed depending on what you are looking for).
I have been somewhat disappointed by how often people ask very silly questions which they really ought to be able to work out for themselves.
Good point, Is it worth saving ? With a plethora of new languages , Delphi is no longer up front. Although, I still like to develop Windows desktop apps if I need.
At this prices, it cannot compete. I am learning Python, and just downloaded PyCharm community edition from JetBrains. Nice product and free. The pro edition is $99.00 which I most likely buy. EMB is completely out touch with its customers.
Excellent post, yet again. Well done for figuring that lot out - the jni implementation is indeed a mixed bag.
ReplyDeleteI am not sure of the logic behind some of the namespace choices - I have had to do much grepping to find where various bits of the android api are buried, although calling constructors is simple enough - the init methods are the Java class constructors, this is not something EMB have done - its how they are stored in the jars. I was able to call a different constructor in my dexloader example, it took some lateral thinking though!
I think that they have done just enough to get android working, much will change in future releases - including getting Brian longs jarbridge into the code base I hope.
Cheers. Those init() initialisation methods then don't so much represent what EMBT have done as what they haven't done.
ReplyDeleteAs you say, they've done just enough to get it working and since they really don't intend people to be using the SDK unless they absolutely have to I suppose it makes sense that they wouldn't put much effort into making it convenient to do so.
Honestly, I think this is a case of meeting a release date rather than anything else. At least theynbare actually doing something - unlike codegear :-)
ReplyDeleteThe init calls offer up the Java platform versions of what the Java constructors 'compile' down to. In the case of a parameter-less constructor, the Create class function of the Java bridge import class deals with calling the base init for you. The interfaces surface stuff that's in the Java byte code of the classes concerned. init constitutes part of that stuff.
ReplyDeleteCalling a different init to use one with parameters doesn't seem to bypass the delphi JNI class constructors though - it works as expected
ReplyDeleteSorry, I'm unclear on what you're saying there.
ReplyDeleteBasically the init methods are like Create in Delphi - they are the construction initializers and are called when Java calls a constructor on a class.
What are you saying - that all is good in this realm? Or the bridge class Create vs JNI init methods is or is not an issue?
I didn't find the bridge class create vs init an issue at all, it created a properly encapsulated JNI object without issue for me. I had though by using class.javaclass.init(someparams) that I would be bypassing the JNI bridge bits to create a java object without the associated JNI additions, I was (fortunately) wrong
ReplyDeleteAh, gotcha. Yes, it is simpler than it may initially appear to be.
ReplyDeleteKudos for finding "AndroidAPI.JNI.GraphicsContentViewText"! Other observations are truly valueable.
ReplyDeleteI would hope that any developer with half a brain and an ounce of curiosity has used grep to search the RTL for code examples of things that they need - its the biggest single resource you have of "how the heck do i do this?" (or indeed, how NOT to, depending on your point of view - or indeed depending on what you are looking for).
ReplyDeleteI have been somewhat disappointed by how often people ask very silly questions which they really ought to be able to work out for themselves.
Paul Foster ah yes - the Politician's Syllogism. ;)
ReplyDeleteCodeGear may not have done much in their time and
Embarcadero may have done far more. But it's not how much is done but what that ultimately counts.
Indeed. Have they done enough to save Delphi though? I hope so, although I doubt it
ReplyDeleteAgain, the real question: Is it worth saving ?
ReplyDeleteIt has never been quite so irrelevant as it is right now. :(
Good point, Is it worth saving ? With a plethora of new languages , Delphi is no longer up front. Although, I still like to develop Windows desktop apps if I need.
ReplyDeleteOf course its worth saving, given the choice would you rather write in Java or Delphi? I'll take Delphi any day :-)
ReplyDeleteLazarus/FPC is good, smart mobile studio looks interesting too, there is also oxygene - can Delphi compete? Not at these prices!
At this prices, it cannot compete. I am learning Python, and just downloaded PyCharm community edition from JetBrains. Nice product and free. The pro edition is $99.00 which I most likely buy. EMB is completely out touch with its customers.
ReplyDelete