Is there a way to detect a user pausing a run/activity within the strava API?
With Get Activity Streams (getActivityStreams) you can obtain differents StreamSet from your activity: in order to detect pause I think you can analyze CadenceStream or MovingStream.
Pauses are not available in the Strava API and can not be extracted consistently through algorithmic processing of the available fields. Moreover, the data contained in the API's streams collection can not be processed in a way which will arrive at the summary distance or time of the run.
The MovingStream contains a bit field which does not flag pauses, but instead (presumably) flags points where the athlete stopped moving. Although, that said, this field can not be used to arrive at the Moving Time by summing up the time values where this flag is true.
Related
I've recently started working with ksql and wanted to check if someone can help me with a query design. The problem statement is that I have a video conferencing app where a broadcaster can start and pause the stream multiple times. I want to get the total played time and the total paused time for that stream. I have a click stream data which consists of start and pause timestamps. How should I go about it so that I can generate an optimized view.
Any help is very deeply appreciated :)
Thank You
Grouping events
The first problem you'll need to solve is how are you going to group start/stop events together?
Likely, you'll want to group them by some kind of USER_ID or other attribute that uniquely identifies the broadcaster that's starting/stopping the stream.
Likely, you'll also want to group by the some kind of STREAM_ID or other attribute that uniquely identifies the stream being played.
This may be sufficient, it you only want the total play time per-broadcaster, per-video. However, you may also want to take time into account. For example, if I watch a video today, and then watch it again tomorrow, is that two viewing sessions, with two independent view time totals, or do you not care?
One way of grouping events in time is using session windows. Before you sessionize the data you'd need to define the parameters that define your session. Here's a good example of using session windows in ksqlDB.
Another way of grouping events in time is using tumbling windows. Here's a good example of using tumbling windows.
Calculating play time
Once you've grouped your events, you'll likely need to calculate the play time. For example, if I start playing at time 5, and stop playing at time 8, then the amount of time I was watching the video is 5 - 8 = 3.
This requires capturing the play event and waiting for the stop event, and then outputting the difference in time. And doing some in a fault tolerant way.
At the time of writing, this would require a custom UDAF (custom user defined aggregate function).
A custom UDAF could capture the start event, store it for future reference, and output a '0' for the play time, and then when it sees the corresponding stop event it can remove the start event from its state, calculate the play time and return it.
Here's a good example of writing a custom UDF in ksqlDB, though you require a custom UDAF, which are covered here.
There is currently a PR open with an enhancement to the LATEST_BY_OFFSET method that may well serve your purpose. This enhances the method to allow it to capture the last N value, rather than just the last 1 value. Likely, this will be released in ksqlDB v0.13, and you can always pull the code and compile it locally, if you have any development experience. If it doesn't serve your purpose, then you may be able to use it as the starting point for developing your own.
Of course, these solutions requires your stream of source events to be correctly ordered, so that stop events never come before their associated play events.
Aggregating
Once you've calculated the play time between a pair of start/stop events, you'll then need to aggregate them. Here's a good example of how to aggregate in ksqlDB.
We've recently started adding programmed radio to our existing SMAPI implementation. I've followed the Sonos Developer documentation and (eventually) got it working as expected. I'm just seeking for some clarification around the 'auto updating' based on the 'queueVersion' value.
Our schedules which are feeding the programmed radio can change from time to time. These changes should be reflected on the Sonos Players as soon as possible. For what I understand this should be possible by modifying the queueVersion property in both GET /context, GET /itemWindow and GET /version.
Looking at the GET /version documentation I see that Players "[...] are responsible for periodically polling this [QueueVersion] value to detect changes in the cloud queue track list, [...]".
I've monitored our API logs for about 15 minutes in which I would expect at least a GET /version request, but none showed up. The only calls I'm seeing are POST /timePlayed.
Can anyone (from the Sonos team perhaps?) clarify what this interval is set to, or how it can be controlled?
Given that you aren't seeing GET /version requests, there may be an error in your configuration.
The player sends a GET /version request every 5 minutes when paused and every 10 minutes when playing. This is by design, not depending on any setting that you can control. However, players fetch new tracks as needed using GET /itemWindow. The player requires a version in your response, so it doesn't send a GET /version request in this case. After the player gets a new item window, it resets the polling interval to another 10 minutes.
See the Play audio (cloud queue) page for details.
I’m developing a small game where the player owns droids used to perform some automated actions. The easiest example is giving an order to a droid to send him at a specific position. Basically, the users gives it a position and the droid goes there. I’m already using a lot Azure app function and I’d like to use them to make the droid moves.
On the top of my head, I thought about making one function that would trigger every minute, fetch all the droid that need to move then make them move.
The issue with this approach is that if the game is popular, there could be hundreds of droids and I have to ensure that the function execution time stays below the minute.
I thought about just retrieving all droids that needs to move then for each of them calling a Azure app function via its URL to make it execute for this particular droid. In my head, it would parallelize the execution a bit but I’m not sure I’m correct.
I also have to think about using sql transaction or not in order to be sure not to create deadlocks.
The final question would be « how to handle recurring treatment of potentially large amount of data and ensure that it stays below the minute ? »
Thanks for your advice
Typically, you handle such scenarios with queues. Each order becomes a queue message, and then Azure Function is triggered by it and processes the order. It can and will scale based on the amount of messages in the queue.
If your logic still requires timer-based processing, the timer should be as lean as possible, e.g. send the queue messages to a queue which would do the real work.
In an iOS app, I'm writing a class that will be messaged, go do a background request (via performSelectorInBackground:withObject:), and then return the result through a delegate method (that will then be displayed on a map). Everything seems to work right when one request is happening at a time, but I'm trying to figure out how to handle multiple overlapping requests. For example, if a user enters something in a search box that starts a background thread, and then enters something else before the initial background thread completes, how should this be handled?
There are a few options (don't let the second request start while the first is in progress, stop the first as soon as the second is requested, let both run simultaneously and return independent results, etc.), but is there a common/recommended way to deal with this?
I don't think there's universal answer to this. My suggestion is to separate tasks (in form of NSOperations and/or blocks) by their function and relationships between them.
Example: you don't want add image resizing operation to the same queue with fetching some unrelated feed from web, especially if no relationship between them exists. Or maybe you do because both require great amount of memory and because of that can't run in parallel.
But you'd probably want to add web image search operations to same queue while canceling operations of the same type added to this queue before. Each of those image search operations might init image resize operation and place it into some other queue. Now you have an relationship and have to cancel resizing in addition to image search operation. What if image search operation takes longer than associated resize operation? How do you keep a reference to it or know when it's done?
Yeah, it gets complicated easily and sorry if I didn't give you any concrete answers because of uniqueness of each situation but making it run like a Swiss clock in the end is very satisfying :)
Using the iPhone and objective C, is there a way to stall or perform a timing loop to allow for the GPS to catch up and return a valid set of coordinates?
Currently, the application runs too quickly and the GPS cannot supply the coordinates fast enough...
Since you said you're on iPhone, you're using CLLocationManager. Just set a delegate on the manager and wait for the locationManager:didUpdateToLocation:fromLocation: message to know when the GPS data is ready.
Assuming your GPS polling is running in a different thread to the User Interface, you can call the static NSThread functions sleepForTimeInterval or sleepUntilDate from the thread that is waiting for the GPS data.
If your mobile application is using GPS, your application should be prepared for location updates, even if your application doesn't track movements..
A common case would be where the user put your application in background and activate it later on a completely different location.
On iOS, create an implementation of CLLocationManagerDelegate like Anomie wrote. And use the timestamp of the update to evaluate the freshness of the location.
Don't sleep & poll like other people suggested.
Either block to wait for data or don't update anything if no data received. There is of course usleep(), but without showing code and specifically how your loop is executed and by what mechanism (threaded or not) we can only answer in general terms.