I know, I know. It's a solution that works for me, - given the
resource limitation of a typical low end phone I decided to do most
processing on the server anyway.
I'm not trying to persuade everyone to do it this way, just sharing my
On Tue, Feb 2, 2010 at 2:09 PM, ryan alford <ryanalford...@gmail.com> wrote:
> Another problem with this approach is that you are now required to have a
> server. So now a developer would have the added expense of paying for a
> server. Now if the developer already had a server, then it's a moot point,
> but not all developers have their own hosted servers.
> What happens when your server goes down, or your hosting provider has
> connectivity problems? Your app is now dead, even though Twitter is still
> functioning normally.
> On Tue, Feb 2, 2010 at 7:08 AM, Anton Krasovsky <anton.krasov...@gmail.com>
>> With all that talk about OAuth, I thought I might share my experience
>> using it in for a mobile (j2me) twitter client.
>> I guess my approach is nothing new, and probably is not applicable to
>> iPhone apps because of the appstore distribution process, but anyways.
>> So the way I handle OAuth is as follows:
>> All application downloads are handled by my own server. Before
>> allowing user to download the app I initiate OAuth authorization with
>> Twitter and then, save user tokens along with generated unique id for
>> a user.
>> Once authorized, user is permitted to download the application which
>> is tagged with that unique user id I generated earlier.
>> Once user starts the app, it uses it's id to authenticate itself to my
>> All communicatin between Twitter and user's appication is
>> handled/proxied by the server that performs all necessary oauth
>> signing on behalf of the user.
>> So, this way I have all benefits of using OAuth in a mobile app.
>> The only drawback really, is that user must visit my web site at least
>> once to perform authorization.