Hello!
Hello!
Our CTO has given me a task which looks easy but is anything but.
In essence, what he'd like to do is this:
- Create a Twitter account
- Send messages to it
- Have them display in our flagship product
Hence, in essence, we'd have a hardcoded account to which our
messages would be delivered and being displayed in our flagship
product.
This, to me, seems a gross misunderstanding of how this kind of APIs works and I am not even sure it's technically doable.
The reason is that customers would have to confirm the interaction (pitfall one: what if they say no?) and then receive messages.
Which takes us to pitfall 2 (as I see it): what happens when Twitter sees that two client are trying to access the same account from different - even wildly different - IPs and that both confirm it?
I do not think this would be seen favourably and, quite frankly, I do not even know whether this is at all possible.
Anybody's worked on this before and can share some insight?
Thanks!
A
Our CTO has given me a task which looks easy but is anything but.
In essence, what he'd like to do is this:
- Create a Twitter account
- Send messages to it
- Have them display in our flagship product
Hence, in essence, we'd have a hardcoded account to which our
messages would be delivered and being displayed in our flagship
product.
This, to me, seems a gross misunderstanding of how this kind of APIs works and I am not even sure it's technically doable.
The reason is that customers would have to confirm the interaction (pitfall one: what if they say no?) and then receive messages.
Which takes us to pitfall 2 (as I see it): what happens when Twitter sees that two client are trying to access the same account from different - even wildly different - IPs and that both confirm it?
I do not think this would be seen favourably and, quite frankly, I do not even know whether this is at all possible.
Anybody's worked on this before and can share some insight?
Thanks!
A
I don't think Twitter will have any issue if you use the same account from different IP addresses for example you can use twitter through your land internet and mobile internet without any issues. You will have an issue if you abuse their platform (for sending spam).
ReplyDeleteIs this just a means to get messages into your product, or are they going onto twitter so that the messages can be read by other people too?
ReplyDeleteI don't think twitter would mind that much if multiple machines were accessing the account at the same time (I certainly have twitter clients on my phone, my tablet, my laptop and my desktop all open and running simultaneously) but I don't know how well it scales and I don't know if there is something in twitter's T&Cs which prohibit you doing this. There may be an upper limit to the number of clients, beyond which you annoy them, if you see what I mean.
I had a requirement to show messages in our app, where we didn't want to have our own external-facing server. We knocked up something using simple table storage in Azure in a day, a very simple client to run at HQ to add/remove/edit messages, and then some code in the Delphi app to go fetch the last NN messages and display. We're paying about £30 a month for a VSOnline account that comes with some Azure storage & bandwidth, you could possibly get it cheaper than that. Do you have a ballpark figure for average monthly number of messages and approximate number of clients?
The other things about the approach of not using twitter is; messages can be longer than 140 and you can include your own stuff about layout and formatting if you so wish.And anyone can see the twitter messages, they're not private.
So I guess it starts with - does he want to use twitter simply as a delivery mechanism, or does he want the messages on twitter and visible to the general public anyway?
Panagiotis Drivilas things are a bit more convoluted here: when you use a desktop and a mobile, usually, your IPs will be very close to each other. Twitter probably recognises that and lets you loose. Plus, it's two, so - you know - even if it were 3 or 4 this probably wouldn't be a massive problem. This is not, however, the case here: we are talking at the very least of about 100 different IPs with very different geographic locations.
ReplyDeleteAlso, I am not sure what you mean by "spam": would you mind being more precise?
Thanks!
A
Who's posting the messages? Someone at corporate I'm assuming? Also, have a contingency plan in place for when the account gets hacked.
ReplyDeleteAnthony Frazier no we have no contingency for that yet. I do not think hacking is going to be a massive problem because we are talking of an off-the-shelf kind of system here. I doubt they would have any advantage from doing something like this. Even though, you can never really tell can you?
ReplyDeleteMy understanding is that, yes, these will be posted from HQ I'd think - or anyway from someone working there even if on the move.
A
Is your CTO aware of this cool thing called RSS feeds?
ReplyDeleteRob Uttley I am not very convinced that this is a good idea either, but I can see the value in it: if you have a twitter account, you can follow it, so - say - someone could check the messages on the go even when they're not connected to the application. Still, I am not very convinced of this idea. I think it's dangerous and, potentially, could give us problems with Twitter.
ReplyDeleteWarren Postma before saying "I do not think this is a very good idea", I'd like to understand the technical problems that may arise.
ReplyDeleteArmed with those, it would be a lot easier to go to him and say "mmmh... why don't we do this instead?".
A
Why not have "front-end" for the PR folks writing the messages, which then posts each message to both Twitter and to a private service, which the flagship product queries (via webservice)? The latter could contain the Twitter link, in case you want to be able to "go to Twitter".
ReplyDeleteAre you sure you understood what he wanted (or possibly he, himself understood it?)? Maybe he just wanted to have a twitter account to post to and have your software follow it/read it. That would mean the software doesn't need to log into twitter but could just display a url in a webbrowser component.
ReplyDeleteTo deal with account hacking or other outages, etc, you could also embed the Twitter widget in a hosted web page, which then again is accessed from your application.
ReplyDeleteAnother solution would be to use a central access point (xml/json/datasnap) which use a central app to pull data from Twitter (solves authentication / throttling issues).
That said - the native web embedded solution is more future proof - and allows rich content such as links and images.
Asbjørn Heid That's more stuff to build. I grok the concept of using Twitter as a notification mechanism. All the infrastructure is already built, clients for posting messages are already available for several platforms, etc. If all the app has to do is read messages from a particular account, it might be doable if the API allows.
ReplyDelete/sub
ReplyDeletehttps://blog.twitter.com/2012/embedded-timelines-howto
ReplyDeleteimho, you must allow your customers to follow you twitter news, never force them to have a de facto account to check your posts. consider this, twitter could be blocked in some way, broken your news feature.
ReplyDeleteOk, here is an update. I explained to my boss that the idea of having a default account wouldn't be too good.
ReplyDeleteSo I suggested two ways:
1) An RSS feed
2) A browser windows where to show by default our tweets,
I haven't received news yet.
My main point with him is that, whatever approach we followed, we'd hit the API rate limit.
We have over 1K customers in the UK, so any attempt to download a feed by all of them would
certainly result in an account suspension or ban.
This is a desktop application we're talking about, not a website.
A
If you are trying to get news to your customers from you, then I would suggest RSS. Works very well.
ReplyDeleteI think that if you have a website, then you could feed yourself, exclusively for your app. This way, no API limit, no restrictions at all. Another way, and depending on what you are to feed and how often, you could put a single text file on a FTP server (not elegant, but works fine). Seriously there are many ways to skin a cat!
ReplyDeleteI'm not sure what the problem is here, other than a developer who doesn't understand marketing. There are websites that reflect Twitter feeds that get millions of views PER DAY. Twitter sends out some two billion tweets daily, and you're concerned about an app that may be viewed by 1000 people?
ReplyDeleteFirst off, you don't need an account to watch a Twitter feed. Or if you do, it can probably be a random account you set up for that purpose.
Second, you're probably only displaying tweets that contain a specific hashtag (or set of hashtags), right? Or is it anything sent to a particular account?
Anyway, you're probably best off setting up a web page with a twitter feed widget in it and simply loading that up inside of a Twebbrowser, rather than hardcoding the twitter access logic in the app. That's because you want to be able to edit the feed parameters from a centralized location. The last thing you want it to have to send out a field update to fix a feed issue.
David Schwartz - It all depends on if he wants to use the Twitter API or not. The API has restrictions. The web UIs have not.
ReplyDelete