I have had a look at the samples for the calendar API, and find it somewhat
amusing/tragic that each of the samples has its own package where concepts
like . OK, they're on the small side. And yes, there are some minor
differences between implementations - for example, the CalendarFeed class:
For the sample targeting Google Apps Engine:
void appendCalendars(List<GwtCalendar> result) {
for (CalendarEntry entry : calendars) {
result.add(entry.toCalendar());
}
}
For the sample targeting an OAuth client:
@Override
public List<CalendarEntry> getEntries() {
return calendars;
}
For the sample targeting Android:
@Key("entry")
public List<CalendarEntry> calendars = new ArrayList<CalendarEntry>();
These differences are superficial - they're all getting a list of
CalendarEntry. The only other concrete method in the CalendarFeed was
identical across all 3 versions. So it would seem that each time you use
the google-api-client-java library to access a particular Google API, you
are doomed to recode boilerplate specific to that API as part of your
project. I mean, what use is an API to access a spreadsheet that doesn't
have a notion of a Cell?
It's well (being polite, naturally) an odd approach to code re-use.
Now I've only taken a fairly cursory look, and perhaps there are some good
architectural reasons why you'd want this flexibility in your client code.
But it does feel a little like all the benefits of the thinner API are
enjoyed by those providing it.
Maybe someone can enlighten me? Anyone hooked on google-api-client-java?
