I'm experiencing issues with the Google Calendar API.
When deleting an event instance that instance belongs to a recurring event made from an RDATE I never get consistent answers of if it is deleted (read "cancelled") or not.
From my experience the after event instance is deleted via the API the status becomes "cancelled" as you would expect. But I can only see/confirm this if I do an API GET call.
If I do an Google API List call (getting all the instances) show the status is always "confirmed" and the event instance appears whether or not showDeleted is true or false.
Also if I do an API instances call on the master recurring event... they all show "confirmed"... none display "cancelled"... yet I know I deleted one and GET gets the result.
Does anyone else have this issue? Or have a solution. (and EXDATE is out...as I don't affect other event instance data stored which gets wiped if I change the recurring rule...)
Related
I have a recurring event created in Google Calendar.
How can I accept all the future events ("this and following events") for a guest using Google Calendar API?
I found only examples where responseStatus was set for the entire event (all instances) or for a single instance.
I can't follow the solution from: https://developers.google.com/calendar/recurringevents#modifying_all_following_instances, because only event's creator is allowed to modify recurring rule of the original event - I have access only to guest's account.
Since you cannot update the recurrence rules of the main event, you can do the following instead:
Using the eventId of the recurring event, call Events: instances to list all the instances of the event.
Filter the returned instances according to their start and/or end dates, so that past events are removed from the list.
For each of the remaining events, call Events: patch in order to update the attendee's responseStatus, this status being:
The only event change that is propagated from attendees back to the organizer
It seems that currently, in-app messages triggered by events only respond to the occurrence or not of the event. One of the richest event in an app is screen_view, which would only be helpful when using the values stored as parameters of the event.
Is there any workaround to do it?
What I'd like to achieve is this:
A user opens any screen in the app, triggering the screen_view event, with the firebase_screen_class parameter specified (this is triggered automatically by the iOS api as far as I'm concerned).
An In-App Message is triggered when that specific event is triggered with an specific value in a parameter.
I explored two options:
Firebase in-App Message is set to appear when an event with an specific parameter value occurs.
Event is captured using Firebase Cloud Functions, triggering the In-App message when the parameter condition is met directly from the function.
Unfortunately I haven't find anything in the documentation, nor in Google or Github that makes me thing this is possible yet.
I was looking for the same thing and reached out to Firebase support. Here's what they told me
Currently, it is not possible to use a specific event (e.g
screen_view) with a specified parameter (e.g firebase_screen) as an
event trigger for Firebase In-App Messaging. As a workaround, to use
the specific parameter for FIAM targeting, you may define it as an
audience first to be able to target it on the composer.
I did not adopt their workaround, but I tried doing the below and it worked for me:
Create an extra Firebase event tag via GTM, set action as "Add Event", and define an event name for it e.g. "screen_a". This is triggered upon your desired combination of event_name and firebase_screen_class value
In Firebase Console, set the FIAM to be triggered by the event name you have defined in step 1 (i.e. screen_a)
I have kind of a tricky question without an answer (I went through the documentation but did not find what I was looking for) :
I am tracking two specific events in my app, one is the start of a GPS tracking, the other one is the stop event. In Firebase Analytics, I am able to select those events in order to create an audience.
The audience I want is when an user triggers the start event of the GPS tracking process, but does not go through the whole process and does not trigger the stopevent.
So basically when I create the audience I have to select both startand stop event, but the thing is I actually have no value assigned to those events. For the moment, as a test case I told the audience to track if start > 0 and stop <= 0.
I suppose it is not going to work as expected. How should I track the event in the Android app, and how should I retrieve it in the audience creation ? By default, is my start event value is the number of times the event triggered ?
Thanks in advance,
Your question does not mention which SDK you are using (Android, iOS, etc. please make your question more precise) - I will assume it's Android.
When logging an event, you can set parameters. A parameter is made of a key and a value. If you want a value assigned to your event, you must use a predefined key : FirebaseAnalytics.Param.VALUE. In this case, the value is accumulated automatically for each event type.
The following snippet will do the work for your start event, stop will work the same way of course :
private void logStartEvent() {
Bundle bundle = new Bundle();
bundle.putInt(FirebaseAnalytics.Param.VALUE, 1);
firebaseAnalytics.logEvent("start", bundle);
}
Then you should be able to create an audience with start > 0 and stop <= 0
Hope this helps.
I've been trying all day to figure out how to "rehydrate" instances of a recurring event from my app.
Let me explain the flow real quick:
User grants access to my app to edit their calendar
The app sets up a recurring event
The app subscribes to the /watch endpoint for that calendar
So far so good, now when the creator moves that event to another time, I get a notification on the webhook url, which is fine (well, sorta), it looks like this:
'x-goog-channel-id': 'my_specified_channel_id',
'x-goog-channel-expiration': 'Thu, 29 Sep 2016 12:58:10 GMT',
'x-goog-resource-state': 'exists',
'x-goog-message-number': '333384',
'x-goog-resource-id': 'some-resource-id', // This id apparently has nothing to do with any resources I know of
'x-goog-resource-uri': 'https://www.googleapis.com/.../resource-uri'
So I would figure that I could call https://www.googleapis.com/calendar/v3/calendars/primary/events/some-resource-id and get the updated resource, but the resource-id doesn't seem to have anything to do with any events in the calendar, nor is it the id of the calendar itself (I use the 'primary' keyword)
So I thought, I could as a work-around get all the instances of the recurring event using the https://www.googleapis.com/calendar/v3/calendars/primary/events/recurring-event-id/instances endpoint, but now the event that was moved is no longer part of that payload anymore. I'm guessing google removes the event from the parent event because it doesn't happen at the same time of day anymore (I haven't been able to confirm this anywhere)?
So what I'm asking is:
Am I interpreting x-goog-resource-id wrong?
Can someone confirm that once an event is edited from the google calendar app it looses its relation to the recurring parent event?
To answer my own question:
x-goog-resource-id is the identifier of the calendar, as that is the entity you're putting the watcher on
Once an event that is part of a recurring set is edited, it is no longer part of that set
I have 2 "limit" queries on the same path. I first load a "limit(1)", and then later load a "limit(50)".
When I load the second query, the child_added events don't fire in-order. Instead, the last item in the list (the one returned by limit(1)) is fired first, and then all of the other items are fired in-order, like this:
**Limit 1:**
new Firebase(PATH).limit(1).on('child_added', ...)
Message 5
**Limit 2:**
new Firebase(PATH).limit(50).on('child_added', ...)
Message 5
Message 1
Message 2
Message 3
Message 4
I'm confused why "Message 5" is being called first in the second limit operation. Why is this happening, and how can I fix it?
I know this may seem strange, but this is actually the intended behavior.
In order to guarantee that local events can fire immediately without communicating with the server first, Firebase makes no guarantees that child_added events will always be called in sort order.
If this is confusing, think about it this way: If you had no internet connection at all, and you set up a limit(50), and then called push() on that reference, you would you expect an event to be fired immediately. When you reconnect to the server though, it may turn out that there were other items on the server before the one you pushed, which will then have their events triggered after the event for the one you added. In your example, the issue has to do with what data has been cached locally rather than something written by the local client, but the same principle applies.
For a more detailed example of why things need to work this way, imagine 2 clients, A and B:
While offline, Client A calls push() and sets some data
While online, Client B adds a child_added listener to read the messages
Client B then calls push(). The message it pushed triggers a child_added event right away locally.
Client A comes back online. Firebase syncs the data, and client B gets a child_added event fired for that data.
Now, note that even though the message Client A added comes first in the list (since it has an earlier timestamp), the event is fired second.
So as you see, you can't always rely on the order of events to reflect the correct sort order of Firebase children.
But don't worry, you can still get the behavior you want! If you want the data to show up in sort order rather than in the order the events arrived on your client, you have a couple of options:
1) (The naive approach) Use a "value" event instead of child_added, and redraw the entire list of items every time it fires using forEach. Value events only ever fire for complete sets of data, so forEach will always enumerate all of the events in order. There's a couple of downsides to this approach though: (1) value events won't fire until initial state is loaded from the server, so it won't work if the app is started in "offline mode" until a network connection can be established. (2) It inefficiently redraws everything for every change.
2) (The better approach) Use the prevChildName argument in the callback to on(). In addition to the snapshot, the callback for on() is passed the name of the previous child in in the query when items are placed in sort order. This allows you to render the children in the correct order, even if the events are fired out of order. See: https://www.firebase.com/docs/javascript/firebase/on.html
Note that prevChildName only gives the previous child in the query, not in the whole Firebase location. So the child at the beginning of the query will have a prevChildName of null, even if there is a child on the server that comes before it.
Our leaderboard example shows one way to manipulate the DOM to ensure things are rendered in the proper order. See:
https://www.firebase.com/tutorial/#example/leaderboard