I want to make an AJAX call for analytics purpose after user clicks on STOP CASTING and before receiver application actually shutdowns. Is there any message interceptor for STOP_CASTING? Or any other way to achieve this?
You cannot delay the stop casting behavior. There is typically a very small window where your code might have a chance to run. A more reliable way to handle analytics is to periodically post updates while the media is playing.
Related
Question in chrome.runtime.getBackgroundPage(...) and chrome.runtime.sendMessage(...).
The first allows you to get a link to the window background page, the second - to send a message to those who have subscribed to the event.
I feel that the second method is more correct to use, but I don’t have proof of that. On the contrary, I understand that sending messages and receiving a response is a serialization / deserialization of request and response in json, when, when we receive a background page, we get a link to it and it should theoretically be less expensive.
What is the right approach?
Any thoughts?
Basically I want to display the current track on a website.
I already searched quite a bit for a possibility to get notified when player state (play/pause, track, current position) changes.
My question:
Is it possible to get notified (socket, hook call) or is the only possibility I have to call the Web API like every second and fetch the state?
I fear that I'm running into rate limits when multiple users connect their accounts and display the current track.
Nope, there's still no way to do that. To achieve what you'd like, you need to pool the Spotify API continuously.
You can however use the Spotify SDK that you can pass a function to be executed on playback state change. The SDK is incompatible with a few platforms (see supported browsers), but for those you could catch the SDK initialization error and then switch to continuous polling via the API. You will have a lot fewer requests then.
A second option would be to only update the currently playing song after the last song should have ended. When getting the playback state for the currently playing song, you could use the field duration_ms and progress_ms to calculate the remaining time of the song. Then schedule another API requests for when the song should have ended and you're good. Whether that's a good strategy for your use case or not depends on the type of playback and how often the playback changes in your app.
I hope I could help!
As of now, it seems to be possible to receive player state events with a listener:
https://developer.spotify.com/documentation/web-playback-sdk/guide/#playback-information-display
I haven't tested the Web version, I'm currently using the analogous Android APIs, and Android's seems to work for play/pause change and track change (but not for position change)
I am developing a Rest API using node js, mongo and express as technologies. My models include users, venues, etc. In addition each user has states. Examples of states could be when a user signup the first state is 'new_user', after one week the state must be 'first_week_user' and so on.
The purpose of these states is to notify the user according to his or her state. For example if a user like a picture and the user is in the first week (he has the 'first_week' state) so an email must be sent to him. I am in the design stage right now, so I want to know if somebody had to face the same issue before.
The design that I have in mind is to put a notification_profile inside the user object and using a cron job to check the state and the actions of the day and according to that send the emails/push notifications.
What do you think? Are there a better option? e.g. I can have an email API and queue the emails hitting this API. Do you know where I can find information about design patterns facing this problem?
Thanks a lot for your help.
Without more detail, this sounds like you need the Observer pattern.
Essentially, your Email component would subscribe to each Person object's like(photo photo) event, and either execute an email-send job immediately, or schedule the job to run later, as part of a batch.
One way to specify the state transitions would be as a hierarchical state machine. See http://www.eventhelix.com/realtimemantra/hierarchicalstatemachine.htm#.VNJIflXF--o and http://en.wikipedia.org/wiki/UML_state_machine
I don't have a good node.js example but here's a C# implementation that also includes the concept of timed events. Essentially the state machine keeps track of a NextTimedEventAt so you can efficiently pull it back out of a database at the right time to fire a time-based event.
Actions happen on state transitions: as you enter a state or leave a state.
I have a monotouch application which has a timer and gets the data from the server.
Once the data is received i want to show the notification on the status bar.
It wrks fine when the app is in foreground. When the app is in background ,neither the timer nor the notification works
Please help me in rectifying this issue.
getting you app to run in the background is easy, add App registers for location updates in the info.plist, create a CLlocation singleton register for significant location change and you are done, your app will be resurrected every time there is a significant location change
When an iOS app transitions to the suspended (i. e. backgrounded) state, it stops its timers and disables locl notifications (and does some more memory optimization-related actions). A possible solution (JB only) to display user alerts while your app is in the background is to run a server (true unix server which is not bothered by an app getting backgrounded!) and use the undocumented CFUserNotificationDisplayAlert() function (just google it).
Your best chance is to extend the lifetime of your app by a little bit, by requesting a grace period in the background. As long as you receive this message during this time frame, you will be able to post the notification.
You do this by calling UIApplication.BeginBackgroundTask. This will let you run for a little bit, and the method you pass will be invoked shortly before your grace period runs out.
When you have an App with registers for location updates it seems to always run in the background to a certain extent, as you get significan location changes and you get the enter/exit regions, so you app is running code or is being waken up to run code... the problem is that the UILocalnotification doesn't trigger a sound and alert consitently ( but all the calls are displayed in the notification center... ) The big problem here is that the significan location changes, and the enter/exit regions are useless if you can not notify your user reliably.... is CFUserNotificationDisplayAlert() the only solution to trigger an alert to the user... ? does it work ? will your app be rejected if you use it ?
I got this working as follows :(Not a good design, but a working one)
Addded location support in info.plist, create a clocation manager and kept on requsting the location services. On the same loop schedule the UIlocalnotification .
It works perfectly. :)
NOTE : One issue is that it will give the user a propmpt as "This app uses your location, Do you want o allow"
Is there any way to know that whether the application has been invoked manually or by push registry?
PushRegistry.listConnections(true) returns a String[] of registered connections currently being used --- so if this is an empty array, the MIDlet was started manually.
See http://developers.sun.com/mobility/midp/articles/pushreg/ under "Discovering Whether a MIDlet Was Push-Activated".
and be care of that if you need information of whether the middlet was runned by alarm, described way is not about it, its only about different push events like incoming connections. here is the quote from http://developers.sun.com/mobility/midp/articles/pushreg/
"Note that the PushRegistry API doesn't provide a way to discover whether the MIDlet was activated by an alarm. If that knowledge is important, you must implement your own detection method. One way is to save information, such as the time of launch, in the RMS, then compare the saved time with the current time when the MIDlet is launched"