Gathering Extensions!

I would like to help gather native extensions together into one place where we can all help collaborate, and over time, continue to develop “best implementation” versions of each needed extension, and unify our efforts.

I’ve started to use the “extension-” prefix (“extension-iap”, “extension-gamecenter”, etc) as the common name, and I am beginning to help migrate repositories into the OpenFL Github organization. Anyone who is interested should let me know, we can help host the extensions on the Github page, we can set up nightly builds, and of course can make sure that excited are given access to help maintain and develop these extensions together.

Over time, I think we’ll be able to develop common code conventions and other similarities that will make switching extension to the next a familiar process. For anyone interested, I also have an #extensions room in the OpenFL Slack account, so that there’s a common place for extension developers to chat and help collaborate on filling missing holes or working together on improving what we already have :slight_smile:


Nice idea, how can I rename and move my extensions? :slight_smile:’

And this too :smiley:

1 Like

isn’t haxelib the place where all the extension should be gathering anyway, so what would be the point of this? on my case, i’m not interested into moving my extensions to the OpenFL organization, but anyone is free to do a fork or submit a pull request to contribute to the cause :smiley: .

@shadow_of__soul I imagine the point is to easily find extensions.

then let’s improve haxelib search engine or do a directory of extension in openFL site that would fetch Readme from existing github repos submitted by community members.

The website definitely need an extension list,
as for the haxelib website apparently it’ll have an update soon, normally around the same time as haxe 3.2, so let’s way and see on that one.

Here are a few reasons:

  1. Gathering together to collaborate on building “best” versions of each extensions we need. This helps bring things under a common organization where we can add contributors to maintain and improve the extensions

  2. This help people discover extensions, and know where to go to help contribute to them

  3. It can help promote common syntax and conventions between multiple extensions, over time extensions can develop style and flow that makes jumping from one you use to a new one a familiar process

  4. We can add the extension to nightly builds, it can automatically be built for each supported target (iOS, Android, desktop, etc) using the latest code

I’ve just added you to an admin group that should let you move repositories over, if you wish :slight_smile:

Great, thank you!
I’ll do it after some time, I have other work to do now.

Share: This is a sharing extension for Android and iOS, the sharing parts maybe less powerful than openfl’s extension-share. But what (I think) make it different is the ability to accept url to launch the app.

GoogleApi: A WIP extension for logging in GoogleAPI service, mainly focus on the GooglePlayGame service’s REST API. But there are also native API calls (e.g. Achievements)

@kevinresol Have you looked at and

This is the sort of thing I’m thinking, perhaps there’s things each one is doing that’s actually better or more completed. Obviously (sometimes) it just doesn’t work to try and align efforts, but it would be great if we could look at considering one good “share to ____” extension and one for Google Play Games, “extension-playgames”

I briefly read the readme files of the two repo. Did not go through all the functionality. So I can only guess out the differences. For extension-share, I think I would like to see the ability to launch app with URL, which I have done in my repo. For openfl-gpg, it supports only android but my repo also support ios, but I only implemented Scoreboards and Achievements (although other API could be added easily as the overall framework is already established). Another plus of my repo is that both REST API (through URLLoader) and native API can be used.

I think at the end of the day someone has to choose one to adopt as the “official” extension. And then we can invite authors of similar work to add the missing functions.

@fbricker Are you around? Do you have anything to add about this? Thanks! :slight_smile:

I’ve renamed/moved some extensions with github, but don’t know how to rename them with haxelib.
Any ideas?

I don’t know of a way to rename on haxelib, we just need to submit under a new name, but that’s alright. Not the worst thing in the world, and it will get better over time. Been making a request for a feature like this

I’m working on some extensions here :

If any of those extension doesn’t already exist in a better implementation, i’d be happy to do the according changes to migrate to the organisation.

by the way, I didn’t know there was a openfl slack chat for extension, is this only for the organisation members ?

No, Slack is invite-only (by design) but otherwise it’s open to pretty much anyone who’s interested – once we get into collaborating, I figure instant chat is better than long forum posts, sometimes, to sort out the best path forward :slight_smile:

Hello there!
Sorry for possible inconvenience, I’d like to know if there already exists native maps (or google maps) openfl native extension for iOS/Android? And also for push notifications?
Haven’t seen it anywhere for OpenFL but have seen a couple of solutions for Adobe AIR…