I would like to use the newest version 1.1 of AdaptiveCards in the BotBulder Node.js SDK 4 to use the new features such as vertical alignment. However, the CardFactory.adaptiveCard only allows version 1.0.
Is it possible to use the AdaptiveCards SDK itself to render AdaptiveCards for use in chat? I am using AdaptiveCards in Telegram, hence they need to be rendered into an image. I tried using the AdaptiveCards method .render but failed due to the issue described here.
If not, is this planned for the future?
The BotFramework SDK does not currently support the most recent release of AdaptiveCards - v1.1; however, someone has just submitted a feature request to the development team on GitHub to incorporate the updated version into the SDK. Hopefully, the newest release will be developed into the framework and will work with the CardFactory soon.
In the meantime, the user who submitted the feature request also suggested a possible workaround. They recommend creating a DOM object which will allow you to render the JSON card into HTML using the AdaptiveCards Library. Then, you can use Puppeteer - a high-level API to control Chrome - to render the HTML and convert it into an image. The image can then be sent to the user in the chat in place of a card. Unfortunately, you do lose a lot of the card's functionality such as actions, but you will be able to use some of the new formatting features in the new release of AdaptiveCards. I would recommend looking at this post and the Puppeteer Repository if you think this solution may work for you.
Related
We want to use extension replace with plugin, but we need use extension to download files and launch the file such as exe file.
Is there a method to do?
As pages said, Firefox extension will compate with Chrome's extension, we found Firefox support most APIs, but do not support runtime.connectNative() and some native APIs.
Does Firefox support them? If support, when will support? And how to support Native's extension?
The native messaging API is not yet implemented in Firefox WebExtensions, but it's on the future roadmap.
In the meantime, you can use the older SDK API system/child_process to communicate with external binaries over a pipe interface.
Also, if you want to contribute an implementation of native messaging to Firefox WebExtensions, I will happily introduce you to people who can help with mentoring and code review.
The Firefox WebExtension API will support connectNative() from version 50 on. The documentation is already available. You can try out the API using Firefox Developer Edition 50.
We want to transfer data from a client to a server in realtime, so we have decided to go with WebSockets.
Using Xamarin.Forms it was surprisingly difficult to find a suitable WebSocket library.
The best match was "WebSocket4Net" because it is directly suggested on Xamarin's Homepage. However I was not able to install this library, because it only supports versions of .NET up to v4.0. (We are using v4.5)
Whenever I try to change the target framework of my PCLs from v4.5 to v4.0 I get loads of weird errors stating "Windows.Input library could not be found", "ObservableCollection could not be found" etc.
So we are currently using the library "WebSocket.Portable.Core", which although lacking some functionality worked out. However for some reason we can only receive one message. The event "MessageReceived" always is just called once.
Has anyone heard about such a problem with WebSockets? Maybe it is just time to use another library, but I just can't find one?
I also can't find any solution how to implement WebSockets natively for each platform.
WebSockets.PCL has a native implementation for each platform and it's well documented
https://github.com/NVentimiglia/WebSockets.Pcl
Xamarin
Write the model in C#
Write the views for each OS in their own native way
Xamarin promises that the new functionality in libraries is added the same day
Telerik Native script
Write in javascript and call native script's api that then calls the separate OS javascript apis?
Write the view in html5 and css which is re-usable for all OSs as they now all support html5 and css front ends?
Telerik simply states... and I paraphrase 'it does not have this problem'
If the above is so, how is Telerik any better than Xamarin as it states on its website:
"When using NativeScript the new additions to the native platform are
available immediately. This is not the case in neither Xamarin or
Appcelerator, where there are technical limitations and wrappers needs
to be created when new native platform features are added."
I am confused at how Telerik is being penned as being better than Xamarin when Xamarin comes with strong type language without using TypeScript's slightly loose thing going on. And also that Xamarin does in fact sit in exactly the same boat as Xamarin apart form the view part... which is actually supposed to be a benefit?
Question:
- What's the difference between them apart from the two I have denoted?
- Why would Telerik claim such a thing?
[Disclaimer: I work for Telerik.]
Telerik NativeScript and Xamarin are solving similar problems in different ways. Both frameworks are focused on enabling developers to create cross-platform mobile applications with native UI and shared, common code across all platforms.
For NativeScript, we're focused heavily on the web developer skill set. We want anyone that is comfortable today writing HTML/CSS/JavaScript to feel instantly at home creating native apps using NativeScript.
The only thing that is a little different is that views are defined in an XML-based markup. This markup is parsed by NativeScript and rendered as native UI on all target platforms. (NativeScript modules encapsulate the platform-specific renderings.)
The capability you highlight is also something unique to NativeScript's approach for exposing underlying native platform APIs. NativeScript effectively uses (build-time) reflection to make ANY native API available to the JavaScript proxy. That includes 3rd party native libraries. You do not depend on Telerik (or the open source community) to update NativeScript to take advantage of these new APIs. You simply execute a command and auto-discover the new APIs.
Of course, we don't expect a lot of people to write against the raw native APIs using JavaScript, so that's where modules again help encapsulate the different native APIs and expose a single, clean, cross-platform JavaScript API. Anyone can create NativeScript modules.
There's a great post that explains how all of this works in much more detail on the Telerik Developer Network (TDN):
http://developer.telerik.com/featured/nativescript-works/
NativeScript's public beta will be available this week, and v1 will ship in May.
UPDATE [Feb 2016]
Since this was originally posted, NativeScript has shipped and is now in v1.6. It is also now integrating heavily with Angular 2. You can track the project progress on GitHub: https://github.com/NativeScript/NativeScript
UPDATE [June 2016]
There are now performance metrics comparing NativeScript and Xamarin. Please find them here:
https://github.com/NativeScript/sample-iOS-Profiling/tree/performance-tests
Telerik is a UI component and it has some beautiful control for designing in xamarin forms,MVC. Net and etc, but xamarin forms is a technology that helps deveopers to make mobile application using c#
I'm working with the code from google drive in visual studio 2012 (C#). I managed with hours of fiddling around with nuget reference the necessary libraries.
I compiled the test application and got the following warnings:
'Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient' is obsolete: 'NativeApplicationClient is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for WindowsStore apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Authentication.OAuth2.GoogleAuthenticationServer' is obsolete: 'GoogleAuthenticationServer is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for Windows Store apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Drive.v2.DriveService.Scopes' is obsolete: 'Use DriveService.Scope instead. This enum is going to be removed in version 1.7.0-beta.'
I did not modify the code other than adding in the client_ID and client_secret. Other than that, it appears to run...
I'll also mention that I am using the nuget Google.Apis.Auth package.
The code behind the DriveService.Scopes warning is using DriveService.Scopes not Google.Apis.DriveService.Scopes (look at the code on the link; mine is the same).
With the google admin api being deprecated and google breaking the old api almost every other week it seems, I'm anxious to get on the new API. However, with what I'm seeing here I'm wondering if that's a good idea or not. I could be trading the frying pan for the fire. With that said, what are we supposed to be using if your current example is already obsolete?
First of all you should use the latest version of the library, that's the version that we maintain, provide fixes, new features and so on. You can get it using NuGet.
The sample code in the page you mentioned wasn't updated lately. Take a look in our samples repository (and specifically in the Drive API sample).
Google.Apis.Auth is the right package to use. The reason the old package (Google.Apis.Authentication) is obsolete is based on the fact the we wanted to support different Windows platforms like WP, Windows 8 applications, ASP.NET MVC. We also simplified the OAuth2 "dance" which was so complicated before.
Last thing - If we make any incompatible changes in the library we document them in our announcement blog, so our users will be able to make the right adjustments . I recommend you subscribing to this blog to get updates about our library.
Hope everything is clear now :)
I am developing (yet another) password manager add-on for Firefox. My add-on needs to:
Add two context menu items to each password field.
Open a dialog box or floating panel when the menu item is selected.
Access a specific method of a specific XPCOM component.
Fill the password field.
Include a preferences window.
Be compatible with Firefox 4.0.
Preferably, also:
Run on Firefox 3.5 and 3.6.
Some users don't update to the latest version.
Firefox 4.0 won't run on a PowerPC Mac.
Install without a restart on Firefox 4.0.
Allow for localization.
I have tried the Add-on SDK (formerly known as Jetpack), and it makes it very easy to start developing. However, I find that HTML cannot easily create "native looking" dialog boxes and that the SDK is rather heavyweight. (It takes many kilobytes to build a simple extension; that includes an XPCOM component!)
What are the advantages and disadvantages of using the Add-on SDK to develop my Firefox extension? Is it ready for "serious" extension development?
Advantages:
Jetpack API exposes high level APIs for most of the things you mentioned:
Add two context menu items
floating panel
API for password manager
Jetpack based add-ons are restart-less.
Jetpack based add-ons are future proof in a sense that high level APIs will remain unchanged
for the coming versions of FF.
You may be able to use some community developed modules for APIs that are not exposed by SDK.
If this is not the last extension you're planning to build there is a potential for code reuse,
by building third party modules as ones mentioned in 4 (see docs for details)
Support for mobile FF is coming in post 1.0 version of Addon-SDK which may mean that your
extension can be made compatible with mobile version of FF with minimal to zero effort.
Jetpack comes with build-in unit testing framework.
Has a better security model, which will ease add-on review process.
Jetpack support commonjs modules / packages that which means that some of the code can be borrowed
from other projects like nodejs for example.
Disadvantages:
Jetpack no longer supports FF<4.
Does not yet have support for localization.
Has no API for building preference panels, but can be developed as third party module and shared
with rest of the community.
Add-on will contain code with layers of abstractions, that will increase size of add-on (there is
ongoing work that will reduce xpi size by excluding files that are not used by add-on).