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 <arrud...@gmail.com> > 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 <otavio.ribe...@gmail.com> > > no.. just the same problem. >> >> On Mon, Aug 17, 2009 at 3:09 PM, AArruda <arrud...@gmail.com> 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.
