0

I have an object which contains some package-private member variables and I'm adding them to a Google Sheets v4 ValueRange in another object. The current code looks a little bit like this:

List<List<Object>> data = new ArrayList<>();
... 

/**
 * Sets all the values in the ValueRange member variable
 * @return the ValueRange object
 */
ValueRange requestBuilder() {
   ...

    //For each case, add it to the value range
    for (int i = 0; i < closedCases.size(); i++) {
        data.add(
                Arrays.asList(
                        closedCases.get(i).number,
                        closedCases.get(i).priority,
                        closedCases.get(i).firstResp,
                        closedCases.get(i).accName,
                        closedCases.get(i).subject,
                        closedCases.get(i).assigned,
                        closedCases.get(i).lastUpdated,
                        closedCases.get(i).daysOld,
                        closedCases.get(i).jiraCase
                )
        );
    }
    vr.setValues(data);
    return vr;
}

The question that I'm seeking to answer is, is there any way to do Arrays.asList( closeCases.get(i) ) or add some kind of method on the case object to simply fill all that stuff in, rather than calling out each member variable in the Arrays.asList(). I'm also aware I can use a foreach, but would still need to use the same notation for adding items, which is what I'm trying to avoid.

In case anyone is interested, closedCases is just an ArrayList of an object with some strings and doubles in it.

A_Elric
  • 3,508
  • 13
  • 52
  • 85
  • 1
    There are other ways to do it, but all of them will require having a list of those attributes somewhere, so there is no *shorter* way to do it. – VGR Nov 12 '19 at 19:59
  • Code will clearly benefit from not repeating things nine times, like the `closedCases.get(i)` expression. That’s what local variables are for. Or, as you said yourself, you can use foreach. That alone would halve the code. In contrast, `Arrays.asList` will not add entirely unrelated fields to a list. What kind of logic should determine which fields to include in which order? – Holger Nov 13 '19 at 13:41

2 Answers2

1

You somehow need to specify what fields go into this list, in what order. If you want to capture all fields, you could use reflection to iterate over the object (potentially choosing declared, not inherited fields, and potentially choosing only package-private fields), as described here.

But that is not the idiomatic way to do it in Java.

Can you change the definition of the "object which contains some package-private member variables" so that instead it has a Map with key-value pairs?

Joshua Fox
  • 18,704
  • 23
  • 87
  • 147
  • Unfortunately the object mapping is fairly static due to the insanity that is the SF api, though I'm often asked to add / remove stuff from these reports, so adding fields / removing them on the object and the openCases / closedCases objects fairly often. I didn't know of a way to do this without reflection which isn't something I want to do for maintainability. Thanks for the answer. – A_Elric Nov 12 '19 at 19:56
  • @A_Elric to that end, why dont you use an object mapper to convert your case object to a map and then just use java8 stream to generate a list? – Kaus2b Nov 12 '19 at 20:04
  • 1
    Mind that Reflection makes no guaranty about the order of the reflected members. You’d still need to enumerate the names of the desired fields somehow. – Holger Nov 13 '19 at 13:55
1

You could add a List field in the object that is held by closedcases and call that field from inside the loop.

For instance, say the object is Foo,

Inside foo, create a field:

ArrayList<String> allFields = new ArrayList<String>{number. priority …… };

Method:

public ArrayList<String> getAll() {
    return allFields;
}

And from inside the loop, just do

data.add(closedCases.get(i).getAll());

If the fields are not just string, you could create different arraylist that holds different types of object, which will increase the list again but could be substantially less that what you gave us.

spinyBabbler
  • 392
  • 5
  • 19