Hi so I know how to use Kyronet and libgdx but what I want to know is when installing the Kyronet library do I only have to copy it into the Main project folder or do I have to put it in the Android and Desktop folders as well or do I have to do that attach source with?
I'm only asking here cause I can't find any documentation on installing Kryonet and want to cover all of my bases
Never used kryonet, but if it's no android native components dependent, it's ok if you just import it in your main project.
Regarding including source code, there's no need unless you're planning to make frequent changes to it.
In my previous projects, I've had to add it to the build paths of both the Main project and the Android project.
Related
I am developing a word game. My aim is to have 90% of the code in pure Java, which is then referenced by Android Studio for an android app, by GWT to make a web solution and exported into objective C for iOS for the small amount of UI coding needed.
I have written all the code and I am only able to do this by manually copying the java classes between the projects. Clearly it must be possible as this seems such an obvious use case, but there does not seem to be a straightforward solution.
I realise I may be missing something. I have searched extensively, in particular the following:
Import source java project in Android project
Android studio add external project to build.gradle
Any help would be much appreciated.
I am working on a library that ideally will have a strictly-Java component and added functionality for Android-specific projects, with the intent to be most useful for Android apps, but also work with other Java apps.
But my question is: how should this be designed? I do not plan on needing resources, so I want to compile it into a JAR, but would I need to make two JARs, one of the Java stuff and another for the Android stuff? Or would a Java-only application be able to use a single JAR so long as it does not use the Android components?
If you make a library that uses pure java and does not use any android apis. It will work on both standard java and android java. However if the library uses any android apis it can't be used in a standard java project.
As far as I know, the JAR would be good for both types of aplications. It seems to mee that both JARs (just Java and android) are totally identical and thus equally compatible. If you don't use any of the android components, including Resources there should not be a problem at all.
You should still check whether you depend on libraries which are available on android and any normal Java distribution or -if not- either tell the user to preinstall the depending libraries or ship them whitin your JAR package and build path. Be carefull not to use libraries which are not available on android because the user has no or really few options to install them on himself.
What I don't understand is why you think your library is more usefull to android developers. I can not think of any example where this could happen. If the problem is really specific for android, you should consider developing the library android-only. If the problem is more general the lib will be usefull to all developers that might come to this problem, not just android.
I am currently attempting to port an android app to desktop. I realize that the majority of the android based code cannot be reused, but what about "smaller parts" which dont depend on the android architecture?
I am mostly talking about support or math related classes like SparseArray, Matrix and so on.
Those may work. But you will have a rough time figuring out what works and what doesn't. Even once you do that you will need to create a whitelist somewhere like in your IDE that doesn't auto-complete classes you don't want or can't use and you will also want to fail your build. Maybe you should create a jar containing only the classes you want to use that you determine are usable.
My project has next structure:
Java part for GUI
Native part(C++) for logic
they are connected by socket.
So, in development process I run native part on desktop computer and java part in android device. They connect by WiFi and it is very comfortable to debug every part.
But sometimes I need build full and all-sufficient .apk where native part included in it as .so libs and calling from java code.
For this reason I try to find a handy way to "ON and OFF" native support in project. Now I see only one way - comment/uncomment all in Android.mk(it is important to prevent including .so libs in apk because they are big) and comment/uncomment call of native finction in java.
But I don't like it...
Thank you!
What you describe looks like two different projects that share some (maybe much of) common code. You can easily have such setup in Eclipse, you can use linked folders to make source sharing between the two projects automatic. But it may be safer to use your source control's powers to maintain sync between sources for the two projects.
not to create an Android project but just a common Java program, can i import packages from Android SDK in order to use some interesting methods and compile it using java compiler in JDK.
Thanks.
If the package uses Android-specific SDK's then no (without some porting). If it's generic Java then probably yes. I have imported packages I wrote for BlackBerry to Android and vice-versa, but any Android-specific API calls have to be rewritten.
There are Android SDK JARs under
android-sdk/platorms/android-3/android.jar
In this case it is API Level 3. I used to copy this .jar to the buildpath of a framework that I am coding recently.
You can use those in Java since they are java bytecodes and your jvm can execute it. Your classes may use classes of Android SDK, however I think since most of them do need an Android environment, they will not just work standalone and will require deployment to an Android device. It is fine if you are just planning to import something but not start Android functionality at all.
You can include common libraries. That is to say, package the Android code as a library or .jar file, and include the libraries in the build path of the Java application. This should work both ways. Android uses a lot of the same Objects and Principles as Java, so some things will work without a hitch. Beware of having to tweak it, though. Projects aren't structured the same way
Perhaps there are some limited cases where it might work, but I doubt it. The jar files that come with the SDK are stubs; they do not include much of the code that you see when browsing the source at android.git.kernel.org. (See this thread, for example.)
What in particular were you interested in using?