Latest Contributions by JuliePowell

Support for CORS will be enhanced in 4.9 and will potentially require changes to your code. Read further for the full scoop on this. The ArcGIS API for JavaScript has long supported CORS. CORS allows web applications to bypass a browser's same origin policy and access resources or services on other servers/domains. When the web server supports CORS, a proxy is not required to do cross-domain requests. Supporting CORS as opposed to using a proxy is helpful as it can: Provide a performance boost since the web application no longer has to send a CORS detection request back to its server, wait for the server to access the desired resource, and interpret the result before sending it back to the client. Simplify development as it is no longer necessary to maintain a proxy on your server. Avoiding the use of a proxy also ensures that web tier authentication (i.e. Active Directory) can be used when accessing secured resources. CORS and WebGL There are multiple scenarios when either CORS or a proxy is needed due to cross-domain requests for a resource. CORS is more important now than ever before when using the ArcGIS API for JavaScript due to the API’s use of WebGL. Thanks to WebGL, the API can render hundreds of thousands of features with fast performance using the GPU. However, WebGL has different requirements than the traditional method of rendering using SVG. When loading images (such as an image used by PictureMarkerSymbol), SVG simply adds an image in the DOM, while drawing on the WebGL canvas requires access to the raw image data. Since the raw image data is required for rendering, the image must meet one of the following requirements: (1) be on the same domain as the app, (2) be hosted on a server that supports CORS, or (3) a proxy must be used. With WebGL becoming the primary way in which the API renders graphics and its requirement to access raw image data, we’ve optimized the way in which we approach CORS. Changes to how the API will handle CORS, starting at 4.9 The API will assume web servers support CORS. Here are the details behind how the API handled CORS until 4.8, and how it will change starting at 4.9. Previously, the API would handle CORS in the following way: Developers could predefine a list of corsEnabledServers to explicitly indicate whether CORS was setup for a given server. If the service was published with ArcGIS Server, the API would automatically send a request to see if CORS was supported (note: this resulted in an extra request to the server before a resource could be requested). If the server didn’t support CORS, a proxy rule could be configured (note: this resulted in the extra hop and performance hit described above). JSONP was used as a workaround when the server wasn't known to support CORS and the request was a GET request for JSON. An example would be using a FeatureLayer from an ArcGIS Server version 10.0 or earlier. If none of the above criteria could be met (not listed in corsEnabledServers, not an ArcGIS Server service, and no proxy setup), the API didn’t make the request to the resource and generated a console error. Starting at 4.9, the API will handle CORS in the following way: If you have configured a proxy rule in your code, the API will continue to use your proxy. Otherwise, requests will always be made with the assumption that CORS is supported. Assuming CORS support is particularly useful when you don’t know what web servers you might be accessing in advance, for example in some scenarios when loading a web map with a mash-up of services. The first request will be sent assuming CORS is supported, and if the request fails due to the lack of support the API will automatically fallback to the configured proxy (via the proxyUrl property in esri/config.request). This change also results in a performance gain when working with ArcGIS Server because it is no longer necessary to send a CORS detection request before accessing a resource (in the case when the server isn’t listed in corsEnabledServers). What do you need to do? If it doesn’t already, configure your web server to support CORS (if possible). Another change at 4.9 is support for JSONP is being removed, which will simplify webpack builds. If your server doesn’t support CORS, setup your proxy so that the app would fallback to using the proxy when the CORS request failed. If you have a specific requirement for using JSONP, you can use the dojo request script module as a workaround. If you previously used any of these APIs, they should be removed as they are no longer needed. Your CORS enabled server should “just work” since the API will make the request assuming CORS support. esri/config.request corsDetection corsDetectionTimeout corsEnabledServers* forceProxy useCors   esri/request allowImageDataAccess option * If your app is using corsEnabledServers with objects that have withCredentials: true, you should push the domain to esri/config.request.trustedServers instead. This guide topic will be updated with the latest information about working with CORS after the 4.9 release. ... View more

We recently published a series of blogs (with one more to go) aimed at helping JavaScript developers wanting to migrate from Google to ArcGIS come up to speed on the JS API: Getting Started: Displaying a marker with a popup Getting directions and displaying a route Search and Geocoding Adding a shape  Have you gone through the experience of migrating from Google or are you considering starting the process? This GeoNet post serves as a way in which you can provide feedback on the above blogs, as well as share your experience coming up to speed on ArcGIS. How can we help? ... View more

This post provides insight into how we manage version 3.x of the ArcGIS API for JavaScript (JSAPI) release plan and technical support strategy.   The JavaScript development team has made great progress bringing version 4.x of the JSAPI closer to parity with 3.x, meanwhile introducing new tech for building very dynamic, expressive 2D and 3D apps. Over the next year, each release will be a balance between capabilities for reaching full parity with 3.x and brand-new innovation. Many customers’ app requirements are fully met by the current release of the 4.x API (4.7) while others are still dependent on 3.x (either with existing apps that they are maintaining or new apps that have requirements such as full editing support). We also have many Esri apps built on 3.x, such as the 2D version of Web AppBuilder for ArcGIS.   Technical Support Plan Because we have a large customer base that still depends on 3.x, we are very careful about how we manage the Product Life Cycle (PLC). Our strategy is to make all PLC dates relative to our estimation of the last 3.x release. When is the last release? It depends on when we reach full parity in 4.x, enabling us to move critical apps such as ArcGIS Online’s map viewer to 4.x. When we reassess our estimation of the final release date, PLC phase dates are updated accordingly.   Relative dates for each PLC phase are determined in the following manner: - 3.x remains in "General Availability" until the last release of 3.x. - 3.x moves into "Mature Support" after the last release, and lasts for 1 year.  - 3.x is retired 3 years after General Availability ends.  For more information about the above software support phases and what they entail, refer to the PLC.   Recent Update to the PLC Version 3.x was scheduled to move into mature phase next month; July 2018. Based on the current status of the API, this was moved to July 2019, with the mature phase starting August 2019 and retirement in August 2022. As mentioned above, these dates will be revisited depending on progress made towards 3.x parity.   If you need further clarification on the above, please reach out to Technical Support through the normal channels.  ArcGIS API for JavaScript‌ Kwasi Asante‌  ... View more