Multi-platform java project, how to make classes depending on the environment

Question

Multi-platform java project, how to make classes depending on the environment

Navigation

#1 by (-1 votes)

0

I am trying to execute depending on the environment, in a previous question I was raised to use polymorphism as you can see in the following question . The problem I have is that in the android environment I need to execute the command getApplicationContext (), where I require it in the android environment only, the issue is that when I run the class in windows, I can not compile because the command is not recognized but is for the platform that was made. Then the idea that came up is in the android project, only the class that is for android will be included. The problem that arises is how to execute one class or another, depending on the environment. Here is an example I have in the project the breeding class of the question quoted, "Trimmed"

public class reproductor implements Runnable {
static reproductor getInstance() {
        //System.out.println("bfhsoftware.sonidoambiental.reproductor.getInstance()");
        if (main.isandroid()) {
            System.out.println("reproducir android");
            //return new Class.forName("bfhsoftware.sonidoambiental.Sonidoambiental");
return new ReproductorAndroid();
        } else {
                        System.out.println("reproducir java");                
            return new ReproducirJava();
        }
    }
}

Desktop class

public class ReproducirJava extends reproductor {
}

In a subproject I have the following class Android class

public class ReproductorAndroid extends reproductor{
}

obviously in the sub-project the classes of the main project are included and can be used, but otherwise when referring from the main project to a class that is outside the project, in this case the android sub-project, not I know how to call her, and here's the question. in this example it is visible that I call the PlayerAndroid class but being out of the project gives an error, the reason why I have to remove it is because of the aforementioned command, which runs only in the android environment, outside of this there is no function. For this and other reasons I need to place some extends classes of the main project, but I do not know how to call it, could someone help me? Explain me clearly enough?

java android

asked by Bernardo Harreguy 06.02.2018 в 23:19

source

1 answer

Error string-array android Error in Android studio layout [duplicated]

score -1 · Answer 1

The option that I use is a project defining the interfaces 1 to implement / use in the other projects:

proyecto IReproductor ->
  public interface Reproductor {
    public void play();
  }

proyecto ReproductorAndroid (depende de proyecto IReproductor) ->
  public class ReproductorAndroid implements Reproductor {
    ...
  }

proyecto MiApp (depende de proyecto IReproductor) ->
  public class MiApp {
    private Reproductor reproductor;
  }

When packaging the application, include the appropriate player jar to the platform.

What remains is to instantiate the classes. Here the best option 2 is to establish that all implementations must implement a particular constructor 3 (one that is widely used is the constructor without parameters) and invoke it using reflection . I suggest creating a Factory class with a method that provides the instances, to encapsulate the logic.

The name of the class to be instantiated can be passed in different ways:

hard-coded in the factory ,
ownership of the system,
file / BD / JNDI of the main application configuration,
configuration file in jar s implementation, read by getResourceAsStream ,
etc.

Finally, in Java EE all this mechanism is already automated with the CDI.

1 Better interfaces than classes or abstract classes. If a couple of implementations benefit from the existence of an abstract class, you can define that the abstract class implements the interface and that the implementations extend the abstract class.

2 Another possible option would be for all implementations to have exactly the same name and constructor and simply package one version or the other depending on the platform. Very ugly.

3 Be sure to document it in the Javadoc of the interface, and in the corresponding design documents.