I have read about new Google Apps Marketplace and have seen the overview video here.
I'm worried about migration from OAuth1 to OAuth2 and having impact to some developed applications with APIs in my domaine
in the video exactely in 24', comparaison of what libraries/APIs are used in the OAuth1 vs OAuth2, and in 27' talking about turning off the OAuth1.
these Libraries/API will be deprecated ?
Any idea about turning off the OAuth1 and when ?
You need not worry about the impact of OAuth1 to OAuth2. This transition can be completed in a max of 15 days if you have done many integrations with Google. If you are worried just about the SSO with OAuth2 this can be completed in a day as Google has already provided proper documentation regarding the work flow.
Google has even provided migration APIs to upgrade your customers domains from v1 to v2 of Google Apps Marketplace(GAM). If you have a huge user base to be migrated then you need to plan accordingly such that migrated and non-migrated users would be able to use your app for some days till the migration is completed successfully.
Google will announce if it intends to discontinue or make backwards incompatible changes to this API or Service. Google will use commercially reasonable efforts to continue to operate those Google Documents List API versions and features identified at http://developers.google.com/google-apps/documents-list/documents-list-api-list without these changes until April 20, 2015, unless (as Google determines in its reasonable good faith judgment):
So on a safe side it is better to migrate all of your APIs to the latest libraries to avoid any failures at a later point of time. Anyway the older versions are not supported for any issue fixes/ support from Google side. So it is always better to migrate your APIs
Older version of GAM(v1) will also be deprecated at some time but Google hasn't provided any timeline for this. Probably it may take a year(not sure)
Google strongly encourages you to migrate your marketplace application to OAuth2 as soon as possible. Google has already announced deprecation of OAuth1. All top apps on marketplace have migrated their customers to OAuth2 with no issues. We plan to stop allowing installs of OAuth1 applications in near future from the marketplace (specific timelines to be communicated separately).
Related
Apologies in advance for the seemingly naive question, I'm a hobbyist developer learning the ropes. I noticed the opentok REST API documentation deal mainly with command line stuff, whereas the SDKs (web/node SDKs for example) come packaged with class instances, methods, etc. So is one a reference for the other? How/when does one use the REST API instead of the SDKs?
Vonage Developer Advocate here.
Our server SDKs provide a language specific wrapper for our REST API. Both are focused on session & token generation and archiving. This logic is usually processed on the server side.
The client SDKs are different in that they provide capabilities for the front-end.
I have published my app ("Match4app") recently with multiplayer feature, after months of hard working, using the Multiplayer APIs in Google Play Games Services.
Now, I received an email from Google:
Real-time multiplayer in Play Game Services is going away on March 31, 2020.
We’d like to inform you that on March 31, 2020, the real-time and turn-based multiplayer APIs in Google Play Games Services will no longer be available.
Action required
Because some of your games use one or both of these APIs (listed below), you’ll need to find replacements in order to continue offering multiplayer experiences. Migration options include using Firebase Realtime Database for multiplayer hosting and Google Cloud OpenMatch for matchmaking. You can log into your Cloud account to use Firebase Realtime Database for free with the Spark Plan.
We know this change requires extra work on your part, and we thank you for your understanding. If you have any questions or concerns, please let us know by filling out.
Questions:
How difficult is this "extra work" to migrate my game to "Firebase Realtime Database" and "Google Cloud OpenMatch" ?
Is there any tutorial with simple step-by-step instructions such as "1. replace mGoogleSignInClient.silentSignIn() with "FirebaseSignInBlaBlaBla... 2.replace this by this, etc." ?
If there is no simple migration and this requires an implementation from the scratch, is there any tutorial to make a multiplayer game with "Firebase Realtime Database" and "Google Cloud OpenMatch" ?
This "Spark Plan" seems to be free. However, this comes with limitations according to this link:
https://firebase.google.com/pricing/?hl=vi
Simultaneous connections: 100.
Is there any other "free" alternative, similar to the deprecated Google APIs ?
Answers:
There's lots of work to do. It's a re-write from scratch.
No. You still need to sign in, but you need to do a whole lot of OAuth stuff in order
to authorise your client via Google Play Services and your Firebase database.
There's a few youtube videos on it, but they always go the easy route of providing random opponents. None of them provide a player search if you want to play against a certain opponent (like GPG used to do).
Not that I could see. I'm moving our game to random players as there seems to be no real solution. Google Cloud OpenMatch seems very nebulous. I can't work out if it's a backend only, or whether I have to install it on my own server.
Since CodenameOne doesn't support "the cloud storage API" any more and the parse.com is going to retire soon as well. Does CodenameOne has any plan to release a new Cloud Storage API or provide suggestions/guidelines to help developers to deal with the parse4cn1 library code, cloud code, database structure and data in parse.com?
That is something you will have to figure out yourself as parse4cn1 was initially contributed by a community member and wasn't developed by Codenameone team.
You can use a simple webservices created in php, python or java, hosted along your content with any ISP.
You may also have a look at amazon aws which is promising, they provide a cloud solution but their SDKs is not yet integrated to Codenameone.
I made the parse4cn1 lib and I'm also wondering what's smartest to do. With the announcement of Parse.com's imminent shutdown, there's been a lot of discussion around alternatives. My feeling is that "the dust is yet to settle" as per what options are best and reliable for the longer term (it would be a pity to migrate to another service only for it to be shut down soon). So I personally plan to wait till sometime in Q2 to do a proper evaluation of the alternatives. Hopefully, there'll be more clarity then.
The option to host one's own Parse server (e.g. on AWS or Heroku) is getting interesting. They recently announced support for push notifications on iOS and Android. If (when?) they open source the Parse.com dashboard code, I think that option would be much more interesting.
At some point in the coming months, I plan to make a parse4cn1 release that exposes an option to set the server path. With that, anyone migrating to the Parse server option should, in principle, be able to continue to use the cn1lib. Of course, for features that are supported by the open source Parse server.
PS: Here are pointers to some of such discussions on Parse alternatives:
https://github.com/relatedcode/ParseAlternatives
http://www.slant.co/topics/5219/compare/~firebase_vs_kumulos_vs_kinvey
I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.
I try to research realTime api with yammer document.But when I browse "https://developer.yammer.com/realtime",it redirect to "https://developer.yammer.com/realtime-deprecated". Does it mean yammer will not support realTime api in the future?
Starting August 2014 we are removing the Realtime API from the documentation. While the Realtime API will continue to be supported and work, it will no longer be available on http://developer.yammer.com/.
We decided to remove it from our documentation because it no longer fits into our longer-term strategy and, while it will still be supported for the foreseeable future, we did not want new developers using it. Also, it’s been available for about 4 years and usage is relatively low.