We stumbled across a deprecation notice for the Gmail sidebar gadgets at https://developers.google.com/gmail/sidebar_gadgets which states that
Warning: Gmail sidebar gadgets are now deprecated and will soon cease to be supported.
This statement and the website are unclear and we cannot find any deprecation notice with specific dates and impact.
Additionally, since the add gadget by URL lab was deprecated, most of this page can't be used anyway.
However, we deployed a gadget via the marketplace which is crucial to our operation of Google Apps because of the Google Apps 50K contacts limit.
I've submitted a ticket to the GWSC with the following questions but I figured I would mention it here as well since we are a bit shocked to have stumbled on this notice and that it hasn't been shared via any channels we have found. Perhaps I missed it?
Does this sidebar_gadget deprecation apply to marketplace apps such as the one USAID wrote and is using?
Can you please point me to the official deprecation notice and especially the date of impact?
What will be replacing the sidebar gadget as this is an integral part of our day to day use of Google Apps?
Any input appreciated as I'm specifically worried that Google did not anticipate people doing things with sidebar in marketplace apps and when they took away the gadget by URL lab, they thought they killed the only avenue to using these gadgets. Hopefully, I'm worried for naught and marketplace apps are fine but...
Regards,
KAM
Google usually perform spring-cleanings. Usually announces around march-april which features will be removed, and by july-august performs removal. However marking a feature as deprecated does not necesarilly mean immediate removal.
Also, maybe this is related to Google G-suite marketplace: https://gsuite.google.com/marketplace/
BTW: in any situation, combine something that "is crucial to our operation" and something that depends on a closed SaaS or cloud plattform it's usually not a good idea, except if your data/services/developments can be moved to other platformS.
Related
We have uploaded our game app at Google Play successfully. When we tried to upload a second version, we noticed that our app has been restricted in our country. When we investigated we receieved a message from support team stating that the app indicates gambling and that it doesnt match the ranking of "All Ages". We have got a review from IARC stating that we are not having any issues or relation to gambling.
We contacted support again to resolve the issue, but they stated the following:
"The app contain simulated gambling, or games of chance or skill that are conducive to gambling are prohibited in the above locale"
We have done all necessary measures and took the extra mile and change UX to remove any indication to gambling though it doesnt have at the first place. We are suffering from poor communication with support team, and need a super fast fix. Any Recommendations?
Unfortunately this is nearly unsolvable problem, I've faced this and after more than 1 year of appeals with Google I couldn't convince them that my app does not contain any gambling.
Once they flag your app as a gambling app it is very hard to change it.
Most of my home automation is controlled internally (timers, events, scenes, etc). I also have voice control (mainly just for fun). I have some google home devices scattered throughout the house with a few IFTTT phrases like "Open the blinds in the $ (e.g. lounge room)". When that phrase is triggered, WebHooks POSTs a request to my home server to open the blinds.
Anyway it would be nice if I could just say "Open the blinds" and the room would be implied by which Google Home device processed the phrase. That doesn't seem possible with the IFTTT services. It actually seems like a glaring oversight, so maybe I'm missing something.
Any ideas on how I could implement this seemingly simple feature? (I'm hoping I won't have to query the Google Assistant myself).
I think I have enough information now to answer my own question. The 'IFTTT Platform' seems to be the key to all my requirements. It will give me greater access to the Google Assistant API (magnitudes greater than the IFTTT GUI). However, it's a steep learning curve:
Step 1: Learn the Ruby programming language
Step 2: Umm I'll get back to you on the next steps :)
I'm currently having a lot of trouble with the google API support team and was wondering if anyone had figured out their process. I'm developing an extension that uses identity.launchWebAuthFlow() to authenticate with google for google drive access. Since July 2017, google has started requiring "Verification" for oauth. As I don't own my extension's domain {random}.extensions.allizom.org, I have no idea how to pass their verification requirements.
You can read about that process here: https://developers.google.com/apps-script/guides/client-verification
They've rejected me once saying my client id is deleted or invalid or does not need verification - I verified that the client exists, is still servicing requests, and still produces the unverified warning screen detailed in the link above.
When I reached out specifically to webstore support, the response said:
Dear Brandon,
Thank you for contacting Chrome Web Store Developer Support! I understand that you're having an issue regarding developing a web extension for both Chrome and Firefox using Google Drive API. As much as I'd love to assist you, unfortunately, our team cannot offer much support on this matter. My best advice is to ask the community on Stackoverflow, or create a bug report directly to the Chrome Browser/Extension experts using the Chromium Public Issue Tracker. The engineers are actively working on the reported problems on this list, so I'm sure that you'll be able to get the information that you're looking for.
I appreciate your understanding and cooperation. Please let me know if there's anything else I can do for you, I'm happy to assist. :)
Warm Regards,
[Redacted]
Chrome Web Store Developer Support
Again the major problem here is that I cannot prove ownership of the identity.getRedirectUri() for my extension as the requirements state. I know other addons use google APIs, but I don't know if this verification process is a way to ban firefox developers from the google api ecosystem.
As a bit of question justification, I can find no documentation anywhere from July 18 2017 or later where developers have run into this, and I think this question will provide significant value to any Firefox addon developers who seek to use any of Google's APIs.
The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3
The Tango Constructor app is referenced in list of Tango tools
Tango Constructor
but it is not available or listed in the Google Play Store, at least in the USA.
Thanks.
After several release update on the Tango API,
We had new features, which may not backward compatible with the older version of APKs, we do care about usr experience for customers. we took down TangoConstructor and so other apps which is bad at this time.
Once we have new fix for those apps. it will be back online.
We will let you know once it is available again.
I also had the same question and sent a message to Google. Their reply:
"I have double checked with my team and it appears the app is being updated and it is not because of your country. That is most likely why you're seeing that message"
I think the current version is not compatible to Zaniah so they removed it for now. It is like with "ADF Inspector" which is still available on play store, but when you try to load an ADF, it crashes.
By the way, I'm from Germany and I also see this "not available in your country" message. So it is definitely not because of region restrictions when it is not even available in USA