Great, thanks everyone :)
On Tue, Aug 18, 2009 at 7:14 PM, JDG wrote:
> That's what you should be doing. There's no reason to get a new Access
> Token every time. Per the OAuth spec, you should probably code your app to
> handle an expired token gracefully. The spec states that tokens MAY expire
> -- Twitter currently does not expire theirs, though. However, that doesn't
> mean that they couldn't in the future.
>
> 2009/8/18 André Arruda
>
>> I'm thinking about storing the access token in the phone so the user won't
>> have to go
>>
>> through all the auth process everytime the program is opened.
>>
>> I hope i won't find any new "surprises" by doing this.
>>
>>
>>
>> 2009/8/18 Otávio Ribeiro
>>
>> no.. just the same problem.
>>>
>>> On Mon, Aug 17, 2009 at 3:09 PM, AArruda wrote:
>>>
>>>>
>>>> I've been developing a Java/MIDP Twitter client for the past two
>>>> months, and i still need a couple more months to publish a beta
>>>> version. A few days ago i found out that the update source (app name)
>>>> is no longer customizable unless the client uses OAuth for
>>>> authentication, which means that any update sent through my client is
>>>> shown as "from API" instead of my app's name.
>>>>
>>>> I understand that OAuth is important for many security reasons, but it
>>>> still has important issues with mobile applications, forcing the user
>>>> to open a page through a mobile device, writing down the PIN,
>>>> switching back to the app and logging in again is just hell. Not to
>>>> mention the smartphones that don't support programs running in the
>>>> background.
>>>>
>>>> The current API's methods shouldn't be restricted to OAuth unless
>>>> these issues are solved first. We, developers and mobile users, would
>>>> be thankful.
>>>>
>>>> Is anyone using any other solution for OAuth and mobile devices, if
>>>> there is any?
>>>>
>>>
>>>
>>
>
>
> --
> Internets. Serious business.
>
