Show HN: Beautiful login and signup views for iOS with a few lines of code | Hacker News Reader

Show HN: Beautiful login and signup views for iOS with a few lines of code

blog.parse.com

82 pointsandwang36 comments

For those developers who also have to support Android, please please please stop porting your iOS code and its login/signup code/UI. Android already has a mechanism for dealing with accounts and they are already populated with Facebook, Twitter, Google, Skype, LinkedIn, Dropbox etc. You can add your app too if you want to be a provider of authentication/authorization for your service. All you have to do is use the AccountManager API - http://developer.android.com/reference/android/accounts/Acco...

This is my number one peeve with apps ported from iOS and highly annoying. The AccountManager system already knowns my credentials and can provide the necessary access tokens - there is no need for your app to have yet another crappy username and password prompt. My passwords are also excruciating to enter on mobile devices because they are long and varied.

There seems to be some sort of fetish over repeatedly entering passwords and usernames on iOS. Am I the only one who noticed? https://plus.google.com/110166527124367568225/posts/Xdnbu4RP...

One of the reasons they added even more of the Apple ID password dialogs is because of issues like this: http://in.finance.yahoo.com/news/apple-sued-over-apps-luring... Basically, without repeated re-authorization (generally via password), accidental or unintended purchases were causing them issues.

I'll agree it's not ideal.

All they need is a little checkbox "Never ask again". The never ending stream of password prompts I encounter also have nothing to do with paid apps - I don't even have a card associated with my Apple id and only have free apps.

The sad thing is, almost every major app on Android has gotten this wrong. I was personally the one who contacted the Facebook for Android developer to beg him to use their own app's account sync when they released FB Chat for Android. Of course there was a silent update two days later that did not require the silly and redundant login.

There are many things like this. Developers whine that "it doesn't work well on Android" because they don't bother to learn how it should work on Android and just port their iOS app are surprised that it doesn't work well. iOS and Android are pretty darn different when it comes down to the details that matter in applications.

(IE: Instragram on Android is almost silly, whereas it seems nearly necessary to make the camera in iOS worthwhile).

Please elaborate on why you think Instagram on Android is silly. I'm don't quite follow.

My idea of beautiful is a bit different than this.

This is convenient, but I don't know about beautiful.

It's not convenient, because you have to use this entire Parse thing (and pay for it).

The headline is bullshit click-bait.

You will have to pay for any server back-end, but the pricing is very favorable and they have a really nice free plan as well.

Fine, but the headline is still bullshit.

I agree abou the headline, I don't think you could call the design beautiful.

Also the "x" button on the top left adheres to absolutely no conventions or expectations.

Officially adding "beautiful" to the words and phrases that make me shudder:

- beautiful

- ninja

- rockstar

- web 2.0

- social-mobile-local

- ajaxified

- "I have an idea for an iphone app"

- gamification

- hyper-local

I better not tell you about my beautiful ajaxified hyper-local social-mobile ninja game then.

I absolutely agree with rockstar. I cringe when people use that word to describe programmers or designers

So is everyone else's. What's your point?

I've been using Parse for a month or so and I've been really impressed by how powerful the platform is, and the rate at which they are adding features and libraries. I also have to say they have some great customer service and take bug reports and feature requests seriously and professionally. I have yet to deploy with them, so I can't speak about performance or scalability, but if anyone is interested I could document my journey. Kudos to the Parse team!

I'm impressed that your account is a whole 5 minutes older than your post. I'd be even more impressed if Parse was open source instead of yet another walled-garden PaaS hyped by shills.

I've been following Parse for a while now, and I agree with technogarden. Their platform is impressive, and they're adding useful new features at a rapid rate.

It would definitely be cool if they open-sourced the platform, but, in the meantime, you might be interested in this project:

http://code.google.com/p/openmobster/wiki/learnmore

Personally, though, I don't mind paying for a service like Parse. If someone is willing to not only build the features I need but also to wear a pager and get up at 3am just to keep my users happy, I'm more than happy to give them some of my money.

Same here, happy to give money to make a pain point go away so I can focus on the product itself.

My only wish was that I could place an easy API layer between Parse and my app, because I would want more fine grained control over how data is mutated (even with ACLs, someone with write permission could mutate data and corrupt it if desired).

There's a REST API, but I don't think I would want to use that as much.

Check out Weary (https://github.com/mwunsch/weary/wiki). It's a framework for building REST clients in Ruby. Clients written with Weary are also Rack apps which can can be mounted in a Rails app, for example. Then you can add your own layer of authentication/whatever to the Rails app which will act as a proxy to your Parse db.

Not only is your comment incredibly rude to some really nice folks, but it's also wrong.

Here's some data I exported from one of my Parse accounts: https://gist.github.com/2475461.

It might be rude, but he's not wrong.

Deploying APIs in the cloud for primary use in mobile apps is an oft-repeated/able task, and it doesn't seem like there's anywhere near enough value in the Parse API on top of what you get from the native SDKs and a solid combination of open source stack software supported by an enterprise track record more promising than a Series A round a few months ago.

Also, as the comments here suggest, there are a lot of slight modifications to the default use case that reward having solidly built a stack not built on yet high-level PaaS abstraction. Sorry, but a JSON representation of your data is the low bar, not some instant proof that the product is magic.

Parse isn't a high level abstraction, they just like to make certain things more convenient, if you want you can just use them as a database with a rest api over it.

In terms of value ... I'm really not sure how you lose - if your app is a flop you're going to coast along on the free plan, if it's a success you can focus on your app rather than your stack, and you can migrate away from them when you feel like it.

Not everything needs to be open-source. Its a good product and they deserve to charge for it.

Not everything that charges money needs to be close-source.

I'm not advocating Parse open source anthing, it's entirely up to them but open source does not mean $0.

I think one of the hardest part of login views and other forms in iOS is dealing with the keyboard. You don't want the keyboard to hide stuff but you also don't want emptiness where they keyboard would be when the keyboard is not visible. Also they size of the keyboard is not fixed. In this particular case, the input accessory view of some keyboards, such as the Japanese keyboard would overlap with the button. In the case of a login view, you want to trigger a login event when the user touches the Done button as opposed to making the UITextField resign its first responder status, which means that on the iPhone the user won't be able to dismiss the keyboard, so all the other login options as well as the sign up button will be hidden forever if the user changes his mind. Ultimately, you want to have the whole thing in a UIScrollView (or a UITableView) to avoid such problems. And leave more space for the keyboard.

  > Ultimately, you want to have the whole thing in a
  > UIScrollView (or a UITableView) to avoid such problems.

Or you can just change the class of background view to UIControl and wire it so it calls resignFirsResponder on inputs if touched.

Yes, that would work as well, but if you do that, you have to make sure that you leave a wide enough margin (at least 44 points wide) on each side of the controls to allow for touching the background.

You can scroll the entire screen up by exactly the amount needed to prevent the keyboard from obscuring the field. It doesn't even need to be on a scrollview.

You'd think the framework would do that (or at least offer that), but nope.

This is also a good approach, but if you do that, you have to remember two things. First, you can only reliably measure the height of the keyboard at runtime, and the keyboard size could change even after it was displayed (if the user touches the globe button to change the language of the keyboard). Second, if your app supports the iPad as well, you have to remember that on the iPad the keyboard is detachable since iOS 5 so make sure you won't have anything ugly (like a big empty black rectangle) where the keyboard would normally be.

I love using Parse. We are integrating them into two apps we are currently building, Reminders With Friends[1] and Hiiire[2]. If anyone has any questions about my experience feel free to contact me.

[1]http://www.slyceapps.com/reminders

[2]http://www.slyceapps.com/hiiire

Tried to get in touch but the only email I could track down on the website in your profile was your support email. :)

snagra[at]slyceapps.com

Welldone parse. Good job. I hope you guys are moving on to the HTML5 areana pretty soon. I don't like the current HTML5 support you have. It allows JS to handle your full DB. If I am wrong please correct me

Not related. But their blog served over HTTPS throws an error: https://blog.parse.com/

Reply on news.ycombinator.com