Make use of Object Oriented Design in an Android App with multiple activities

Formal issues

Naming

As with any other language there are common naming conventions for Java. You should get to know them when you write Java code. You would expect other developers to do the same when they work in your preferred language.

e.g.: you have a method named Calculate(). This should start with a lower case letter (calculate())

You have variable names containing underscore like pressure_value, they should use camelCaseNaming: pressureValue

You use the abbreviation pres in one of your variable names. you better use the full word pressure here.

in your switch you have literal numbers in your case statements. You should better convert them to constants with expressive names like:

public class Temperature extends AppCompatActivity {
    private static final int NEWTON_PER_SQUARE_METER =0;
    private static final int PSI =1; // just guessing here... ;o)
    private static final int HECTO_PASCAL =2; 

eg.: your variable pressure_value should better be named userInputPressure and the variable spinner_pres should be named pressureUnitInput.

Then you have a parameter named position This should better be selectedPressureUnit.

In conjunction with the previous hint the switch would read like this:

        switch (selectedPressureUnit) {
                case NEWTON_PER_SQUARE_METER:
                    break;
                case PSI:
                    pressure = Float.parseFloat(pressure_value.getText().toString())/14.696;
                    break;
                case HECTO_PASCAL:
                    pressure = Float.parseFloat(pressure_value.getText().toString())/760.0;
                    break;
            }

Your variables hold physical values. It is a good idea to add the actual unit you expect the values to have.

Some famous space exploration missions crashed because on team processed length in ISO units (eg. kilometers) passing them to another teams unit which expected the value to have imperial unit (eg. miles).

The problem is that there is no technical solution to avoid that. And you won't expect a bug in this:

double length = someDependency.getLength();

But you might get alerted when you write (or read) this:

double lengthInKm = someDependency.getLengthInMi();

Comments

Comments should always explain why the code is like it is.

Other comment often lie as the first occurrence of your comment // Implement list de volume unit conversions does because after that you calculate pressure. This almost ever happens in code under development since nobody really feels responsible to update the comment while the code changes behavior.

Your comments structure the Method onCreate into logical sections. You should better extract those logical sections into separate methods with names derived from the comments you wrote. This would change the method to something like this:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_temperature);
    gatherValuesFromTextFields();
    implementListDePressureUnitConversions();        
    implementListDeVolumeUnitConversions();
    calculateTemperature();
 }

The code lines themself would move to that methods:

private void gatherValuesFromTextFields(){ // answeres your question from the code
    totalTextView = (TextView) findViewById(R.id.tempTxt);
    pressure_value = (EditText) findViewById(R.id.pressureTxt);
    volume_value = (EditText) findViewById(R.id.volumeTxt);
    moles_value = (EditText) findViewById(R.id.molesTxt);    
}

private void implementListDePressureUnitConversions(){  
    spinner_pres = (Spinner) findViewById(R.id.units_pressure_temp);
    ArrayAdapter<CharSequence> adapter_pres = ArrayAdapter.createFromResource(this,
            R.array.arr_units_pressure, android.R.layout.simple_spinner_dropdown_item);
    spinner_pres.setAdapter(adapter_pres);
    spinner_pres.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() {
        @Override
        public void onItemSelected(AdapterView<?> parent, View view, int position, long id) {
            switch (position) {
                case 0:
                    break;
                case 1:
                    pressure = Float.parseFloat(pressure_value.getText().toString())/14.696;
                    break;
                case 2:
                    pressure = Float.parseFloat(pressure_value.getText().toString())/760.0;
                    break;
            }

        }

        @Override
        public void onNothingSelected(AdapterView<?> parent) {

        }
    });
}
// and so on...

BTW: This is a (language independent) implementation of the OO principles Separation of Concerns (SoC) and Single Layer of Abstraction (SLA) which would even work in pure procedural C.

Making the code more OO

IMHO the major principles of OO are:

• information hiding/encapsulation
• Separation of Concerns (SoC)/Single Responsibility Pattern (SRP)
• Tell, Don't ask
• apply polymorphism instead of branching

The ultimate goal of this is to reduce code duplication, improve readability and support reuse as well as extending the code.

replace switch/if-else cascade with polymorphism

You have two switch statements in your code. They should be resolved to use polymorphism since this is one of the most powerful OO mechanisms.

In order to do this we could introduce an interface:

  public class Temperature extends AppCompatActivity {
      private interface UnitCalculation{
        double calculate(String userInput);
      }

Next we create a a list of known calculations:

private void implementListDePressureUnitConversions(){ 
   List<UnitCalculation> unitCalcualtions = Arrays.asList( 
      // pre Java8: anonymous inner class
      new UnitCalculation(){ // NO_SELECTION
        @Overwrite 
        public double calculate(String userInput){
           return Float.parseFloat(userInput);  // default unit
        }            
      },
      // Java8 Lambda, no semicolon at statement end, comma is list separator
      userInput -> Float.parseFloat(userInput)/PSI_QUOCIENT,
      // userInput -> Float.parseFloat(userInput)/14.696, // PSI -> broke my own suggestion
      userInput -> Float.parseFloat(userInput)/HECTO_PASCAL_QUOCIENT        
   );       
   // ...

then we use this list instead of the switch:

    spinner_pres.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() {
        @Override
        public void onItemSelected(AdapterView<?> parent, View view, int position, long id) {
         pressure = unitCalcualtions.get(position).calculate(pressure_value.getText()); // getText() already returns a `String` object.
        }
     }

You can do so for the volume respectively.

avoid code duplication / support DRY

Often you don't have pure duplicated code. In most cases you have similar looking code which you usually quite easily can change to equal code by simple refactorings and/or by applying design patterns.

This goes basically in 3 steps.

• identify similar code
• make similar code the same
• remove the duplication

Since this process is expected not to change the behavior of your application you should better have UnitTest that fix the desired behavior so that you get immediate response when you broke something.

The code for calculating pressure and and volume look quite similar but have certain differences. Most of them are obvious like the variable names used. But others are kinda "hidden": Eg.: both switch statements have 3 cases, but this is just an coincidence!

On the other hand: if you follow the polymorphism approach from above then the difference is only the content of the list. And this is a minor difference.

In this step you convert individual similar parts of your code to look exactly the same. Avoid typing as much as possible and rely on your IDEs refactorings like "extract to local variable", "rename in file" and alike.

Assuming you have created the separate methods and implemented the polymorphism approach:

We place the cursor on one of the member variables and apply the IDEs refactoring "extract to local Variable (replace all occurrences)". Move the line created by the IDE up to the beginning of the method.

Do this for all member variables so that at the top of the method you have only assignment to local variables and below that you only access local variables, not member variables. Place the List of the unit calculations directly below them.

Do this in both methods, implementListDePressureUnitConversions() and implementListDeVolumeUnitConversions() an make sure to use the same names for the local variables.

After that in one of the methods select all lines except the local variable declarations on top and the list. The apply the "extract method" refactoring of the IDE. It should replace the selected part in the current method and the corresponding part in the other method.

Following your suggestion to implement lists instead of switch statements, I get an error in the lambda expressions that says Float cannot be applied to , how can I solve this? – lorenzattractor

For the records: I suggested a Map, which is something different than a List. Please be exact in that to reduce misunderstandings.

The compile problem is cause by your original code where you assign a float value to a variable of type double. This was no problem since float is the smaller datatype an the compiler accepts this assignment as well as in the implemntation of the anonymous class. I didn't change that to make it for you easier to follow.

However with Lambdas the compiler does a lot of assumptions of what you might want to do. Therfore it cannot be that liberal with the type upcasting (float->double).

To solve this you should use the correct parser for your target datatype:

 Double.parseDouble(userInput)//...