Is it possible to programmatically upload a picture to twitter from iPhone?
Can this be done through twitter directly, or do I need to use a third-party service like Twitpic?
Thanks for editing your question. It makes more sense now. I'm leaving my original answer up so that this thread doesn't become confusing.
Anyway, the answer is short: the Twitter API doesn't provide a way for you to upload a photo directly with a status update, so I'm fairly certain you need to use a third-party service. The official Twitter client uses yFrog by default, but it lets you change the service to TwitPic, TweetPhoto, Mobypicture, Twitgoo, Posterous, img.ly, or a custom service.
Just use http://github.com/Gurpartap/GSTwitPicEngine.
Related
I'm trying to get the HTML of a website, and display it as a picture. The conversion is very straightforward on iOS, but since watchOS doesn't have WKWebView (which all of the methods I've found uses) I can't use those solutions.
I've also explored doing it via an API, but they're either too costly or look suspicious (but please feel free to point me to one if you're aware of one!).
Is there any way to display HTML as an image on Apple Watch?
Thanks!
You can deploy your own free microservice (i.e. with node.js + heroku) and then make the http request to your service passing your url and getting back your image.
I've got a client that wants to have a paid app providing his video instructional content on iOS, but of course we dont want people simply getting the video content directly without paying for the app.
Is there some simple way of doing this that I'm overlooking? He wants the content streamed so he can add content easily and periodically without app updates.
Perhaps using Youtube but having the videos password protected? Is there a service anyone has used with an appropriate iOS API that anyone has heard of?
I've never done this before, but you could do some kind of token exchange based on the device ID. When the app is first used, register the device ID with the content server, and use that in combination with a salted hash of some kind to identify the device when requesting the media from the server.
I'm considering two options right now.
1- Following this post (roughly) In iOS, how would you programmatically pass a username / password to a secure site and essentially doing a combination of .htaccess for password protection, leveraging robots.txt to prevent search engines from indexing the videos, and obfuscating the video names. I've got to research the password protection of the video directory and how exactly to do that... but it seems the simplest. The downside is the clear text password.
2- A slightly more sophisticated method where I use oAuth to authenticate against but really following the first path, and potentially leveraging http://maniacdev.com/2010/09/new-open-source-oauth-library-for-easy-authentication-on-ios-devices-from-google/ to help in writing the oAuth piece.
a third possibly prohibitively expensive option is to look at the HTTP live streaming in OSX server https://developer.apple.com/streaming/
How do you guys think these options sound? Are there others I'm not considering?
Assuming you built a page for each specific mobile browser (Android/iOS/BB/etc.), is it possible to have a web application capture an image and send it to the server for processing?
I'd like there to be "Nothing to install" for my application, but if I need to reach out to the hardware at all, I fear it's not possible.
There is the Video Capture API but I have no idea how widely spread addoption is at present and it is very new.
IF this api isn't avalible there isn't really much you can do other then asking users to upload it using a standard file upload and them to take the picture before hand.
This is one area that a native application would be far far better as intergeneration would be easier and more seamless for the user.
When I implement OAuth in iPhone, I have a dilemma to choose Safari or UIWebView to open the Twitter pages for user authentication?
I write some advantage and disadvantage of both case:
Using UIWebWeb. The disadvantage is users have to enter their credentials in our application. It's maybe risky phishing. The advantage is this approach will not quit our app.
Using Safari for user to authenticate (this approach automatically callbacks to our application) Addvantage: less risky. Disadvantage: have to quit our app
A good reference link about this: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
Which approach do you prefer?
Any response is appreciate. Thanks.
The vast, vast majority of users will not understand or care about the distinction. Do whatever makes their lives easier, or--all else being equal--your life easier. And so long as you are trustworthy (you're not phishing or peeking at their credentials, right?), you'll be providing a good experience and not screwing them over. In this case, I'd use the UIWebView.
The guy who did the Pownce iPhone app a couple of years ago sort of publicly debated with himself about this.
His blog doesn't seem to be up anymore, but basically he implemented it the "right" way as far as OAuth is concerned. Instead of entering credentials inside of the app, Safari was launched and they were entered in there, and then a custom iPhone URL was used as the callback to relaunch the Pownce app. Pretty neat, eh?
Some time later, the developer followed up with a comment that a lot of people were downloading the app but not actually using it. His conclusion? That his brilliant OAuth scheme was to blame. Users were confused by Safari launching and being taken out of the app.
To be honest though? I think the fact that the app was for Pownce, a service that nobody used, was to blame.
I have an app in the app store right now that uses the Foursquare API, which supports both Basic HTTP auth and OAuth. I decided to "do the right thing" and use OAuth. The user enters their credentials directly inside of my app. Am I saving their username and password in plain text anywhere? Nope. But could I be? Sure.
It might sound like I'm arguing for both sides here, but what it really comes down to is that it's very unlikely that your users will know or even care about what OAuth is. It's probably just as unlikely that they will even think twice about putting their credentials into your app. OAuth is great (a hell of a lot better than OpenID) but wasn't designed with the iPhone in mind. It's built to work inside of a web browser. I think the Foursquare API docs put it best when talking about their Mobile/Desktop client OAuth scheme (different from what they want you to do for a web app) - "We provide this mechanism under the assumption that if a user has installed your application on their hardware they, trust it enough to pass through their authentication information to foursquare."
I've already implemented this as a drop-in set of classes (open source). Feel free to take a look: http://github.com/bengottlieb/Twitter-OAuth-iPhone
For the best user experience with destop and mobile application, we should use xAuth:
http://docs.google.com/View?id=ddkz8b2q_76d95356mz
As of May 31st, 2017 and onwards, there is no option left. We MUST use Safari, since google now does not support OAuth via UIWebView. Refer this link for more details.
I would like to enable my iPhone app's data to sync with Google docs. How can this be done? What other sync'ing options do I have (another one I am aware of is EverNote Sync Server)?
try nutdb app for iphone. nutdb will sync every nutdb database with google docs hosted spreadsheet.
It is hard to give a specific answer without more detail, but Google does provide an API that allows some manipulation of document data. The httpriot library is a handy way to simplify access to REST structured web services like this.