So before building something that relies on things entirely outside of your control, consider a few things and the effort it would take for each:
- Can you run it on something else (S3 is a good example - there are several API-compatible competitors) - Can you replace the service you're relying on with one of your own (e.g. building your own Google Reader sync API)
Then decide if it isn't worth building the whole thing yourself. Heck, you might even want to put an API on it yourself. Feel the power? :)
Oh, and never, ever rely on someone else doing authentication for you. It's just too easy to get your entire userbase taken away from you.
Your argument is exactly why I don't use Google AppEngine. I know there are open-source stacks now that you can use if you want to take your AppEngine code in-house, but trying to build up an AppEngine infrastructure at probably the worst possible time ("we're getting billed @ $10k/month, but only making $8k! getting more popular will cause us to lose more money! quick, switch to custom servers!") when you can build up a solid infrastructure using technology that you can replicate on any VPS or managed box or colocated hardware that you buy seems the easiest way to scale.
So what's your solution? Write everything in assembly and run it on your own servers?
I think the way to proceed is to look at the stability of the API and the historical level of backwards compatibility that the API creator has provided and explicitly take that into account when you're developing an application. This is one of the things that Microsoft does very well, better than Linux (where GUI APIs, especially, seem to mutate every few years) and OSX. In general, though, any desktop API is much better, in terms of maintaining backwards compatibility and announcing breaking changes, than any mobile (iOS, Android, etc.) API, and mobile APIs, in turn, are better than web APIs. This isn't a case for never using mobile or web APIs, but it is a case for ensuring that you have enough resources (or a loose enough timeline) to deal with API churn as well as developing new features.
The only way to get away from APIs entirely is to write your own code, run it on your own OS, using custom hardware that you've designed yourself. That way lies madness, or, equivalently, game console programming ;)
Is the criticism due to the annual version update? Or is it because there are API changes every new version? If it's the latter, wouldn't updates be expected, and in fact desired? It may just be me, but I've had good experiences when it comes to API stability with iOS. I've been unable to keep up with the newer features (I'm indie and only work on apps jn my spare time) but the new features rarely get in the way of my app being able to run with the calls they are already making.
I'm aware of the UDID deprecation from before, but devs were given plenty of time to transition from it. Actually, I was surprised how much time they gave.
Persona is perfect for blogs, but using it for a service people may be paying for, or handles any private user information (postal address, private messages or posts on a forum etc) is a bad idea.
I feel you should mention whether or no you pay for the API and have a legitimate contract enforceable with law.
This is one reason why I don't use google APIs; I can't pay for them with any sort of reasonable SLA.
For authentication I'd argue in some ways it's better to provide the option of third-party. This means users don't have to submit credentials to you. Given most people (against advice to the contrary) use the same username and password for most sites signing up to an unknown company's service feels riskier as they're then giving that company their credentials, which someone may then try on other sites - having a token which allows them to sign in with their Google/FB/Twitter/etc account saves this worry / only requires the user to hit an "authorise" button.
- Be careful with companies that don't sell the API or SDK as a product (Twitter, Google, Faceboook, etc.)
- Watch out for companies that don't like to publish roadmaps and makes APIs and SDKs deprecated or obsolete with little warning (Apple, and more recently Microsoft)
Because you pay for S3, AMZN has many incentives to make it reliable and keep it going.
A free API might look like a giveaway, but it is ALWAYS a chance to take.
Can you give an example of that?
I believe at some point iBooks could go to a darker brightness setting than other apps were allowed to.
Those are the two that jump to my mind.
Also, there's no open bug tracker. The developer relations people are very friendly, but when I ask where to report bugs I'm told "just tell me". So every 2 months I've reported the same 3 bugs in person and they get swallowed up and that's the last I hear about it until my next report.
The silly thing is that we were one of the showcased applications in Google I/O this year, for the Drive section. A number of Googlers came past and said "Wow, cool. Please, please commercialise this". The truth is, we can't and it's because of the bugs in Google's code (well, partly, the other problem is Drive has just been too unstable over the past 4 months, until there's 99.9% uptime for a year, we can't consider it).
Don't get me wrong, I love what Google are doing with their API stuff and the dev relations really go out of their way to help (specifically the Drive SDK team). But, as it stands, this isn't a platform I'm confident in building a critical business product on, currently.
EDIT : That last sentence is wrong. I'm confident to build a critical business product on it, I think it'll get there, I'm just not confident to charge money and have to support it, at this point in time.
While the api is a little funny, it's clearly very powerful. Anyone criticizing the move to work with Google API's at all should keep that in mind. But the nonexistent service and unreliability of the API are hard to overcome.
TBH, I don't really want it to be that I whine in a very public place and the bugs I personally need fixing get priority.
What I'd really like to see come out of this is a public facing bug tracker for the Drive SDK that people can vote on and priority be given to the most voted for/most critical issues as viewed by the developers.
I can throw one onto github, as long as you don't mind something unofficial.
[0] http://stackoverflow.com/questions/13971272/is-there-a-way-t...
[1] http://stackoverflow.com/questions/13366254/is-it-possible-t...
[2] http://stackoverflow.com/questions/15664523/cant-get-google-...
And three nines is still 45mn of downtime per month.
I would call that an edge case and launch the rocket. Just drop a comment about it in the FAQ.
Unless, your product is strictly about multiple Google accouncts in which case you are shafted. :)
That's 50% of users. All we needed was one user out of however many were on the domain to remark and the feedback was "sort out the details" and these were the details.
As also mentioned, the availability of Drive documents to our apps and the app integration working correctly was also a factor.
I've evaluated what they are doing on their technical merit. If you want me to give you a detailed explanation of why I prefer their system, it'd probably take about an hour, so it's a bit much as a HN comment.
I genuinely think their direction with the API I'm using is the way forward, I've been waiting for someone to have the balls to do it for some time.
Any anyway, I must have missed the outpouring of love Google received for closing Reader, for not having a native Google Linux kernel OS Drive client, and so on.
If they'd turn evil over night or just stop existing, we'd still have a big net positive left. Not something that can be said for some competitors.
Anybody has collected more down's for one comment, or is this some kind of record?
That simply isn't true. They have support for some very specific areas which they consider of specific importance (e.g. Android), for the rest you're left to rot.
> Perhaps they do not have a corresponding relations team focused on operations support.
This has nothing to do with ops, it's a developer needing a raise in his apps requests quota.
If some one came to me saying my employer is saying I am a poor performer and trying to sack me and gave the Google apis's and its documentation as an example I would have sympathies with the employer.
BitPay as a payment processor in particular: https://bitpay.com/
But you can definitely accept money using premium/business acounts. Premium account requires only your PAN.
You, you really aren't persuasive for anyone.
I usually lurk, I probably make an average of 5 comments per month. When I do make a comment, not only on HN I usually make a new account.
This is in constrast to many other big companies where you get at least some reply (although it's often canned and not very helpful, but still more than a generic auto reply), or where you can call a more or less expensive hotline, so you can at least pay them for hearing your voice.
This behaviour of Google is so restrictive that it even violates consumer protection laws in some countries. For example, here in Germany they got into trouble because they violated the so-called "Impressumspflicht". This law requests that they have to provide (among others) at least one postal address and one telephone number on their website, and that they can actually be contacted by those, in 60 minutes or less.
http://translate.google.de/translate?hl=de&sl=de&tl=en&u=htt...
http://translate.google.de/translate?hl=de&sl=de&tl=en&u=htt...
This lets you develop apps on Exchange (similar to your tasks app). See http://msdn.microsoft.com/en-us/library/jj220499(EXCHG.80).a... and http://code.msdn.microsoft.com/office/Exchange-2013-Create-t...
Office365 customers (all of them are paying customers) who find it useful can install the app on their accounts. You don't have to stuggle with PayPal issues as Microsoft will pay you through the marketplace account after charging the customers.
Office365 support is excellent as well (they even do phone support). No need to chase anyone on Google+.
(I'm not shilling for Microsoft. I have no financial interests here).
Paid or unpaid, this post is pretty much shilling.
Keep persisting, but as a temporary measure I would prompt your users to provide you with their own API key. Lots of apps do this (such as CMS plugins). You can give them a link to the API portal and explain in 2-3 points how to generate a key and paste it back in your app.
Also, your app is in debug mode, so errors are showing a complete stack trace. Your database is also down right now.
FTFY
But, as one of my clients would attest, even if you're a paying customer, you may still be left hanging in the wind. I hope they don't start spreading the YouTube feedback treatment to all their services.
If they spent 15% of that ($2.1 bil) on support, with say a mix of 2/3 low pay ($100k/yr cost) and 1/3 high pay ($150k/yr cost) people... they could hire 18,000 additional support staff and still show a great profit.
That works out to 30 mil support hours assuming 1680 hrs/yr (35 hrs * 48 weeks) actually spent on support. They could probably hire twice that many people by hiring some people in less expensive areas.
To sum up, Google puts making a more money ahead of better support. It's their right to do so, but it not "unrealistic" for them to provide much better support.
I want Gmail Tasks to be world recognized and people to use it more frequently. I see that there are very less standalone apps developed for Tasks, this is a small effort by me to make Google Tasks better and more usable.
If you find value in what I am doing and see it innovative enough, please help.
Thanks for giving me an opportunity to build an app on google.
I also think there are development enhancements you could make to your application to work around these problems. Maybe you won't get any response from Google until you have 2M users? What are you going to do about it? There have been some excellent suggestions in the comments for working around this (longer waits before retries, premium level retries etc). Do these first, increase user base, then contact Google when it's less easy for them to ignore you.
See "I'm a developer and used Google's developer products/tools to create a new product. Can I use the Google name?" on http://www.google.com/permissions/faq.html
Based on my experience, each team individually deals with quotas for their API. Google Tasks is not really a dedicated product so it probably has little to no permanent team behind it. This is probably the cause for the slow response time on quota requests.
Thankfully it was a real person who actually knew what they were talking about and were able to sort it out over a chain of emails.
So yeah, I guess it is team by team.
Does this mean that as soon as your app becomes popular, you are doomed to fail?
I've looked briefly at a few Google APIs and they seem strange. So there's no longer a straight search API, you have to put some params on a "custom search API" that only has something like 100 searches per day? But on the other hand, hit the Google Local Business API and you can make 10k requests...and then there are APIs that were shut down all together, like translation. This is really weird to me. Is it supposed to make any sense?
Some services have prices over the courtesy limit (Translation) while others just have a max. What happens for like the Books API when you get above 10k/req/day?
1.) You are clearly young and do not know: if there is something on the internet you do not like, go make it yourself. What obligation does Google have to do something for you? None! They are providing mostly free services, but if you don't like it (or the support), go make your own and quit bothering people (and Google).
2.) You have no relation to the GMail Web Application, yet you specify: "Founder GmailSharedTasks" Remove the Gmail from your description and build out your solution without trying to get a free ride.
3.) Your Google Groups post can be summed up: "Cry! I'm not getting any attention for my pet project!" Instead of crying, create your own solution that does not leave you at the mercy of a company or individual who sees you only as "1 of billions". Get over yourself.
4.) You know how to code, you know how to integrate with FREE APIs, now learn what it takes to run a business.
1) Why make it again if there is a platform already existing ? why not bother them : please check this link http://productforums.google.com/forum/#!topic/calendar/vdFSJ...
2) Yes, I know it is my fault
3) I would rather chose not to comment on this.
4) Why create my own API ? If someone as good as Google has already build it ? I know how to code and have built this app within 3 months.
and yes I am a young developer and I know what business is. I know about code re-usability and providing a great user experience.
Regarding building of my own API, I could have done that but I always wanted to make Gmail Tasks better, because I have been using it from past two-years.
Learn to praise the people instead of finding negative aspects.
The quota request was denied, but we (Google) failed to communicate the decision properly / at all. Sorry about that.
It's a tragedy. He doesn't want to spend the time to build his own platform, and Google won't enable him to develop effectively for theirs.
Google are tarnishing their brand, eroding their user base, and compromising their platform, all in the name of what? Avoiding the inefficiency of dedicated support for a global brand?
One drawback in having people build their apps on top of you platform is that then you are stuck with the way things are. If you have popular apps depending on the current task system, you can't just take it away or move it to Google+ (or you can, but then you get lots of whining).
One missing piece if the puzzle that is really going to make this idea if a shared platform across companies is moving to encrypted data oriented networking instead of server based networking. Not only does that model make vastly more sense in terms of the real topology of internet use now with data being propagated to leaf nodes, but there are also very strong reasons to move to distributed encrypted computing for privacy and economic reasons. A server based internet means server based web apps which is going to continue to result in due facto platforms created by individual companies.
This issue almost took more than a year to get fixed - I had to drop a project midway and start with other technologies from the scratch to build the same thing.
The developer experience could have been better.
