I know it is a beta and all, but it is such a horrible beta... it is unbelievable, the hierarchy does not make any sense, when he needs to use inheritance they don't, when they uses it, it is an abuse of the hierarchy mechanism, the use of generics is absolutely wrong, and the use of virtual methods with or without generics is absolutely ridiculous, the code duplicate seem to never end, and the separation to projects seems to be correct but it is not!
I've investigated the API to its core... all the jars attached to the calendar-android-sample, I've attached all the sources to one project, and saw the reflective workaround used to load the classes, there was nothing sophisticated about it.
I've tried to understand how the API works to write a simpler implementation(I'm very good at that!), it is impossible... Google are right to publish their API as open source, why the hell to obfuscate the code if you don't need to ha...? why not just to make a darn mess and no one would be able to understand WTH it does...?
I've tried to avoid writing this, but it burns and upsets me and makes me sad a pile of code written this way.
So I've tried to change my approach... since I want the Calendar API, and I wanted to use it I've tried just to scratch the surface of the sample project... that has made me sad...
I've found the following row:
CalendarList feed = client.calendarList().list().setFields(CalendarInfo.FEED_FIELDS).execute();
can anyone guess WTH it does?
let me tell you, it is a Calendar instance returning a new instance of a CalendarList, which returns a List (not the one you think) of initialized results (which results???), for which you set a field values for the response, for which you have virtual method to cast the return value back to a List, and then calls... execute()...???
execute()????
execute()????
execute()????
execute()????
execute what on a darn list... can you explain...
ha... yes it inherits from a CalendarRequest with a generic parameter T, oh yes and T is a... wait T can be four different types, now I confused... there are:
- 1 Clear
- 1 Instances
- 1 Query
- 1 QueryAdd
- 1 Move
- 4 Inserts
- 4 Updates
- 4 Patches
- 4 Deletes
- 6 Gets
Don't you think there might be a better implementation than to override all the darn methods, and cast the return type!
I've always thought Google has the best minds working for them, I've also been to a lecture about the brilliant continues integration system they have build, and trust me it is brilliant, I've meet the guy who designed it, he is very keen, but this just goes to show me, that I my gut was right about not continuing with the attempt to work for Google, I would have for sure ended up resigning, because if this is the infrastructure they release, and I guess they are proud of their "success" (which 'sucks S') then they are lucky to have a lot of money, because it would cost them very much to keep it up!
I know the cost of bad code... I've tried to avoid it for long enough, everywhere I've worked, and seen what bad code can do to huge teams of development... the bottom line... it costs MONEY...
Luckily Google has enough of it :)
