we are developing 3rd-party apps on Nest Hub Max and currently using Interactive Canvas that triggers webhook HTTP requests. But Interactive Canvas won't be supported as part of the Conversational Actions Sunsets. The suggested alternatives App Actions doesn't support visual screens, so what are the alternatives for developing 3rd-party apps with visuals on the Nest Hub Max (in replace of Interactive Canvas and webhooks)?
Related
Where can I find list of PWA features that are supported and under development for each browser?
This will greatly help to determine if I shall develop a native app or go directly for PWA. And also know upfront what to expect in the foreseeable future in terms of browser support so that I can enhance my app with newer features.
Thanks
Actually you can try
https://whatwebcando.today/
for test your browser first
Web App Manifest, and
Service Worker API
seem to be the key technologies to watch. Google's Progressive Web App Checklist mentions both of these technologies.
However, other technologies such as BeforeInstallPromptEvent, or PWA installation notifications, are explicitly discouraged by Mozilla Developer Network, MDN:
Do not use it [BeforeInstallPromptEvent] on production sites facing the Web
Also, as an aside, commercial incentives for PWA's appear to exist:
The Supreme Court signaled Apple could face a revived antitrust
lawsuit over its price control [...and 30% take] of the iPhone and
iPad App Store. -Fortune
Google indicates that a progressive web app, PWA, is:
Progressive - Works for every user, regardless of browser choice because it's built with progressive enhancement as a core tenet.
Responsive - Fits any form factor: desktop, mobile, tablet, or whatever is next. Connectivity independent - Enhanced with service
workers to work offline or on low-quality networks.
App-like - Feels like an app, because the app shell model separates the application functionality from application content .
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search
engines to find it.
Re-engageable - Makes re-engagement easy through features like push notifications.
Installable - Allows users to add apps they find most useful to their home screen without the hassle of an app store.
Linkable - Easily share the application via URL, does not require complex installation.
You can check this blog about the features of PWA. Also based from this documentation, Chrome, Opera and Firefox have all implemented support for service worker with Edge having positive public signals about interest in the feature. Safari briefly mentioned interest in it via one engineer's proposed five year plan. You can also check this related thread for more information.
I’ve already built an Alexa skill, and now I want to make that available on Google Home. Do I have to start from scratch or can I reuse its code for Actions on Google?
Google Assistant works similar to Amazon Alexa, although there are a few differences.
For example, you don't create your language model inside the "Actions on Google" console. Most Google Action developers use DialogFlow (formerly API.AI), which is owned by Google and offers a deep integration. DialogFlow offered an import feature for Alexa Interaction models, which doesn't work anymore. Instead, you can take a look at this tutorial: Turn an Alexa Interaction Model into a Dialogflow Agent.
Although most of the work for developing voice apps is parsing JSON requests and returning JSON responses, the Actions on Google SDK works different compared to the Alexa SDK for Node.js.
To help people build cross-platform voice apps with only one code base, we developed Jovo, an open-source framework that is a little close to the Alexa SDK compare to Google Assistant. So if you consider porting your code over, take a look, I'm happy to help! You can find the repository here: https://github.com/jovotech/jovo-framework-nodejs
It is possible to manually convert your Alexa skill to work as an Assistant Action. Both a skill and an action have similar life cycles that involve accepting incoming HTTP requests and then responding with JSON payloads. The skill’s utterances and intents can be converted to an Action Package if you use the Actions SDK or can be configured in the API.ai web GUI. The skill’s handler function can be modified to use the Actions incoming JSON request format and create the expected Actions JSON response format. You should be able to reuse most of your skill’s logic.
This can be done but it will require some work and you will not have to rewrite all of your code.
Check out this video on developing a Google Home Action using API.AI (that is recommended).
Once you have done the basics and started understanding how Google Home Actions differ from Amazon Alexa Skills, you can simply transfer your logic over to be similar. The idea of intents are very similar but they have different intricacies that you must learn.
When you execute an intent it seems as if your app logic will be similar in most cases. It is just the setup, deploying and running that are different.
We currently deploy a CMS type application through the Citrix Environment and i have added an electronic signature feature which I wrote using an WPF Inkcanvas. This part of our application works well when using the pen mouse through a desktop version of the receiver, but very poorly when accessing it through a tablet, Ipad or Droid. When you go to try to scribble you signature you either to hold your finger to initiate the left-click hold, this is longer of droid than Ipad. Does anyone have any experience with this? I want it to work just like Square signing feature a just draw by touch.
You have a few options here. The simplest is to tell admins to set the Application Description to the following when publishing the application:
keywords:mobile
On the mobile receivers (iOS and Android) this does a few things, the useful one for you is it puts them into a different input mode where the receiver does less gesture detection and pushes through events more directly.
You can perform more finer grained control of the input mode using the Mobility SDK for Windows Apps. You can probably get away without the added complexity of using the SDK and just use the extra keywords in the publishing step. But if you're interested there are multiple language bindings for the SDK, including .NET. The main SDK link is here:
http://www.citrix.com/mobilitysdk/
The specific class you use to set the input mode with the .NET binding is here (see BeginSetTouchInputMode):
http://www.citrix.com/mobilitysdk/docs/cmp.net/index.html
Finally the last option is to get your customers using the latest XenDesktop 7 using Windows Server 2012. This is the latest release and it supports touch remoting, so the receiver will not perform any gesture translation that delays user input. Instead it will pass all the touch events directly up to the server for processing. The iOS receiver has implemented touch remoting, however I'm not sure if it's been added to the Android receiver yet.
So the tl;dr is use "keywords:mobile", and then when your customers eventually upgrade to XenDesktop 7 this should become a non-issue.
We’re building a mobile solution on windows 8 i.e. Windows Store App, enabling real time collaboration features for maintenance personnel to connect with Customer Support team. We are leveraging Lync 2010 client SDK to support the collaboration needs. The following are the key functionality we plan to enable with in the app
Text Conversations
Audio Conversations
Video Conversations
File Sharing (Send/Receive)
Remote Desktop Sharing
White board sharing
The following is the approach we’ve taken to integrate Lync with Windows Store app:
Lync will be running in UI Suppression Mode & app will communicate with Lync client through SDK APIs, since the functionality is needed within the application.
Lync Assemblies are wrapped in WCF service, since Lync SDK is not available for Windows Store apps.
We are currently able to enable Text & Audio Conversations through SDK in UI Suppression mode
We right now are in need of an approach to enable File sharing between the app & Lync standard Client.
The option available for file transfers is through contextual conversations which requires GUID exchange as per the below references.
http://code.msdn.microsoft.com/office/Lync-2010-Transferring-f766e7aa
We want to know if this scenario works between Windows Store App & standard Lync Client, if not request to advise the right approach.
Along with File transfers, we'd also need the approach to enable video conversations, remote desktop/white board sharing with the current approach (Lync -> WCF Service -> Windows Store app) as from SDK it is not clear how we get stream data which can be forwarded to Windows Store app.
Just found out that Desktop/Whiteboard/Resource sharing is not possible in UI Suppression mode, (reference below)
http://social.msdn.microsoft.com/Forums/en-US/communicatorsdk/thread/1a7355fe-5c64-4b11-ba25-ce18d6bdd3dd
The following behavior will be the concern from user experience point of view in case of Automation APIs, especially for Windows Store App, considering their full screen behavior
On starting a conversation, corresponding conversation window flashes and takes the user to desktop, user will have to manually go to the windows store app, post this event. The conversation window can be docked in case of desktop apps, i.e. WinForms/WPF using DockWindow(),is there a way for Windows Store app?
Incoming call notifications are bubbled which disturbs the user experience with the Windows Store App
User has to accept the file transfers to receive, in the conversation window, manually
Please advise if there is a best solution to avoid the above behavior if Automation API is the only option to go with for Windows Store App.
New to iPhone development. Working on first app. I'm accessing google maps via UIWebView to forward geocode an address using "http://maps.google.com/maps?q=my address". It works, although it has this quirk of requiring you to hit "Back" button and then the "Detail" button (provided by the navigation bar) to get back to the screen from whence you started. If anyone knows why it does this, I'd love to hear. My real question, however, is this a legal use of google maps? Since I intend this app for commercial use, am I violating Google's rules + regs? If it is illegal, what's my alternative? Thanks.
Using Google Maps in a UIWebView is permitted by Google's Terms of Service.
In iOS 6 Apple switched the maps backend from Google to its own, and even though it is technically possible to use Google's map tiles in MKMapView, that is not permitted by Google's ToS.
Here's the clarification directly from #GoogleMapsAPI on Oct 3 '12:
Q: There are some iOS apps using GMaps tiles, so I want to know they are legal or not legal with licence violation.
A: Direct tile access is not permitted. Using JavaScript API in a web view is permitted.
I'm not an iPhone developer and the last thing i know is objective-c, but have you considered using the Google Maps API?
http://code.google.com/apis/maps/faq.html#mapsformobile
It says
The Google Maps JavaScript API v3 has been developed to cater to mobile devices, and is suitable for browser applications targetted at both the desktop and devices that include a web browser with a full JavaScript implementation, such as the Apple iPhone.
For browser based applications targetted at devices not suitable for using the JavaScript API, the Static Maps API delivers map images in GIF, JPG, and PNG formats, including markers and polylines. Note that it is not permitted to use the Static Maps API outside of browser based applications.
I'd surely try it, at least the Static Maps API cos it's extremely easy to use, and the overall agreement allows commercial use.
You might be better off using the Bing API, it's designed to be used client and server side. So you should be able to make a web service request without using UIWebView.
Rich