Erel B4X founder Staff member Licensed User Longtime User Jan 24, 2017 #1 If you are including resources in your library, packed inside an AAR file then you should use the following package name: anywheresoftware.b4a.objects (it should appear in the embedded AndroidManifest.xml file). Each unique package name causes the whole set of resource fields to be duplicated which can lead to the "Too many field references" error during compilation. See this post for more information: https://www.b4x.com/android/forum/threads/preferences-material-design-preferences.75482/#post-479172 Note that you can also apply it to third party libraries if you compile them yourself. You will need to update the "import <package>.R" line. This suggestion is not correct anymore. Please use a unique package name. Last edited: Apr 12, 2021
If you are including resources in your library, packed inside an AAR file then you should use the following package name: anywheresoftware.b4a.objects (it should appear in the embedded AndroidManifest.xml file). Each unique package name causes the whole set of resource fields to be duplicated which can lead to the "Too many field references" error during compilation. See this post for more information: https://www.b4x.com/android/forum/threads/preferences-material-design-preferences.75482/#post-479172 Note that you can also apply it to third party libraries if you compile them yourself. You will need to update the "import <package>.R" line. This suggestion is not correct anymore. Please use a unique package name.
DonManfred Expert Licensed User Longtime User Jan 24, 2017 #2 Erel said: You will need to update the "import <package>.R" line Click to expand... So instead of creating a somepackagename.r.java (if i create a wrap for a lib somepackagename) i should rewrite the thirdparty lib to import a anywheresoftware.b4a.objects.r? Honestly i´m not sure about
Erel said: You will need to update the "import <package>.R" line Click to expand... So instead of creating a somepackagename.r.java (if i create a wrap for a lib somepackagename) i should rewrite the thirdparty lib to import a anywheresoftware.b4a.objects.r? Honestly i´m not sure about
Erel B4X founder Staff member Licensed User Longtime User Jan 25, 2017 #3 DonManfred said: So instead of creating a somepackagename.r.java (if i create a wrap for a lib somepackagename) i should rewrite the thirdparty lib to import a anywheresoftware.b4a.objects.r? Click to expand... Yes, it is recommended.
DonManfred said: So instead of creating a somepackagename.r.java (if i create a wrap for a lib somepackagename) i should rewrite the thirdparty lib to import a anywheresoftware.b4a.objects.r? Click to expand... Yes, it is recommended.
corwin42 Expert Licensed User Longtime User Jan 25, 2017 #4 Hey, I was just about to suggest something similar.
Erel B4X founder Staff member Licensed User Longtime User Jan 25, 2017 #5 Note that the in next version of B4A the tool chain will support MultiDex configuration so don't spend too much time on this. It is still recommended to avoid adding resources by mistake. This will happen if you use Android Studio to build the library. You can delete the AndroidManifest.xml file if you don't need to access your own resources.
Note that the in next version of B4A the tool chain will support MultiDex configuration so don't spend too much time on this. It is still recommended to avoid adding resources by mistake. This will happen if you use Android Studio to build the library. You can delete the AndroidManifest.xml file if you don't need to access your own resources.
DonManfred Expert Licensed User Longtime User Jan 25, 2017 #6 Erel said: Note that the in next version of B4A the tool chain will support MultiDex configuration so don't spend too much time on this. Click to expand... THANK YOU SO MUCH for this info! I was just trying to adapt my MaterialDrawer (the one from Mike Penz) for this... The lib does contain the source from the Material Drawer lib itself but it is referencing some other aar´s used in the drawer. The other aar i do just use (no source) the aar´s. Code: @DependsOn(values={ "com.android.support:recyclerview-v7", "materialize-1.0.0.aar", "fastadapter-2.1.5.aar", "fastadapter-extensions-2.1.0.aar", "fontawesome-typeface-4.7.0.0.aar", "iconics-1.6.2.aar", "iconics-core-2.8.1.aar" }) Inside eclipse i added the classes.jar from the aar-files to be able to work with Eclipse. But this did not really help. I did change the source i was using to anywheresoftware.b4a.objects and it did change the number of subs but not that much that it comes under 64k (there are still some aars with resources used. I just changed the main drawer-source. Not the sources for all of them) Seeing this info i´ll stop here, telling the user with the problem to wait a bit and i for myself will joyfully wait for the next great release (as usual).
Erel said: Note that the in next version of B4A the tool chain will support MultiDex configuration so don't spend too much time on this. Click to expand... THANK YOU SO MUCH for this info! I was just trying to adapt my MaterialDrawer (the one from Mike Penz) for this... The lib does contain the source from the Material Drawer lib itself but it is referencing some other aar´s used in the drawer. The other aar i do just use (no source) the aar´s. Code: @DependsOn(values={ "com.android.support:recyclerview-v7", "materialize-1.0.0.aar", "fastadapter-2.1.5.aar", "fastadapter-extensions-2.1.0.aar", "fontawesome-typeface-4.7.0.0.aar", "iconics-1.6.2.aar", "iconics-core-2.8.1.aar" }) Inside eclipse i added the classes.jar from the aar-files to be able to work with Eclipse. But this did not really help. I did change the source i was using to anywheresoftware.b4a.objects and it did change the number of subs but not that much that it comes under 64k (there are still some aars with resources used. I just changed the main drawer-source. Not the sources for all of them) Seeing this info i´ll stop here, telling the user with the problem to wait a bit and i for myself will joyfully wait for the next great release (as usual).
