The API clearly says that all user types can listen to full streams of tracks(Content Access Rules) in a Radio/ SmartRadio, I only get previews though when I pull an artist's radio track list...am I missing something?
Full track streaming is only available through the SDKs (Javascript, iOS or Android), for authenticated users. You'll have to use one of the playRadio methods available there.
Full track streaming - only available for authenticated users.
1) Would authenticated users need to individually sign up
2) and would they need to pay any subscription fees for playing (unlimited songs)?
Thanks
Related
I have a backend running GraphQL, MongoDB + Mongoose, and Apollo. This application has functionality for user accounts and a friends list. Each user can login to their account and see a list of friends with their current 'status'; If a friend changes their status, I need that change to be reflected on the user's side. An example of this is like facebook's "green dot" on messenger that tells you when one of your friends is online using the application.
I have been searching documentation for GraphQL and have been suggested either Subscriptions or Live Queries. Subscriptions seem to be the majority of suggestions from what I understand, live queries are not officially part of GraphQL or were dropped.
Does anyone have a solution to getting "live" data with GraphQL/MongoDB that doesn't involve polling for this scenario?
You already seem to have your answer: subscriptions!
Using your example, consider two users - mikep17 and mcy. You are mikep17, logged into your application and viewing your list of friends and their statuses. I am your friend, and I log in as you are viewing this list, and you want to see that in your application's UI.
On the frontend, in your application's instance, your application will execute a subscription to some event. Let's call it friendStatusChange. Now your application is "listening" for that event in order to respond accordingly. Let's assume that when your application receives the event, it can parse out the information that "I" (mcy) have changed from offline => online and then use that to add the "green dot" next to my username.
On the backend, your GraphQL server will have code that handles your user functionality - logging in, logging out, etc. It will need to be enhanced to hook into these actions and "publish" the friendStatusChange event as applicable.
Now, instead of your client constantly asking (polling) "did a friend's status change? how about now? now?", it can just listen and wait for your server to tap it on the shoulder and say "hey buddy, your friend mcy's status changed".
I created an app on google home, and I want the app to work only if its MY voice who that asks to do the skills on my google home
How can i do that? Is this possible? I configured my google home at beginning for it recognize my voice, now how to make it mandatory for this app?
I'm trying to make my app secure because it's make banking operations by voice.
Each user request is sent to your application with a unique anonymous UserID. You will need to determine the UserID that belongs to your account (by looking at logs for your application to see which value is yours) and reject requests from other UserIDs.
Even better would be to setup a more proper Account Linking system.
Keep in mind, however, that the voice authentication system isn't perfect and there is a slight, but possible, way for others to duplicate the request - either by using a recording of your voice or by having a similar voice. Consider all the risks when designing such applications.
When streaming a single track on Deezer from the server side, how can Deezer recognize that this track came from Flow radio and therefore give a full streaming url for a free user? I seem to always receive a 30 second preview for free users, which we would like to avoid.
For the api to know that the track is within the subset of of a radio station (vs an on demand track), the api call needs to include the id of the station from which it came:
https://api.deezer.com/streaming_url.php?access_token=xxxx&radio_id=yyy&track_id=zzz
rather than simply:
https://api.deezer.com/streaming_url.php?access_token=xxxx&track_id=zzz
I have a doubt about real-time Instagram subscription in the API. Can i subscribe to whatever user i want? or there is some restrictions about the users that i want to subscribe?
I arises this doubt because in the Instagram of real time subscriptions page says: Note that this subscription is for all of the client's authenticated users, not just a specific user.
Its means that i can only subscribe the users that have authorithed my app in Instagram??
I have to make an app that consumes the instagram subscriptions and when there is a new photo it automatly saves it in the DB.
Thanks
A few things, first if you use the "user" type, then you are correct it will ping your endpoint any time any user who has authorized your app posts, there is no IG side filter (yet), but you can easily filter on your end once you get the notification. Oddly, I did notice it now sends the media_id of the post (although the docs say it doesn't!?). If users do not authorize your app, then the only way to get notifications is via the other endpoints such as by tag.
I have found some issues though when dealing with "private" users, and some strange filter behavior to watch out for.
A final point, you said you want to save to your db - that could be in violation of their use policy, so be sure to clearly understand what IG's rules are and that you don't break them.
Hope this helps,
P
I have created Twitter bots for many geographic locations. I want to allow users to #-reply to the Twitter bot with commands and then have the bot respond with the results. I would like to have the bot reply to the user as quickly as possible (realtime).
Apparently, Twitter used to have an XMPP/Jabber interface that would provide this type of realtime feed of replies but it was shut down.
As I see it my options are to use one of the following:
REST API
This would involve polling every X minutes for each bot. The problem with this is that it is not realtime and each Twitter account would have to be polled.
Search API
The search API does allow specifying a "-to" parameter in the search and replies to all bots could be aggregated in a search such as "-to bot1 OR -to bot2...". Though if you have hundreds of bots then the search string would get very long and probably exceed the maximum length of a GET request.
Streaming API
The streaming API looks very promising as it provides realtime results. The API allows you to specify a follow and track parameters. follow is not useful as the bot does not know who will be sending it commands. track allows you to specify keywords to track. This could possibly work by creating a daemon process that connects to the Streaming API and tracks all references to the bot's names. Once again since there are lots of bots to track the length and complexity of the query may be an issue. Another idea would be to track a special hashtag such as #botcommand and then a user could send a command using this syntax #bot1 weather #botcommand. Then by using the Streaming API to track all references to #botcommand would give you a realtime stream of all the commands. Further parsing could then be done to determine which bot to send the command to. This blog post has more details on the Streaming API
Third-party service
Are there any third-party companies that have access to the Twitter firehouse and offer realtime data?
I haven't investigated these, but here are a few that I have found:
Gnip
Tweet.IM
excla.im
TwitterSpy - seems to use polling, not realtime
tweethook
I'm leaning towards using the Streaming API. Is there a better way to get near realtime #-replies for many (hundreds) of Twitter accounts?
UPDATE: Twitter just announced that in the future they will have User Streams which expands upon the Streaming API. User Streams Preview
Either track or follow will work for the cases you describe. See http://apiwiki.twitter.com/Streaming-API-Documentation#track for details on what track actually does. The doc on follow is on the same page.
There are rate limits of sorts on the streaming API, but they have to do with how big a slice of the total tweet stream you're consuming. For writing a bot like this you won't hit these limits without a pretty big user base. And when you get that user base you can apply for elevated access levels that increase the rate limets.
There's the twitter firehose but you're probably best off using the Streaming API. The firehose is open to Google (try googling your twitter name) and as the link says they're opening it up to all soon enough.
You'll want to get your IP whitelist too.
If your not already, you want to check out the GoogleGroup for twitter devs.
The track predicate for the streaming api would actually be useful because if you follow your bot's user IDs, you'll get all the messages made by your bots and all the other messages that mention your bots #usernames (including #replies). It really does track everything public on twitter relating to the user IDs you follow with it, give it a shot.
REST API:
The most comprehensive results with the least amount of false positives. Will include protected statuses if the bot is following the protected account. If you poll every thirty seconds it is pretty close to realtime and you will be well under your rate limit (350/hour) if you are using api.twitter.com/1 with OAuth.
Streaming API:
You will want to avoid the Search API. It is trending more and more towards popular results and not complete results.
Streaming API
The fastest but also likely to miss some statuses as well as include false positives. Protected statuses for example are not included. Track for a screen_name will return statuses with that screen_name in it but will also include tweets that just have the screen_name as a string without the # so be sure to filter on your side.