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
Related
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
I'm creating an app for Q&A that unifies twitter mentions/DMs, facebook wall posts/messages, as well as email and sms into one inbox. I know how I'm going to handle the SMS (storing each incoming message and outgoing response), but I'm wondering if it's realistic to apply the same methodology to twitter/facebook messages.
I figure I need to store them so I can at least mark them read/unread. Is this how TweetDeck does it? I can't imagine them polling the API constantly without caching anything.
By the way if you know of an app that does this already that would be fantastic. Hootsuite does everything but SMS and email oddly.
Assuming you're building a mobile app (since you mention SMS), if you're aiming to support arbitrary Facebook & Twitter accounts (ie including very busy ones) & use over a long period of time, then you can't store all the tweets & posts on the mobile device: this storage required would grow over time to exceed the capacity of any device.
You can store a reasonable number of "recent" tweets/posts in full; these form the backing model for your UI's views. When the user navigates past either end you can retrieve more via the APIs, and you'll perform housekeeping on this collection so it doesn't get too big, discarding older ones as necessary.
(This collection may end up being gappy: eg if I haven't run the app for a week, when I start it it would retrieve the most recent day's content, leaving a gap between yesterday's content & that of a week ago. Twitter's apps do this & show the gaps, allowing the user to fill them in via the APIs.)
If you need to keep track of read/unread status, you could store this & the unique id for a larger number of items; but again, you'll eventually need to purge these too.
You might want to look at the Twitter User Streams feature; Facebook's Realtime Updates isn't as well-suited for mobile apps (unless backed by your own server).
We are building a system that seeks to calculate and score the value of information and users of information - based on the interaction between the two.
To do this, we need to track and measure these interactions. We are working on different ways - from connecting your social services and monitoring them (hard to scale and requires very patient users happy to connect services) to explicit tracking having a bookmarklet ala digg that user can trigger whenever she is on a piece of information (basically, content) that she wants included in her score.
What we'd really like is a tool that could do something like;
monitor all activity of a person across all networks (read, watch, comment, post, tweet, author, etc) and actively sit in the users browser and 'listen and report' back to HQ anytime a defined activity takes place.
Suggestions?
If you want to monitor the Social network activities for ex. Facebook, you need to take the authentication from the user like read/friends list etc. and fetch the updates from facebook with in specific interval of time and report same to HQ.
The same thing you need to report for other networking sites.
Each network sites may have different APIs you need collect and take the permission of the users (like signin).
Hope it helps.
I am using the GA Data Export API to interact with Google Analytics and I'm making a lot of progress, I am using this URL Endpoint initially to pull all the profiles under an account:
https://www.google.com/analytics/feeds/accounts/default
This URL retrieves each GA ID (profile) and each UA. One thing I've realized is one account can contain multiple UAs and when this happens, this request pulls all profiles. We have a client who has about 115 profiles under like 10 different UAs, and the request takes about 30 seconds for the initial request (and then I believe it must be cached, because it speeds up considerably after this, but then the next day the same thing occurs).
Is there a way to get a list of UA's without pulling the profiles? This way I can query the UA specifically for the profiles instead of pulling each one.
Any advice on this would be really helpful!
Thanks
UPDATE: Here's some documentation on the specific call I am using right now:
http://code.google.com/apis/analytics/docs/gdata/gdataReferenceAccountFeed.html
UPDATE 1: I have found some interesting information in the docs
Once your application has verified
that the user has Analytics access,
its next step is to find out which
Analytics accounts the user has access
to. Remember, users can have access to
many different accounts, and within
them, many different profiles. For
this reason, your application cannot
access any report information without
first requesting the list of accounts
available to the user. The resulting
accounts feed returns that list, but
most importantly, the list also
contains the account profiles that the
user can view.
So this means that you have to use the default accounts call to get these back? Surely, somebody has had this issue before?
So apparently, you can query the account if you know the UA-ID, however there is no way to get back a list of only UA IDs.
One way you can do it is have the user enter their own UA ID instead of having them choose one; not as user-friendly as it could be but better than making the user wait 30 seconds!
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.