Background continuous access to a users live location - telegram-bot

I want my TG bot to have continuous access to a user’s live location. Is this possible?
I understand that TG can be given continuous access - but it seems to me that this privilege is not relayed to bots running on TG. Is this correct?
For the record, I don’t have a problem with an additional pop up requesting for such a permission.

As you can see here :
sendLocation:
Use this method to send point on the map. On success, the sent Message is returned.
So the user can share it's location via bot.
But you are looking for "Live Location" right? so you can do it :-)
Period in seconds for which the location will be updated (see Live Locations, should be between 60 and 86400.
86,400 Seconds / 60 Seconds = 1,440 Minutes.
1,440 Minutes / 560 Seconds = 24 Hours
So you can have live location of your user but there is only "24Hrs" limit.
Thanks in advance

Related

Google Calendar API gives 403 Quota exceeded error when limit is not exceeded

I have a problem with the Google Calendar API.
We are using the API with OAuth2 authentication in Python code.
It was working fine for about three years, but after today, it started to output the following error log.
<HttpError 403 when requesting https://www.googleapis.com/calendar/v3/calendars/**********************/events?alt=json returned "Quota exceeded for quota metric 'Queries' and limit 'Queries per day' of service 'calendar-json.googleapis.com' for consumer ‘project_number:*************'.">
However, the above log is not always output, and the error rate is about 30%.
We have set the allocation limit to 1,000,000, and there are about 3,000 queries for 24 hours.
Even though the number of times per day has not reached the limit, we are being told to use up our Quota for the day.
The API methods we are using are as follows
calendar.v3.Events.Insert
calendar.v3.Events.Get
calendar.v3.Events.Update
Delete calendar.v3.Events.
calendar.v3.CalendarList.
List calendar.v3.Calendars.
List calendar.v3.Acl.
Calendars.Insert calendar.v3.
Calendars.v3.Events.Insert is requested about 2000 times in 24 hours.
Calendars.Insert has been requested 2 times in 24 hours.
Has anyone encountered this before?
Thank you.
We have the exact same problem here.
Everything was working fine and suddenly starting this morning we have these 403 errors (RateLimitExceeded) coming up, with a 50% rate.
Our API usage is exactly the same as before. Our quota sits at 600 requests/minute/user and 1000000 requests per day. All we do is manual, so I don't see how we got past that limit suddenly...
It looks like other people have the same problem, it must be a bug in Google APIs.
The bug has been reported to Google already, see here: https://issuetracker.google.com/issues/182497593
I suggest you star this issue and wait for Google's answer.

How to get a list of the 10 top closes users by driving directions without incurring Google API Costs

If I have a Database of 50,000 users with there address and every time a new user is created the want to see who are the top 10 closes users by driving distance.
Google starts charging 50 cents for 1000 requests. I'm looking a better may to do this that would limit my costs.
Also is there a better way then having to run the API against all 50,000 users every time a new user is added?
At first you may select closest users by the direct distance. You don't need paid functionality for that.
Let's say 20 would be enough bacause it's very unlikely that so many addresses will be the closest by distance but farther by driving route than others.
In that case you need only 20 requests to check the users closest by route.

Google Fabric: Time in App vs Session Length

Can anyone explain the difference between the "Time in App" vs "Session Length" metric?
The Time in App metric started showing up as a metric in May 2017 and is significantly higher than the Session Length metric, so they are clearly different, but it's not clear as to how.
Mike from Fabric here. "Session length" is the median length across all daily active users. A session is considered complete when the app has been sent to the background for more than 30 seconds. Time in App" is a measure of how long the typical daily active user is active in the app on a specific day.
A user could, and often do, have multiple sessions in a day which would then be included in the time in app. For example, if I look at a calendar app for 30 seconds each time, I use, but I use it 6 times a day, then my time in app would be 3 minutes, but my session length would be 30 seconds.
Reference: https://docs.fabric.io/apple/answers/answers-metrics.html

Google Classroom API suddenly returning quota errors

I have routines that synchronize Class/Roster information between an SIS and Google Classroom. Everything has been running smoothly until very recently (11/1/2016). Now we're seeing the following message in all of our log files for routines that handle Classroom syncs.
Insufficient tokens for quota group and limit 'DefaultGroupUSER-100s' of service 'classroom.googleapis.com', using the limit by ID...
We perform batch requests whenever possible and these errors are showing up in individual batch "part" responses. The fact that these errors suddenly started showing up for ALL of our Classroom routines makes me think that something changed on the Google end of things.
I've been playing around with the throttling on our end by changing both the number of requests that we send in each batch (docs say that you can send 1000 per batch) as well as the total number of requests/batches that we're sending per 100 seconds (docs say you can send 50/s/client and also 5/s/user). Interestingly, the quotas indicated in the development console display slightly different but I assume they are to be interpreted in conjunction with one another.
I've throttled things down to the point where we're not even getting close to 5 requests per second and I'm still getting these errors back from the server.
Can someone provide some suggestions or solutions. Has anyone experienced this lately?
Let me know if I any additional information is needed.

Simple explanation of Twitter rate limits on "per user" and "per app" basis

I've searched Google and the Twitter documentation for a very straightforward answer for how the following scenario would play out. Specifically, I'm wanting to understand how Twitter's rate limiting works on a "per user" and "per app" basis. Can someone take a look at the example below and explain to me what would happen. And please don't just refer me to a Twitter documentation URL! Thanks in advance.
Example:
The "GET friends/list" API call is currently limited to 15/user and 30/app within the 15 minute window (See https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list).
If I have 4 users who all make the "GET friends/list" API call 10 times each within a 15 minute window (i.e. 40 calls made) does that mean I violate the 30/app limit? I'd still be within my limits for each of my 4 users, but do their individual calls eat away at the app limit too? Or is the app limit entirely separate and related solely to my app's token/secret?
The number of users (aka user tokens for your app that you've saved in your app store/config) give you that many times the specified per user limit (different for different APIs) for your app.
In your example, you're well within your limit if you make 10 calls per 15 minutes per user to the 'GET friends/list' API call since you have 60 (4 X 15) calls you can make per 15 minutes.
App limit applies if you don't have user tokens via user authZ/consent and are calling in application context only.
You should try your scenario with a 15 minute sleep after iterating over the 4 users and making 10 (upto 15) calls each in the user context (on the user's behalf) and you'll see that all works fine.