Dear David,
long time no see! I am very glad to see that javaGeom is alive and there are new versions. I picked up my former project and was eager to switch to a new version of javaGeom. Unfortunately, the latest version is (again) not compatible due to the old problem: The usage of java.awt.geom.Point2D in the code. You implemented conversions to your Point2D in both directions. I got the source code and removed these methods and now it works.
While the functions with java.awt.geom.Point2D are good in terms of convenience, they break the compatibility with Android. There are three options when we want to solve this in javaGeom:
1) Maintain two parallel versions: one for Android and one for normal Java.
2) Remove the java.awt.geom.Point2D stuff for good and maintain only an Android-compatible function.
3) Make javaGeom more modular, i.e., one base jar file and one jar file with additional functions that rely on java.awt.geom.
Solution 2 is the simplest. Solution 1 and 3 would require that the building is a little bit changed. Here, the solution with make.bat and makejar.bat seems quite strange to me. Anyway, one might use for instance Gradle for building what also allows you to upload jars to maven central, etc.
Best,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There might be a forth option:
4) Use Gradle to build two versions and remove all methods that use java.awt... classes for compiling the Android version.
(This would require a little bit help from some Gradle experts on stackexchange)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for your feedback! I have tried to limit the dependencies to AWT, at least by removing inheritance. But it seems this is not sufficient...
It would be nice to keep facilities for direct drawing of shapes. So either solutions 1 or 3 could be envisioned. This would require some refactoring, but seems feasible.
I also have to update the build system. I agree, the make.bat solution is not the most effective...
Regards,
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi David,
Maybe it would be in fact necessary to start with the build system. You should have a look into Gradle and see whether you like the general concept. I may invest some time within the next weeks and help to port the build system to Gradle if you think its a good idea. Moreover, it could be help to move to GIT or Mercurial instead of using SVN (I prefer Mercurial over GIT).
Dear David,
long time no see! I am very glad to see that javaGeom is alive and there are new versions. I picked up my former project and was eager to switch to a new version of javaGeom. Unfortunately, the latest version is (again) not compatible due to the old problem: The usage of java.awt.geom.Point2D in the code. You implemented conversions to your Point2D in both directions. I got the source code and removed these methods and now it works.
While the functions with java.awt.geom.Point2D are good in terms of convenience, they break the compatibility with Android. There are three options when we want to solve this in javaGeom:
1) Maintain two parallel versions: one for Android and one for normal Java.
2) Remove the java.awt.geom.Point2D stuff for good and maintain only an Android-compatible function.
3) Make javaGeom more modular, i.e., one base jar file and one jar file with additional functions that rely on java.awt.geom.
Solution 2 is the simplest. Solution 1 and 3 would require that the building is a little bit changed. Here, the solution with make.bat and makejar.bat seems quite strange to me. Anyway, one might use for instance Gradle for building what also allows you to upload jars to maven central, etc.
Best,
Martin
There might be a forth option:
4) Use Gradle to build two versions and remove all methods that use java.awt... classes for compiling the Android version.
(This would require a little bit help from some Gradle experts on stackexchange)
Hi Martin,
thanks for your feedback! I have tried to limit the dependencies to AWT, at least by removing inheritance. But it seems this is not sufficient...
It would be nice to keep facilities for direct drawing of shapes. So either solutions 1 or 3 could be envisioned. This would require some refactoring, but seems feasible.
I also have to update the build system. I agree, the make.bat solution is not the most effective...
Regards,
David
Hi David,
Maybe it would be in fact necessary to start with the build system. You should have a look into Gradle and see whether you like the general concept. I may invest some time within the next weeks and help to port the build system to Gradle if you think its a good idea. Moreover, it could be help to move to GIT or Mercurial instead of using SVN (I prefer Mercurial over GIT).
Btw, I finally got my Android game in the market, you can check it out: https://play.google.com/store/apps/details?id=de.timedout.mosaic.app
Best,
Martin