I am using the Outlook API (https://dev.office.com/reference/add-ins/requirement-sets/word-api-requirement-sets). At the moment it is on 1.6 and I see some changes towards a 1.7 (I think).
What versions of Outlook support the current 1.6 version? (What is the oldest version supporting it). I saw some versioning for Excel and Word, not Outlook though.
And is it clear when the new update will become available?
The requirement set 1.6 APIs are supported starting with build number 16.0.9020.2000. We don't have preset timeline for the requirement set 1.7 APIs, it will be released when all supported platforms implement all the APIs from that set. That work is currently in progress, that's why you may see some APIs from 1.7 in preview.
Related
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 just built a very simple add-on for Firefox, but it's only compatible with FF 8+. I'd like to make a version that's compatible with FF 3.6 and FF 4+. Is there an SDK for those versions I can use to create/compile a version that'll work with those versions?
No, even Add-on SDK 1.0 marked the add-ons as only compatible with Firefox 4.0b7 and higher. The main reason is that Firefox 3.6 didn't support installing add-ons without a restart and developing an add-on that will use the "conventional" approach in Firefox 3.6 and install without a restart in Firefox 4 and higher is pretty complicated. There are other issues with Firefox 3.6 as well. So your options are:
Just ignore Firefox 3.6. This should be the best course of action given that this Firefox branch will become unsupported soon - its already low user count will be significantly reduced again.
Create a classic extension, without using the SDK. This might be non-trivial depending on what your extension does, and you will most likely lose the ability to install without restart (as I said above, keeping it while being compatible with Firefox 3.6 is very non-trivial).
Use a pre-release Add-on SDK version, e.g. Add-on SDK 0.9. The differences to current SDK versions might be insignificant enough for your extension to work but you should expect bugs and issues due to browser changes since this SDK was released (it lists Firefox 4.0b6 as maximal supported version).
As I read more on the use of webdriver/firefox, I am getting the impression that there serious issues regarding different versions - specifically that when a new version of FF comes out, a new version of WD is needed as well...
Am I reading this correctly?
If so, does the same problem exist with other browsers?
This is a worry for me because my clients may have different versions of FF, and because the app they get from me is compiled - which means I would need to send them an updated app every time FF is upgraded...
WebDriver is updated on a consistent basis to stay current with the new browser versions that are coming out. Firefox has a very fast release schedule. For your application to support the very latest Firefox version, then you'll have to keep it updated with the latest WebDriver version that supports that version.
My advice is to tell your users which Firefox versions are supported by your application, and then setup a regular release cycle with them, in which you update WebDriver to work with the latest Firefox versions. Then as new Firefox versions are released, you can update your application and send them the newest version.
Chrome is in a similar position, but for WebDriver, the Chromium team maintains the ChromeDriver, which doesn't always need update for each Chrome version.
Internet Explorer has a very slow release cycle, so you won't need to update the WebDriver assemblies as often for IE.
However, staying on the latest WebDriver version does have advantages, regardless of the browsers you need to support in your application, such as the latest bug fixes.
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).
As a long time time Flex developer I've thought about building my next application - which should run on the iPad as well - with OpenLaszlo. OpenLaszlo offer a Flash and DHTML runtime, but besides the demos on the website I don't see any real world application built with OpenLaszlo:
http://openlaszlo.org/showcase
Has anyone built a large application with the DHTML runtime, and what was your experience doing that.
Thanks!
I've tested our complicated video editing application under HTML5 mode of OpenLaszlo (formerly known as DHTML mode) and everything works aside from the text mis-aligning a bit. Audio and Video playback is not available in the latest official release (4.9.0) but the latest nightly builds ( http://download.openlaszlo.org/nightly/trunk/ ) contain the html5video and html5audio classes which work fine for media types that play in the new HTML5 and tags (different browsers support different ones). My test results of what works can be viewed here:
http://jira.openlaszlo.org/jira/browse/LPP-10058
In regards to iPad, everything seemed to work fine except that it was not possible to programmatically play more than 1 video/audio item at a time without user interaction. However, this seems to be a limitation of iPad and not OpenLaszlo since a test HTML5 application suffered the same limitation.
http://www.pandora.com and http://www.gliffy.com are large applications built on OpenLaszlo Framework.
The DHTML runtime (or the ability to generate an HTML5 application, as we'd probably phrase that feature today) has been added to OpenLaszlo with 4.0 release in March 2007. The first time I saw a version of Laszlo Webtop running using the DHTML runtime was in mid 2009, although Laszlo Calendar wasn't working at that moment. In March 2011 I witnessed a much improved version of Webtop running in DHTML mode, the system looked very stable.
In July 2012 Gliffy announced the Gliffy HTML5 Editor Preview. Gliffy is an online diagram editor, which has been around for a number of years - but in the past it was only running as a Flash application. Gliffy is a very complex application with a large code base, and it's a good sign that Gliffy is able to run on the DHTML runtime. I haven't found any information on the Gliffy website to which browsers are supported by the HTML5 preview.
Based on this information I would say that the DHTML runtime is production ready. The only question is if Laszlo or Critical Path (the company which acquired Laszlo) is going to keep funding the project in the future, since the number of developers working on the platform at the moment is very low.
Laszlo has not upgraded the HTML5/DHTML runtime to support the newer version of IE (IE9+), although it seems that the company is working on improving the DHTML support for IE at the moment (as of summer 2012). If you are planning to use the DHTML runtime for only some browser (Chrome, Firefox, Safari), everything should work relatively well.
If you plant to develop an OpenLaszlo application using the DHTML runtime, I'd recommend that you use the Trunk version (upcoming 5.0 release) of OpenLaszlo, since a lot of bugs have been fixed in Trunk for DHTML.Despite the fact that it hasn't been released, a number of developers are using that version already for production purposes.