This doesn’t support leaderboard and achievement yet, right? Is there any plan or news about it? Like I said earlier here, I tried to build an Android native extension having leaderboard feature but failed.
The biggest problem was that it seems Defold uploads whole libraries when I add a new jar. And I had to wait for a long time with even one single fix. And I wonder if Defold team are using Defold to make native extensions in the exactly same condition with the other Defold users. Otherwise, are you guys having advantages like putting jar libraries on your server directly and can test it with rapid feedbacks? Of course definitely it must be much more efficient. In other words, can I do everything what Defold team can do to build native extensions?
Correct. We were hoping that the community would make contributions and addmissing features themselves, but so far no one has volunteered.
We have the ability to run a local version of the native extension server in a Docker container. This will reduce the upload time to virtually zero and speed up the iteration process if you have a slow connection.
We will make it possible for everyone to do this in a few weeks time.
I tried but failed as I said. But it’s not just a problem of network. You should be able to use gradle and aar to build with the leaderboard feature in Android. The leaderboard is using ComponentActivity which is a part of huge aar chains. Maybe that’s why you guys excepted the feature for the current version. At least it was the reason for me. And it’s impossible with the current version of Defold as just a user of it. Refer this: https://github.com/playgameservices/play-games-plugin-for-unity . Unity is possible to build such plugin. I hope same thing could be possible on Defold.
Although we have this option, I only really use it to debug things.
Otherwise I (we) do use the same pipeline as you do.
AAR support has been on our radar for a long time, and while it previously was easier to solve things in a straightforward way, Google now rely on a much more complex beast (gradle) to build things.
And, the more other vendors update their 3rd party libraries, it grows continually harder to build the engine in a more straightforward fashion. So, we are anticipating us having to to AAR, through gradle, but we currently have no ETA for when that will happen.
You can ofc script this, by using gradle to resolve your dependencies, then unzip the AAR files and put the files in correct places.
Independent resources in aar are a big problem. It shows the reason of birth of aar format. Each one belongs to each aar. So unzipping and placing are huge job, easily mistakable, and not guaranteed.
Actually big vendors compete each other extremely and so it seems they really don’t like platform independent development. Such actions of them prove it. Anyway supporting gradle is necessary to build right binary for Android. It means native extension developers should be able to use Android SDK with Defold.
Yes, that’s what we’ve seen during these last two years of the extension development. It becomes increasingly harder. But, with that said, it’s not a complete blocker. You can do it if you need to.
It means native extension developers should be able to use Android SDK with Defold.
Not sure what you mean here?
When you make a final apk or aab file for Android in the linking process, gradle finds right aar libraries in the SDK. You can not and should not assume that some aar files are completely independent from the rest part of the SDK. Even though some are independent now, they still could be engaged complicatedly in the future. That’s why using SDK for gradle is necessary.
Ah, yes. you should be able to use it as you normally use gradle, with specifying dependencies, and the dependencies get resolved. And yes, that includes getting things from the SDK.