OAuth is a perfect solution for authentication with other web apps. The problem is, it just sucks for native apps.

You know the typical workflow for apps. Open, enter credentials, it works. Now here’s what OAuth looks:

Yes, it quit’s the app, opens Safari, and then restarts the App. Yes, this sucks. But see for yourself

Even worse, some other apps like Echofon like to play the travesty role and ask your two times.

There was a big outcry by some people, especially UX affine ones, when Twitter announced shutting down their http auth, leaving only OAuth. Twitter listened and presented xAuth. It basically hides everything from OAuth, let the user enter his credentials the old way while transparently fetching the token. hen some other people say this is a terrible, horrible, not good, very bad idea…

So what else is there?

Facebook’s new Graph API is probably the most known OAuth 2 API. They provide a full package for the iPhone that manages all authorization  in the browser, yet in a very user transparent way. Sure, this is a security risk. With some easy hacking and/or javascript injection you can steal the login data. But it’s certainly saver than letting the application store the credentials.

Problems

• Creating multiple accounts is a PITA, requiring multiple roundtrips and logging in/logging out of the service. (This is less of a problem if you make the login convenient via a optimized landing page; and you don’t have an automatic login)
• The Consumer Secret is reverse engineer-able. This nullifies the argument that oAuth is better for identifying clients when it comes to desktop/mobile apps.
• If a native app wants to get a copy of your password, it will get a copy of your password. It can create embedded browsers, hijack the authentication, add a proxy or else.

Loren Brichter proposes a solution that integrates deeply with the OS, therefore maximizing security while keeping the “native” experience.

Advantages

• From a service provider’s point of view, it’s absolutely reasonable why the want OAuth. Control. Which is a good thing.

OAuth doesn’t prevent evil folks from shipping Twitter apps that might be trojans, but it does allow us here at the Mother Ship to revoke their ability to talk to the Twitter API. That means less spam/”SEO” tools, and a short time-to-live for applications that are discovered to be malicious. [Alex Payne - API Lead, Twitter, Inc.]

• For the user this is also a good thing. You can loose your iPhone and just disable the specific token. Your password is not leaked. The App furthermore could be configured to clear all caches when it detects that the API Key has been revoked.
• It’s better than Basic access authentication, where your username and password is sent in every single request. But you have to go over SSL anyway. If your token leaks, other’s have access to your account.

My proposal

I’ll propose something similar. A optimized, secured landing page that is styled native-ish per device and runs within the native browser, but without showing the user so. So we can provide a good-known-flow

1. Open App
2. Press Login / Register
3. Wait for login page to load (this is where users may experience a little difference…)
4. enter credentials
5. wait for authorization
6. it just works!

Of course, the web service has to provide some sort of management page where current applications are listed and rights can be revoked. If a application goes wild and messes around with usernames, their token can be blocked. (which only makes sense if there’s a reasonable review in application registering)

There’s some comparison of the different techniques on the oauth wiki native apps page; but no clear winner.

Related posts:

1. Add Facebook Like Button with Facebook Connect iPhone SDK
2. WordPress: Change the default text for password protected pages
3. mysql5 with mac os x

I present you a clever workaround, that even uses the sdk to display a *conventional* facebook login in a way the user knows.

The flow is equal to other Facebook-Connect functions – at least for the user:

• User presses like button
• If cookie is there (user logged in already and marked “Keep me logged in” it is instantly liked. Done.
• Else, the (known) Facebook Connect Login Dialog pops up. It looks a bit different (two headers) but most users won’t notice
• User enters his login details
• Dialog closes, like button reloads, displays like now in user language + friend faces that also like link
• User can press like again to invoke it

So how to we get there? First, let’s overload FBDialog (we need to hack a little bit).

PSFBLoginDialog.m:

[CC lang="objc"]
// overridden to check against our *own* URLs
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
navigationType:(UIWebViewNavigationType)navigationType {
NSURL* url = request.URL;
GTMLoggerInfo(@”url: %@”, [url absoluteString]);

if (![[url absoluteString] containsString:@”login”]) {
[self dialogDidSucceed:url];
return NO;
}else {
return YES;
}
}
[/CC]

This checks whether login was successful and calls our registered delegate. Now, let’s add an area where the like button should be. In my case, I add it as a table footer view.

[CC lang="objc"]
#define kWebPadding 10
UIView *paddingView = [[[UIView alloc] init] autorelease];
paddingView.backgroundColor = [UIColor whiteColor]; //RGBACOLOR(128,128,128,0.7);
paddingView.opaque = NO;
UIWebView *webView = [[[UIWebView alloc] initWithFrame:CGRectMake(kWebPadding, kWebPadding, self.view.width-kWebPadding, 60+2*kWebPadding)] autorelease];
[paddingView addSubview:webView];

NSString *likePage = @”http://google.com”;
NSString *likeFacebookUrl = @”http://www.facebook.com/plugins/like.php?href=%@&layout=standard&show_faces=false&width=320&action=like&colorscheme=light&height=35″;
likePage = feedItem.link;
[webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:[NSString stringWithFormat:likeFacebookUrl, likePage]]]];
webView.opaque = NO;
webView.backgroundColor = [UIColor clearColor];
webView.delegate = self;

paddingView.height = webView.height;
paddingView.width = webView.width;
self.tableView.tableFooterView = paddingView;
[/CC]

This is wrapped in a UIView to get a bit padding.
Next, we need to intercept the calls on the UIWebView, maybe opening the dialog if a login is needed.

[CC lang="objc"]
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark UIWebViewDelegate

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
GTMLoggerInfo(@”starting request %@”, request);

// if user has to log in, open a new (modal) window
if ([[[request URL] absoluteString] containsString:@”login.php”]) {

PSFBLoginDialog *dialog = [[[PSFBLoginDialog alloc] init] autorelease];
[dialog loadURL:[[request URL] absoluteString] method:@”GET” get:nil post:nil];
dialog.delegate = self;
[dialog show];
return NO;
}

return YES;
}
[/CC]

We’re almost done. We need to create the callback delegate for this operation to reload our WebView after a successful login:

[CC lang="objc"]
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark Facebook Connect

- (void)dialogDidSucceed:(FBDialog*)dialog {
GTMLoggerInfo(@”succeded!”);

// try to reload webview after dialog succeeded
if ([[[self.tableView.tableFooterView subviews] objectAtIndex:0] isKindOfClass:[UIWebView class]]) {
[(UIWebView *)[[self.tableView.tableFooterView subviews] objectAtIndex:0] reload];
}
}
[/CC]

Voila. A working Like Button!

This solution however has a downside, the user may has to enter his credentials two times if both the FBConnect Login AND the web-login are used.

Related posts:

1. Use TTURLXMLResponse with server that send you the wrong encoding
2. Fix Mobile WebKit target behavior on OS 3.0
3. The Facebook-App Situation

So some stuff in encoding was weird. I replicated the feed on my server, voila, worked like a charm. http://beta.feedvalidator.org finally brought some light into the issue: “Your feed appears to be encoded as “UTF-8″, but your server is reporting “iso-8859-1″”

Okay. So the server fucked up. But we can’t change that, so let’s make our parser more robust. I am using TTURLXMLResponse (see their TTTwitter example on github)

So let’s override that! See the middle part for my change/hack/improvement. (Call it whatever you want)

[CC lang="objc"]

@implementation VIURLXMLResponse

///////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark TTURLResponse

// overridden from TTURLResponse to hack around voest rss feed!
- (NSError*)request:(TTURLRequest*)request processResponse:(NSHTTPURLResponse*)response
data:(id)data {
// This response is designed for NSData objects, so if we get anything else it’s probably a
// mistake.
TTDASSERT([data isKindOfClass:[NSData class]]);
TTDASSERT(nil == _rootObject);

if ([data isKindOfClass:[NSData class]]) {
NSString *utf8Response = [[[NSString alloc] initWithData:data encoding: NSUTF8StringEncoding] autorelease];

// oh ooh. server sent us data in ISO-8859-1? [hack around standards]
// http://stackoverflow.com/questions/1207867/nsxmlparser-rss-issue-nsxmlparserinvalidcharactererror
if (!utf8Response) {
NSString *dataString = [[[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding] autorelease];
data = [dataString dataUsingEncoding:NSUTF8StringEncoding allowLossyConversion:YES];
}

TTDCONDITIONLOG(TTDFLAG_XMLPARSER, @”Data: %@”, [[[NSString alloc] initWithData:data encoding: NSUTF8StringEncoding] autorelease]);

TTXMLParser* parser = [[TTXMLParser alloc] initWithData:data];
parser.delegate = self;
parser.treatDuplicateKeysAsArrayItems = self.isRssFeed;
[parser parse];
_rootObject = [parser.rootObject retain];
TT_RELEASE_SAFELY(parser);
}

return nil;
}

@end
[/CC]

Related posts:

1. Add Facebook Like Button with Facebook Connect iPhone SDK
2. Backup Server with rsnapshot
3. NSDateFormatter and +00:00 parsing

Having tried and used speech recognition myself (all started on my 400 mhz celeron … oh boy…) i really agree on the article’s essence. They just don’t get it right – and it’s more or less impossible to really get it right.

There’s also some current state-of-the-art software available. Tried it, failed. It’s not that it doesn’t work at all, but that you are faster typing than speaking, going to keyboard fixing, speaking again, hoping and checking, fixing….

Why on earth I am thinking now on the big great Android feature to fill *every* textfield with text-to-speech via google servers? I don’t know. Maybe it relates to this. (And yes, I tried it, and yes, it failed in a quite funny way. Maybe because I’m not a native speaker… maybe.)

I wonder how many people actually like this feature. I’ll add a comment here as soon as I see someone non-geeky using it. And don’t bash me now – there’s a difference between voice control and voice recognition. In short, the first may work

So again, it’s great for navigation, or other feature sets where you have a finite domain of answers. But it just fails on free speech.

No related posts.

No related posts.

See it? Shadows have the wrong path. I have the same bug with three20 builds. I wonder how this *ever* could go through their quality checking. After all, it’s a one-line fix. And TechCrunch’es argument, that it only applies to the unread-bubbles is wrong, the status-update bar has also the wrong (inverted) shadows.

They don’t mention iOS4 in their fixed section, so you can’t really blame them. But it’s really disappointing. After all, facebook was once the “leader” in app quality and was one of the first apps of the AppStore. But ever since Joe Hewitt walked away from the iOS-Platform, the project kinda stagnated.

There has been huge effort by facebook-employeed Jeff Verkoeyen on three20, the underlying open-sourced library that Joe built around the app. But the app code itself was apparently less touched…

For a company of this size there should be enough resources to do better. (and i’m not even talking about the Android version that really sucks)

It’s also interesting that there is no love for the iPad. Yes, the screen is big enough to support the Website without any “app”, but IMHO the experience would be much better. And people really *are* searching for the iPad-App, which some developer brought much money. (of course he is innocent… for sure…)

Maybe because there are ads on the website, and there aren’t anyone in the mobile apps… What do you think?

Related posts:

1. Add Facebook Like Button with Facebook Connect iPhone SDK
2. Fixing NSFetchedResultsController
3. pay for facebook? you already do.

I spent my two weeks in San Francisco @ WWDC with an HTC Legend. What, you think? It was my only *unlocked* phone, i got it for free – and I really wanted to try Android somewhere more in-depth. So I got a T-Mobile USA Sim and started playing. And no, I won’t go into the horrible cellular networks that are in the US… (God bless Austria for that!)

And I apologize for not having screenshots ready…

There are some domains where Android really shines:

1. The Notification Area. When you get different Push Notifications/Messages on iPhone, they (sometimes) overlap, but mostly you will loose the older one. That’s kinda annoying. On Android those notifications are collected in the status bar and are accessible from every screen, as long as the status bar is visible. I’m sure this will improve in later iOS versions. (Palm also has a superior notification system)
   Disadvantage:  There’s no scroll-to-top (like on iPhone) which in combination of a kinda wanky scrolling system is really missing.
2. Maps. I *love* the Places-Integration. It’s just that cool to have all data from Yelp, Urban Spoon right on the spot you searched for. (It may be useless in Austria but it was cool in the US)
   Otherwise maps felt much clunkier than on iPhone. Scrolling wasn’t smooth at all.
3. Systemwide back. It’s a yeah and sucks both times. Those extra buttons like back, search, menu take you away from your app canvas every time. It is supposed to be just the app. But with those hardware-buttons you (the developer) has to provide actions for every screen. But yeah sometimes they just don’t work.
   Systemwide back however, is pretty nice. Open a URL in Maps, go into the browser, press back, and voila, you’re back in Maps.

Let’s go to the bad things i noticed

1. Messaging. First, the system is not able to order my messages the right way when they were sent in the same minute. This leads to very strange message histories with garbled sequences. It’s very frustrating cause thats clearly a bug. I don’t know if it’s a HTC Sense issue or Android itself.
2. Message send failures. When message sending fails, you get a notification (good), then you get to the “Message sending failure”-Screen (good) and then you don’t see a button or anything to retry sending. It’s hidden under the Menu-Hardware-Button-Popover. I had a hard time discovering that.
   To be fair, it’s a 1:1 cause the iPhone doesn’t even has option to retry sending of all unsent messages.
3. The Keyboard. Much too much keys, two labels per key, and much junkier to use. To be fair, that’s an HTC Sense issue and was improved on Android 2.2. There’s an paid App on the Android Market that replaces the keyboard with an iPhone-nearish model, and i was pretty good.
4. Autocompletion. Sucks on iPhone too, but subjectively less. If you type and you look at the text, iPhone displays the proposals right where your text is. Android adds a text proposal bar right above the keyboard (like early prototypes of iPhone did) This takes up more spaces (as it’s added when you *start* typing, and not with animation but in a junky way.
5. Twitter. The official Twitter app is nowhere near as good as the Twitter app for iPhone. Nowhere. I tried Twitdroid too, but that was a total sucker. Added a notification as soon as I got new tweets, my phone was making noise every 5 minutes. But that’s supposed not to be an Android issue, right? Because it’s all the apps. But as a developer, the frameworks you get really make the difference in building a ok or a great app.
   I tried to upload an Image with Twitter for Android, and it crashed every time. Yeah, after I found my picture, because the picture browser is crazy slow (there isn’t even a delay on iPhone – on Android you can see each picture thumb loading after the other). And the order is wrong, you have to scroll right down to the bottom to get the latest pic (which is usually what u want – take pic and tweet it). Twitter for Android also often just lost my scrolling position, changing it a few tweets up or down. That’s absolutely unacceptable.
6. Facebook. The iPhone version is also much superior. As soon as you drill down on something, you are redirected to the Web-Interface of Facebook, where the iPhone-Version just does fine. I also didn’t manage to upload a picture to fb that was already on the phone, because pressing the picture-icon just opens the camera (instead of giving you a chance to selected saved pics)
   @westbaer on twitter told me that it’s only possible from the Android picture browser. So you go to a picture, press the action button and get this menu with all app hooks (which is kinda cool and not possible on iPhone right now). But then _another_ screen is opened, where you have to select the picture you wanna upload (same junky stuff as on Twitter, scrolling, waiting, scrolling, waiting). Why it doesn’t just upload the picture I was on? And why I can’t do that within the application?
7. This damn selection-ball. I don’t get it, I don’t need it and I don’t wanna use it. Hello, it’s all touch, remember? But I accidentally touched it and it changed my screen focus. It’s also ridiculous that this is the make-a-picture-button. I gave it to some people and most just messed up. As they removed their finger they made a touch-gesture on it, resulting in the active button cursor to be on delete, deleting the picture right after making it. Great. (And isn’t that supposed to glow on notifications? It never did)
8. Selecting text. Where’s my magnifier? It’s there _sometimes_ but it wasn’t there in messages or the browser. At least not when I tried to copy that damn phone number. (On iPhone you have data detectors that make the number click-able. It worked here, on Android most of the times not) After five minutes trying to get the cursor right before starting the selection mode with long-touching in input, then copying… and then every time THE WHOLE MESSAGE was copied. Which I didn’t knew, pasting it into the message number box unknowingly, resulted in a bunch of alert boxes that this was (obviously) no number. The only way out was to press the Home-Button as Message-App was pretty much killed with that action.
9. The Address Book. I don’t care where you save the Contact, can’t you just save it and keep my Google-Contacts in sync with my Local-Contacts? It’s a Google-Phone, isn’t it? And SIM, hahaha, I really don’t care.
   But it asked me every time, with no option to “make this default”. Sucks, totally. Also that you have to enter many sub-views to enter your data (like name – all happens on one screen on iPhone). And then try to scroll aaaaaallll the way down to the end of the form to find the save/clear button. Why it just can’t be on the top?
10. The Browser. Tabs? What is it, a joke? Switching tabs on iPhone already sucks, but on Android sucking got a whole new level. Press Menu, Press Windows, try to select your tab from the junky CoverFlow, activate it. But don’t worry, more than 4 or 5 tabs are not allowed anyway.
    The Browser is also way more imprecise when pressing small urls. I was used that most of the times i got it right – no chance on Android (this may be because of a worse touch screen, or was it just not calibrated correct? I don’t know, and honestly I don’t care – this is supposed to just work!)
    The Browser also doesn’t auto-zoom in when pressing on small form elements. It’s a small feature but you gonna miss it really hard – especially in combination of bad-working multitouch zoom. Try it and you go back to the on-screen-buttons (they are much more reliable)
11. Apps in general. The quality is much lower than I am used to. Some are _ports_ of iPhone apps, resulting in clunky copycated ui-elements that just aren’t there on Android. Must Apps look and feel very differently. There are some outstanding good ones, like doubletwist, but most of them are junk.
    On the iPhone AppStore, there’s much more junk. But also MUCH MUCH more apps that really shine out and make your live easier. Here, knowing most of the iPhone-Versions, most had less features, had a junkier ui and were slower.
12. The Market. I really wanted to buy some paid apps (maybe here is the good stuff?) but there were no attractive apps in the store. I finally bought a replacement keyboard (after downloading the free task killer app
    The payment process is a mess, I was forced to enter my credit card details on the phone, in a multi-step process. Even later on buying needs about 4 touches, compared to just one on the iPhone.
    Another suck-age is the return policy, which you just can’t do. Maybe a 79 cent app is fun for 20 minutes. People buy, download and then, after 20 minutes, just return it and get their money back. ERROR IN THE SYSTEM!
    Another error is that the LOCAL PRICES are displayed. So I see Euro, Pounds, Dollars, pretty much mixed up. Why? I only have one currency, and Google knows my country so it should be able to just recalculate that.

I keep that as a draft, pretty sure there are more things than that.

Related posts:

1. Version Adoption Rate: iPhone vs Android
2. “On Android, it’s fucking hell”
3. The Great App Bubble?

“This changes everything. Again.”

[CLLocationManager setLocation:]

Found at L3 on WWDC, some crazy kid…

No related posts.

I’ll gonna focus on San Francisco here and how it compares to Vienna/Austria, as the WWDC is just starting (I definitely will blog about that too!)

What’s great:

• American toilets! They don’t need toilet brushes, as it’s filled with water. Why isn’t that standard in austria? (Germans like to see their poo?) ^^
• The people. They’re totally friendly, talk to you, smile, and just seem to be happy.
• Starbucks. Oh my. I don’t feel bad going there (probably because SF doesn’t have a coffee house culture like Vienna ;o) And coffee is so much cheaper. Go on market street, you see them every 100 meter
• Medication. Maaan. Their pharmacies are more like stores, just grab what you want and go. Most stuff where you need to see a doctor and get receipts are just free here, get them in the 500-tablet-saving-box. (don’t know if that’s really that great)
• Smoking. Only homeless smoke in SF. Clubs and Bars are smoke-free. I love it. Btw, parties at Castro are freakin’ crazy! (They even run metal detectors when entering the disco ^^)
• You wander around at night, and a party bus full of screaming people drives along.
• Steak. Go to Mortons. Crazy prices (’bout 150 bucks), but it’s worth it, believe me.
• The skyline standing on Alcatraz.
• Glide Church. Awesome experience. Go there and hear them singing and praying!
• Golden Gate Bridge. Go rent a bike and ride over it!
• Silicon Valley. Go visit the Googleplex when its lunchtime. We just parked on the employees parking spaces and played being googlers. They have an awesome campus! Intel Museum is also worth a visit.
• Cable Cars. Go hang on them, it’s really fun!
• Go watch (and smell!) the sea lions, but don’t go to Pier39, it’s a tourist pit.
• Sour Bread at Boudin Bakery. U have to try those.
• Coit Tower. It’s not the tower, but the stairs up getting there. Flowers and beautiful gardens everywhere. U have to be really rich or lucky getting a house there.

What sucks:

• Homeless people. There are A LOT. On every street, on every corner. Or standing next to the ATM and want your money.
• Water. Yeah, yosemite national park or not, it’s strange, maybe because of chlorine or other chemicals, but it totally looses compared to our national water.
• Bread. You get muffins and whole grain muffins. Don’t even think of great rolls.
• Milk. nuff’ said.
• Renting a  car. Just don’t do it. U have to wait ages in traffic jams and don’t find a parking lot. You don’t need it anyway, just go by bus or bike, SF is not THAT huge.

We still have 10 days left (5 of them are for WWDC) and there’s a lot more on the list, expect part 2 soon!

Related posts:

1. Heading to WWDC 2010 @ San Francisco
2. About voice recognition
3. The Great App Bubble?

No related posts.