Ryan,
Don't know if it will fit in with your architecture, but maybe this
service could be of use to you:
http://wapple.net/
On Feb 6, 12:39 am, Ryan Sarver rsar...@twitter.com wrote:
Ill talk with the team and figure out if it's better to roll it back or just
limit it to the known, working
And for QA, if you're not able to procure each commercially available
handset, check out www.deviceanywhere.com. Or if you prefer to
outsource, hit me up off list, I can give you a list of reputable
mobile QA houses.
On Feb 6, 2010, at 7:40 AM, Dewald Pretorius dpr...@gmail.com wrote:
Can you let us know the current supported User Agents? That way I can
direct our users to it if I am certain their phones are supported.
Thanks
T
On Feb 6, 4:39 am, Ryan Sarver rsar...@twitter.com wrote:
Ill talk with the team and figure out if it's better to roll it back or just
limit it to
Ryan,
Thanks for both the attempted fix and the announcement.
Unfortunately, where the previous version was kind of a crapshoot for
mobile users because the buttons appeared black (see my screenshot in
the bug report at http://code.google.com/p/twitter-api/issues/detail?id=395),
this new version
In fact, I'd recommend that you only show the new version for devices you
have actually tested against... Mobile browser support is a crap shoot and
you really can't assume that something that works on one device, works on
another... You need to test each and every one of them (or at least each
That's an amazingly great recommendation, Michael.
-- Charles
On Feb 5, 9:22 am, Michael Steuer mste...@gmail.com wrote:
In fact, I'd recommend that you only show the new version for devices you
have actually tested against... Mobile browser support is a crap shoot and
you really can't assume
Ill talk with the team and figure out if it's better to roll it back or just
limit it to the known, working user agents
On Fri, Feb 5, 2010 at 3:42 PM, CharlesW cwilt...@gmail.com wrote:
That's an amazingly great recommendation, Michael.
-- Charles
On Feb 5, 9:22 am, Michael Steuer
Buttons *NOT* clickable on BlackBerry Bold Browser (OS4.6).
Have tried with and without Javascript enabled.
Can provide headers etc if needed.
Thanks for this update - it looks amazing. Should really ramp up
security usability.
On Feb 3, 11:16 pm, Ryan Sarver rsar...@twitter.com wrote:
Buttons not clickable on Windows Mobile; tried on both a 6.1 6.5
device.
On Feb 3, 6:16 pm, Ryan Sarver rsar...@twitter.com wrote:
FINALLY!
An update has just gone live that fixes rendering of the OAuth screens for
most mobile devices. We also fixed a few small nagging things like the
We've had to roll back the mobile OAuth update as it was consuming an
abnormally large amount of resources. We'll dig in and figure out what was
going on.
Almost there, rs
On Thu, Feb 4, 2010 at 12:24 PM, Carlos carlosju...@gmail.com wrote:
Buttons not clickable on Windows Mobile; tried on
Buttons are non-clickable on Nokia 6300. This will be teh same for all
Nokia Series 40 browsers.
On Feb 5, 10:27 am, Ryan Sarver rsar...@twitter.com wrote:
We've had to roll back the mobile OAuth update as it was consuming an
abnormally large amount of resources. We'll dig in and figure out
Following up on my earlier email. I jumped the gun and the rollback never
actually happened :)
However, we are getting some reports of the buttons not functioning in a
number of browsers and are working on a fix.
Best, Ryan
On Thu, Feb 4, 2010 at 3:27 PM, Ryan Sarver rsar...@twitter.com wrote:
w0t! :D
thank you x1000
This is great and works well too!
On Feb 3, 11:25 pm, Swap rh.swar...@gmail.com wrote:
w0t! :D
ZOMG *faints*
one small nit: the redirect back to the app seemed to take longer than
it should. not sure what the redirect timeout is, but it might do well
to shorten it up by a second or two... otherwise ppl might start to
get click-happy while nothing is happening.
-Chad
On Wed, Feb 3, 2010 at
Thank you so much. This looks much better.
On Feb 3, 4:16 pm, Ryan Sarver rsar...@twitter.com wrote:
FINALLY!
An update has just gone live that fixes rendering of the OAuth screens for
most mobile devices. We also fixed a few small nagging things like the
default action is now allow instead
I've started testing it and it looks good. One comment, though. Is
there any chance to move the PIN above the instructions?
Did the element id change? I was using this piece of code (iphone) to
get the oauth_id, and it's no longer working since around when these
new changes got pushed -
NSString*authPin = [[_webView
stringByEvaluatingJavaScriptFromString:
'oauth_pin' element id got changed to 'oauth-pin' for anyone else
who's stuff broke
On Feb 3, 3:53 pm, Fernando Olivares aeris@gmail.com wrote:
I've started testing it and it looks good. One comment, though. Is
there any chance to move the PIN above the instructions?
It is working correctly on a G1 running Android, but getting the non mobile
version on a Nexus One. User-Agent is
*Mozilla/5.0 (Linux; U; Android 2.1; en-us; Nexus One Build/ERD79)
AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17*
this broke my code - in case anyone needs it and didn't notice, the
oauth element id changed from 'oauth_pin' to 'oauth-pin'.
On Feb 3, 4:56 pm, Will Fleming wflemin...@gmail.com wrote:
It is working correctly on a G1 running Android, but getting the non mobile
version on a Nexus One.
Rocks!
On Feb 3, 5:16 pm, Ryan Sarver rsar...@twitter.com wrote:
FINALLY!
An update has just gone live that fixes rendering of the OAuth screens for
most mobile devices. We also fixed a few small nagging things like the
default action is now allow instead of deny if you just hit go on an
22 matches
Mail list logo
