GabiAxel
commented
8 years ago Thanks for contributing.
If you want to have a non-default constructor for deserialization, you need to add JsonConstructor on it. I chose not to use non-default constructors because it looks really cumbersome for large amount of parameters, didn't want to make the client code have nulls for every parameter it doesn't need, and didn't want to deal with changing the constructor signature or add another constructor when new versions introduce new parameters. Also, for update operations you would need setters anyway.
A good practice when a class has a lot of properties could be to add a builder. See DriveFile for example.
The calendar was WIP and I didn't get to finish it, so I welcome your help, and do feel free to change things you think should change according to your experience with the Calendar API. Just try to stick to the conventions of the rest of the project.
Hello,
I've been implementing support for inserting events: https://developers.google.com/google-apps/calendar/v3/reference/events/insert
I'm a relatively junior developer so I figured I would ask some questions before making a pull request. The idea is to be able to say
Event responseEvent = google.calendarOperations().insertEvent("primary", newEvent, false);with newEvent being a locally constructed org.springframework.social.google.api.calendar.Event.I was unable to implement that without making Event 's constructor public, and adding a bunch of setters to the Event object and it's related inner classes. Is that bad practice? I can see that Event was initially protected to ensure that an Event had to be pulled from a calendar, is there any other architectural reason to leave it that way?
My code can be found here on the "insert_event" branch: https://github.com/LukeDowell/spring-social-google/tree/insert_event
Apologies if this isn't the correct place to discuss this, and thank you for your time!