Android 2024 #500
Comments
|
As I don't have any way of testing the build, it would be great if you could indicate which changes PG should do in the template, like replacing |
|
I'm not a specialist of gradle so I tried removing the That being said, it seems that an There are some explanations in https://www.baeldung.com/gradle-source-sets Several subfolders are used for different flavours or customisation of the same app : We find the same folder structure for a gradle project in https://stackoverflow.com/questions/31518622/how-to-use-multiple-res-srcdirs-and-override-some-resources-with-gradle 
Last but not least, the oboe android library (Google) follows the same architecture : 
So, I'm really convinced we should keep it as it is. It seems that it makes sense for Android projects. |
|
Thank you and here is the entire list |
|
Found more information here : https://developer.android.com/build By default Android Studio creates this structure when creating a new project : I tried it myself and got this : There are 3 folders main, Android_test and test corresponding to different versions of the app. No cpp folders : adding c++ is not your average Android project |
Hi Dimitre, we should definitely keep the gradle folder and exclude local.properties The |
|
3 Points : 1. No need of gradle folder and Bradley under ofApp In this case, there's no gradle folder and gradlew files that are added under ofApp, and it still works. I have modified on my last commit on 2. Complexity of CMakeLists.txt vary especially with Adonis That being said for ofxSoundObject I also had to change the OpenGL lib that is linked (going from GLES2 to GLES1 to get a definition for glPointSize). => it seems the modifications of the CMakeList.txt may be difficult to fully automate. 3. Checking differences in of v11.2 Android examples
For each example it's probably better to store for each example the files in :
And automate from there ? Thierry |
|
Great. My suggestion is you make a PR similar to this one |
|
Ok, I've just merged the first versino of PG android2024 template For now it is only changing cc.openframeworks.emptyExample. maybe there is more stuff to change in .java files or in other places, let me know. Added the missing files to the template and merged in openFrameworks master |
|
Great ! I will check this in the next few days |
|
Hi Dimitre, I had troubles to generate the projectGenerator apps straight with the instructions given (with setup_environment and build_command, so I moved to the legacy instructions which include downloading the OSX libs. That works and I can use a command similar to yours Then the result I get is the following : With the legacy way of creating the PG app, it is necessary to download the OSX libs bc otherwise some libs are lacking like Glew. The problem is that doing that changes a lot of the includes which differ between the android and osx libs (see the attached file). So finally the folder hierarchy is different for he libs and the OF libs is just built for OSX. So I ended to download the packaged version for macosx and I use Thierry |
|
OK I think you need to update PG, it was changed internally to handle android template files. |
Indeed I had forgotten to checkout to the last commits. This time, I've managed to go through the process to build PG and it seems I've got the right version. It seems that it's the Android template folder that is used though, and not the Android2024 ? 
Here is my output : and my PG : 
Maybe I don't use PG in the right way ? Thierry |
|
Ah ok. you will have to use only the commandLine for now, because the way it is programmed now you will have to pass "android2024" as a platform and not template. |
|
ok done ! There are a few things lacking and one thing (config.cmake) not belonging to the project. The original src can probably be erased too (or it's making too much hassle with git) ? IO've highlighted them in the following figure. Otherwise, great job ! It's a good starting point. 
|
|
Nice. I'll be updating PG. |
|
Not sure I understand what you mean. It makes sense for me to have a standard initial example project with This is exactly this hierarchy. what you see in my repo is this hierarchy that I recreated manually for the examples that I have treated. Now there are still questions arising for examples which are a little bit more tricky than the emptyExample and don't use the standard :
If you have a look at the current version of OF you will see that when there differences between a project and the emptyExample, the corresponding files are present in the initial sources. Here is a comparison of emptyExample and JavaOnlyActivityExample (2 java activities instead of 1, each with their own layout + 1 data file) : Does it make sense ? cc:@danoli3 |
|
It does. I will still rather wait to hear more opinions on this. Design wise I think we should not move the user "src" folder using PG. if we decide it is better to follow Android Standard, my suggestion would be moving "src" files from all examples to the final src folder. |
|
OK, hoping that these opinions will be completed by actual testing ! |
|
The Depths of folders goes deep, but it need not worry too much as whatever file structure as long as its linked in the cmakelist correctly via the projectGenerator 
The main issue I was having was the Build Gradle and Sub Gradle projects |
ok
Actually it's already like in the previous version of OF for the
I know nothing about PG tbh. |
|
That's great. for me the other files doens't matter as long as "src" folder is directly inside project folder. |
I'm working on a new template for Android, so we can test projectGenerator building projects like in @tctr fork.
Related thread: https://forum.openframeworks.cc/t/android-support/41968/8
First thing:
@tctr is it possible to keep the same folder depth for the cpp files? like
emptyExample/srcinstead ofemptyExample/src/main/cpp?The text was updated successfully, but these errors were encountered: