I developed my java code using awt classes. When I copied this code to my Android project I was getting errors. So I added JRE system library to the build path. Will it work now?
No. The Android UI isn't built on AWT. (A few AWT classes are available, but not many - fonts, basically.) You should only use the libraries listed in the Android developer documentation.
No when you move it to an Android platform.
Android is a language that uses the Java syntax/keywords but implements a different API. As long as they could the kept it and copied it (see the more common classes like java.lang.String), but sometimes they could not
If the class is missing in Android emulator it will be missing in the device, and more likely that not you will not be able to port it.
Related
I was trying to look at the sources of some AOSP classes like:
"android.com.android.server.am.DumpHeapProvider" (i then found the source inside this repository and looked at it online: https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/am/DumpHeapProvider.java), so I tryed to import the class inside a new project created with AndroidStudio and I immediately noticed that AndroidStudio didn't found the class...
So I was wondering if AOSP classes and its packages are somehow "external" things that should be downloaded and imported in you project before they can be used, just like a library.
It sounds weird because searching for AOSP gets me to a sentence which states that AOSP is composed by android OS and middleware, so I was expecting its libraries to be part of Android SDK, which I downloaded with AndroidStudio...
What is the correct way to use these AOSP classes?
I tryed to import the class inside a new project created with AndroidStudio and I immediately noticed that AndroidStudio didn't found the class
The vast majority of the AOSP represents code for an operating system. Very little of it is part of the Android SDK, and very little of it is usable by an app.
I was wondering if AOSP classes and its packages are somehow "external" things that should be downloaded and imported in you project before they can be used, just like a library.
They are used to build an operating system.
What is the correct way to use these AOSP classes?
Build an operating system, such as Android.
I've installed VisualStudio 2015, Xamarin, and MonoGame 3.5. I'm going to build my XNA app for Windows UWP, iOS, and Android.
I've some libraries based on XNA... and I need to build them for the three target systems (Windows UWP, iOS, and Android), but no way to create a library for Windows UWP. I've tried to create a MonoGame Windows 10 Universal Project, but such a project cannot be converted to generate a DLL.
I've also tried to create a Class Library (Universal Windows) project, but then I was unable to add MonoGame.Framework to the references.
I've the same problem when creating a MonoGame Android Project... no way to switch to a library project. The only MonoGame project that can be modified to be a library project is MonoGame iOS Project.
That said, how can I create a class library based on XNA (MonoGame) to be used from UWP, iOS, and Android?
As far as I know you've only got 2 options here.
Portable Class Libraries
Shared Projects
I haven't really used Shared Projects much. The way I understand them is that they allow you to share code between multiple projects as if it lives in a library but it actually gets compiled directly into the referencing project. They can be thought of like advanced file linking.
Portable Class Libraries are a bit of a different beast. I've used them in the MonoGame.Extended project with great success, but it wasn't always easy. The way they work is to provide a subset of functionality that works on all target platforms. They compile to a DLL that can be referenced by any of the projects and you can be confident the code will be the same.
There are a couple of downsides of using a PCL:
you can only use a subset of functionality. Surprisingly, this doesn't get in the way too often.
if the PCL references another library, it also has to be a PCL.
The second point is where things get a little tricky with MonoGame. Typically, MonoGame isn't shipped as a PCL, but a PCL version has been published on NuGet that can be used.
As it stands right now, the NuGet package is a version behind the official release but surprisingly that doesn't really matter because it's a bait and switch PCL which essentially means it just provides the interface to the real DLL that gets used at runtime. In other words, your game will still happily reference version 3.5 even if the PCL is version 3.2 so long as the interface hasn't changed.
There is some talk about improving this situation in version 3.6.
I noticed MonoGame projects are built using .Net 4.5 by default. Regular class libraries default to the latest installed version of .Net which in my case was 4.5.2. I was able to reference a regular class library by going to its project properties and setting the target framework to 4.5. Hope this helps.
I'm using android-sdk-plugin to make Android apps with Scala using SBT. This generally works great - however when trying to import the project into IntelliJ IDEA 14.1 the imported project looks rather empty and does not recognize my source files as being part of the project.
The documentation says:
IntelliJ 14 now includes native support for importing projects from android-sdk-plugin. The process generally works well, however there are still several caveats:
The idea-sbt-plugin is still required to actually perform the build (no longer necessary as of IDEA 14.1)
Cloning and importing even the simplest example project results in an empty IDE not showing any sources at all:
I have installed both the Scala plug-in and the SBT plug-in (which I believe should no longer be required) as requested by the documentation.
What essential step am I missing?
Edit: I added the plug-in manually to project/plugins.sbt, then ran gen-android to get a project/build.scala containing object Build extends android.AutoBuild.
The essential step missing is the Android plug-in of IDEA. This might seem obvious but in contrast to plug-ins for other frameworks this one does not just provide extra goodies but is actually essential for anything Android.
Having the plug-in installed allows for selecting Android as a Project SDK (which not just selects an Android SDK but also a Java SDK to go with it).
I want to create a Java library like SLF4J which can run since certain Android version (e.g. Froyo/2.2).
The thing is, I can't be sure if some methods I use are already available on that Android version. For example, "String".isEmpty() is not available in Froyo. How should I know this, unless I create the library project as Android Library project?
Making the project as an Android library project is not easy to test. Robolectric is also tricky with Gradle.
I'm expecting something like simple Java Maven project which uses subset of Java API available in certain Android version. Is it possible? Like, I create a new SLF4J library without involving non-existent methods in Android.
Thanks
It's possible that there are differences between the Android SDK and other Java APIs, so if you build and test your code as anything other than an Android library, you may miss problems. For example, just the other day I found a bug in API 19 (Android 4.4) where DecimalFormat produces BigDecimals differently than it does in J2SE SDKs.
But if you must do this, the easiest way is probably to create it as an Android library project and build it against the Froyo SDK to ensure all the methods are available. Then take the same code and create different build files to build it for your preferred test framework.
I'm new to Android development and I wonder if I can use some Java packages (for instance javax.xml.bind, org.springframework or org.jooq) on Android platform despite the fact they are not listed on packages list of Android API. Is it possible when I simply import them as external JARs? At this moment I don't care if they are big, just if they can work on Android.
Thanks for help.
It Depends.
Android is built on a subset of Java 1.6. If the library uses references to classes that Android doesn't have, I believe the ADT plugin will give you an error about system level libraries WON'T work on Android. Something to that effect.
I wouldn't recommend it. The guys at Android included libraries that they knew worked with their system (and probably modified them).
Just importing a Java library that isn't part of the Android API and isn't written specifically for Android probably won't end well.
There are a lot of differences between mobile and Desktop computing.
As recommended by TeamMCS, try to import your librairies in your Android project. That's what we done with a SOAP client library and we saw that it depends on other Java librairies; librairies that are present in the standard JRE (i.e. Sun JRE on computer) but not provided with the Android OS.