31–39 of 39 posts
Earlier quoted context omitted.
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.
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…
You'd think the framework would do that (or at least offer that), but nope.
Earlier quoted context omitted.
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.
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 .
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.
Earlier quoted context omitted.
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 h…
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.
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 Ac…
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 A…
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…
> 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.
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…
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.