Processing Android as aar library in a maven repository

[victordiaz]

I've been using a tiny fork of Processing Android (with fragments) I made few years ago that can be embedded in any android app as a library https://github.com/victordiaz/ProcessingFragmented First I apologize that it wasn''t a proper fork since at that time I didn't know the proper git workflow :)

I think it might be very useful to have Processing in a maven repository so any person could use Processing core easily in any Android app just including the library in the gradle file. I think the amount of users will grow really fast if this is done.

Do you think it would make sense to have this option?

Here you can try it out the library, just download the aar file, reference it in your gradle file and you can use Processing in your app https://github.com/Protocoder/Protocoder/tree/app_cleanup/protocoder_app/libs

Cheers

(EDIT: misspell)

[codeanticode]

@victordiaz Yes, I think it would be very useful for many people working primarily with Android Studio. Could you update your package to the latest version of the core library in master? Many things changed in the past year, and now the mode supports Wear and VR among other things.

[victordiaz]

Sure! I will first explore the current code and see if it need some changes. Excited to play with the new features :)

[rich-gg]

interested here ! :) how different is it from http://android.processing.org/tutorials/android_studio/index.html ?

[victordiaz]

@rich-gg thx for pointing out that tutorial! I wasn't aware of it it :)

So basically the main differences are:

1. AAR files can contain layout resources, drawables, etc. That will make it easier to encapsulate all the android functionality in just one file. I think the core.jar doesnt contain cardboard, wallpaper and watch layouts so when using Android Studio one would have to include those files manually.
2. Having the library in a maven repository you can include a library with a new line in your .gradle file and get easily updates.

@codeanticode I just compiled the latest version successfully and checked a bit the code structure. As far as I see, the layout XML files are in processing-android as templates. Do you think it will make sense to move them inside core? Doing that, It will be easy to extend Wallpapers / Watches / Cardboard easily in Android studio without adding extra files and allowing to add more functionality in the future in an easier way. I will try to play a bit with the idea and share my discoveries here.

[omerjerk]

@victordiaz I believe that it's better if the XML files stay inside processing-android only. I haven't looked into the new processing-android code with all the watch and VR features, but I'd still not prefer to move the XML files to processing-core.

[codeanticode]

The template files should not be moved inside core. The reason is that Processing for android has two components: the core library, and the mode itself, which is in the root of the repository. The mode uses the templates to create the project structure when you run the sketch from the PDE. When you include the core library in an Android project developed in an IDE such as Android Studio, you either have to create those project files (manifest, main activity class, resources, etc.) manually, or use those generated by the IDE.

[victordiaz]

@omerjerk @codeanticode I understand better the current structure and I agree, the templates are better placed where they are now :) I guess it's not necessary to create any aar file and the core.jar works quite nicely the way it is. Just replaced my old custom version with 4.x branch core.jar and works almost the same.

I would still suggest to have a maven repository with the library. The current method to include the core.jar in an Android Studio project is either compile the Core your self or download Processing + Android mode and then extract the core.jar. Its not complicated but a bit time consuming specially to update the lib for each release.

I've never uploaded any artifact to a Maven repository but I've found 4 suitable options

• Maven repo (The traditional / standard option) http://maven.apache.org/guides/mini/guide-central-repository-upload.html
• Self hosted https://stuartsierra.com/2009/09/08/run-your-own-maven-repository
• using Github (not that nice apparently) http://stackoverflow.com/questions/14013644/hosting-a-maven-repository-on-github
• https://jitpack.io is quite an easy option

Will any of this options integrate well with the current building process?

[codeanticode]

@victordiaz I think hosting it to maven would be a good option. JCenter seems to be another popular repository. @omerjerk do you have any recommendation on repositories?

It does not need to be managed by Processing. If you interested to maintain a "processing for android" artifact on Maven, JCenter, or another repository, please go ahead. You would need to update it every time there is a new release of the mode.

[omerjerk]

I also like the idea of uploading processing-core to maven. I would definitely like to take up this responsibility, if no one else plans to do it.

@codeanticode I have uploaded libraries to JCenter previously. It's pretty easy to use. However, I can't compare one service with the other. We can move ahead with JCenter.

[codeanticode]

I think that both Maven and JCenter are largely equivalent, at least from the perspective of the developer using Android Studio, so go ahead with the one you are more comfortable with.

[omerjerk]

Sure. I'll update you on this.

[rich-gg]

Processing being Processing, please keep in mind that this new way to use processing in Android Studio will need a designer/artist friendly tutorial I would be glade to be the test pilot for that dumb proof process :]

[codeanticode]

There is a tutorial on the Processing for Android site about using Processing in Android Studio, which we can update once the core library is available through Maven or JCentral.

[codeanticode]

The new build scripts generates packages ready to upload to JCenter. They are provided as jar, since there is no need for additional resources. Previous versions of the core and VR libraries are already available on JCenter.