Fixed
Status Update
No update yet.
Comments
et...@google.com
se...@gmail.com
[Comment deleted]
xy...@gmail.com
Please also add
getAllEvents()
(without "startTime" and "endTime" parameters)
getAllEvents()
(without "startTime" and "endTime" parameters)
et...@google.com
A getEventById method would be an optimal alternative to cycling through all events retrieved with a date range, which is the only method possible on GAS currently.
ma...@martin.st
Does this mean that if you declare this new feature field, it won't be installable on older devices at all, or can this work cleanly with compatibility with older devices? Or is it only an issue with the Google Play app? Anyway, I guess you can't comment too much on it until it's out anyway, so we can only wait and see.
et...@google.com
I concur with Greg.
ma...@martin.st
There has continued to be interest in the original report of this issue, which should have been here. I count 11 notes added to
This is still an issue, and should be addressed.
This is still an issue, and should be addressed.
ma...@martin.st
I, too, could use/need getEventById(). I was part of the previous thread (#395) that was closed as completed. I'm glad to see that people are still asking for this.
hb...@gmail.com
+1
I am coming from:
Google, all I'm really looking for is clarity.
If you say, "tough noogies, use getEventSeriesById" that's fine. Make it clear in the documentation.
Are we missing some core concept of the Event and Event Series interaction? Does this just need a better explaination and use cases?
As it is it just seems like there is a gaping hole of: "HEY LOOK. There should be a function here but we do not support that concept." Please make it clear or let us know that you plan to implement the feature.
That said, I do support the implementation of the method instead of using a workaround.
I am coming from:
Google, all I'm really looking for is clarity.
If you say, "tough noogies, use getEventSeriesById" that's fine. Make it clear in the documentation.
Are we missing some core concept of the Event and Event Series interaction? Does this just need a better explaination and use cases?
As it is it just seems like there is a gaping hole of: "HEY LOOK. There should be a function here but we do not support that concept." Please make it clear or let us know that you plan to implement the feature.
That said, I do support the implementation of the method instead of using a workaround.
ma...@martin.st
I would imagine that offering a getEventById to allow setTime,etc would outway the consumption of server traffic for deletion and new allocation of resources.
Not only did the lack of clarity generate frustration, but no birthday cake for a year=old issue really topped it off!
It's at times likes these that my five year-old's wisdom rings loud: "It's not hard!"
Not only did the lack of clarity generate frustration, but no birthday cake for a year=old issue really topped it off!
It's at times likes these that my five year-old's wisdom rings loud: "It's not hard!"
hb...@gmail.com
getEventSeriesById isn't the same result as a potential getEventById
an alternative could be getEvents(start, end, {id: eventId}) of course…
an alternative could be getEvents(start, end, {id: eventId}) of course…
ma...@martin.st
Same story here.
This is a bit complicated and unnecesasry:
var events = CalendarApp.getDefaultCalendar().getEventsForDay(date);
for (var e=0; e<events.length; e++) {
if (events[e].getId()==id) {
var event = events[e]
var title = event.getTitle();
var end = event.getEndTime();
var start = event.getStartTime();
var desc = event.getDescription();
var id = event.getId();
var loc = event.getLocation();
var day = start.getDay();
var thisevent = {"title":title,"start":start,"end":end,"location":loc,"id":id,"desc":desc};
}
}
ma...@martin.st
A year and a half later, is there still no solution for this?
et...@google.com
w....@gmail.com
For anyone who isn't ready to switch from CalendarApp to the Advanced Calendar service, there is a getEventById() function provided in this answer:
http://stackoverflow.com/a/30657751/1677912
et...@google.com
Merging with existing issue.
ho...@gmail.com
I hope this work
ho...@gmail.com
35166
Description
Issue:
According to the articles above, Android is defining the uses-feature "android.hardware.camera" to mean rear-facing cameras only. Devices with a front-facing camera only, like the Google Nexus 7, will not appear to be supported by the app. This means the app will not appear in Google Play for that device.
This breaks backwards compatibility for many apps (QR code scanners in my case) and will require developers to remove this requirement if they want to support front camera only devices. This will require run time checks for hardware, UI messaging the user that their device is not supported, localization and re-testing expenses, and a bad customer experience. "Sorry, your device is not supported even though we said it was on the Play page." is not a good experience.
Suggested solution:
1. Define "android.hardware.camera" to mean ANY camera, including future development of externally attached devices.
2. Add new feature fields of "android.hardware.camera.rear" and "android.hardware.camera.front" to explicitly refer to those positions.