BLOG
|
We’re excited to announce a major change in how we version and release the ArcGIS Maps SDK for JavaScript; we’re moving to semantic versioning (SemVer)! This change will make it easier for developers to upgrade between versions, understand release impacts, plan upgrades, and integrate with modern tooling. Learn more by reading this blog and feel free to share any thoughts or questions you have under this post. https://www.esri.com/arcgis-blog/products/js-api-arcgis/announcements/arcgis-maps-sdk-for-javascript-is-moving-to-semantic-versioning
... View more
6 hours ago
|
1
|
0
|
97
|
BLOG
|
The goal of this blog is to provide information and guidance for customers using web applications that are causing browser tab refreshing on iOS devices. This can be any web app, including ArcGIS configurable apps and builders, custom apps built with the ArcGIS Maps SDK for JavaScript, or any other memory or processing intensive app. The foundational differences between mobile and desktop environments - especially in terms of hardware and memory management - are significant. A mapping app that runs flawlessly on a desktop may not perform well on a mobile device. When it comes to building web mapping applications, developers often encounter unique obstacles when targeting Safari and all other browsers on iOS. iOS devices often have stricter memory and CPU usage limits compared to their Android counterparts, making web mapping applications more susceptible to browser tab refreshes. Adding to the challenge, iOS 18.4 has introduced a regression leaking image bitmaps that will accelerate the occurrence of browser tab refreshes in certain scenarios. In particular, maps that include a layer using image tiles (raster basemaps, tiled imagery layers) or full-screen images (map image layers) will see the issue more often. We have created a workaround for the iOS issue in the ArcGIS Maps SDK for JavaScript which will be included with version 4.34 and will drastically reduce the refreshing behavior.. This guide will explore these considerations, offer advice for better understanding issues you may be experiencing when running your app on a mobile device, and provide resources for tuning your app for performance. Web mapping in iOS While today’s web mapping technology provides rich, dynamic visualizations and interaction with anything from small to very large datasets, they are also inherently memory and processing intensive. On iOS, memory constraints are more tightly managed by the system to prevent a single tab from affecting the entire device. These limits are process-based, meaning a webpage runs in a dedicated process with a memory ceiling. When a browser tab exceeds the set limit, the system will immediately free up memory by reloading the tab and effectively resetting your application to its default state. Tuning your ArcGIS map and app for performance When creating web apps, the goal is to create performant web applications, but this shouldn't come at the cost of other user needs. The key is to balance user expectations with the highest possible performance. The ArcGIS Maps SDK for JavaScript is already optimized for efficient data fetching and visualization, so you should test your application on different devices before beginning any manual optimization. To benefit from constant improvements in CPU and memory usage, always use the most current SDK release. If you still encounter performance issues, consider reducing the amount and complexity of data that your app must display. For example, you can reduce the number of layers in your map and use techniques like client-side aggregation (clustering or binning) to reduce the number of features the map needs to draw. There are several available resources that cover performance optimization techniques for maps and apps, such as: Blog: Performance Tips for ArcGIS API for JavaScript Optimize performance in ArcGIS Best practices for creating scalable web maps General Best Practices To ensure your web mapping app performs well on iOS, consider these recommendations: Reduce Memory Impact: The most common cause of crashes is excessive memory usage. To mitigate this, encourage users to close other tabs, close non-essential applications, and restart their device to reset the device’s memory state. Learn Mobile Debugging: Familiarize yourself with mobile debugging techniques. Apple's Web Inspector, available in Safari on macOS, can be used to debug a connected iOS device. This allows you to inspect the DOM, view network requests, and analyze CPU and memory usage. If you are having challenges with the Safari inspector crashing while connected to your mobile device, you can also do some level of debugging using the desktop Chrome DevTools on MacOS. Isolate Bugs: When troubleshooting, try to isolate the issue as much as possible. While it can be challenging with complex, custom applications, narrowing down the problem helps the development team and others assist more effectively. Check Device and OS Support: Always verify that the mobile device is still supported and is running the latest operating system. Older OS versions generally have lower memory limits and may not support the latest optimizations. Consider Native/Hybrid Apps: For some applications, a native or hybrid app, such as Capacitor.js, might be a better choice. This approach offers developers a more direct relationship with the operating system, including the ability to detect low memory or high CPU usage and react proactively within the app to prevent crashes. To build a native mapping app, you can use the ArcGIS Native Maps SDKs, and with SDKs like Flutter, creating native apps has never been easier. Debug with a Mobile-First Mindset: You can't treat mobile devices the same as laptops. Differences in hardware, operating systems, battery life, and network speeds mean that an app that runs well on desktop may not run well on mobile. Remember, you have very limited control over other apps running in the background, which can consume valuable CPU and memory resources and contribute to crashes. Understand Crash Categories: Crashes typically fall into three categories: bugs, memory usage, and CPU usage. While bugs can be in the application or API code, they can also be in the browser or the OS. It's crucial to remember that mobile devices have much more limited resources than laptops, making efficient use of memory and CPU paramount. Communicate Expectations: Help end users understand that mobile devices are not the same as laptops. Due to differences in hardware, operating systems, and network speeds, an app that runs well on a desktop may not perform the same on a phone. Ultimately, understanding the unique constraints and behaviors of iOS is key to building a robust and performant mobile web mapping application.
... View more
yesterday
|
2
|
0
|
141
|
POST
|
Ahh, ok. Sorry about that. yes no This one is a bit more complicated, see below The Widget class is going away with widgets. With regards to view models, it is a bit more complicated. First off, we know how important it is that developers can continue to create tailored experiences with the SDK. Going forward, you will be able to build the same custom experiences using the underlying business logic, but the implementation will change. As we move to the component-based architecture, view models are being considered for 3 possible buckets: 1) The View Model will be kept in the core API, but reworked/moved: The functionality will simply move to another location (since they are currently located in the widgets/ folder). 2) The View Model will be dissolved into the core API: The functionality will be available in core, but through other APIs. For example, AreaMeasurement2DViewModel logic could move to an analysis API similar to what 3D has for AreaMeasurementAnalysis. 3) The View Model's logic belongs to the component: The logic will be exclusively used by the component and the view model will be deprecated and later removed. View models fall into this category when we believe that they don't provide additional value to developers. For example, in the case of the WeatherViewModel, different APIs already exist to set Weather directly on SceneView so the view model isn't really necessary. Categorization of view models into the three buckets above depend on the explanation above, but also based on what we are learning from customers. We really want to understand which view models are being used, and for what purpose so that we can make sure we account for the wide variety of scenarios and customer requirements. We are encouraging customers to fill out this survey to help inform this roadmap: https://arcg.is/005zS9 One other aspect that I would like to share is that sometimes view models are used to make a slight adjustment to the UI (like hide part of it, or add a button to do something). Part of our roadmap is to implement slots which are placeholders within the component UI for you to embed your own functionality/workflows. Components also have configuration and styling options through css properties. So in some cases, developers can write and maintain less custom code because they are able to use the out of box components (as opposed to creating their own UI on top of the view models), and still tailor the experience to meet their requirements. So, the more specific information you can share in the survey, the better we can design the component options for your needs. I am working on a blog that covers this topic. I will post a link here when it is published.
... View more
07-28-2025
08:58 PM
|
4
|
3
|
520
|
POST
|
Hello @Aeseir! We are making a full transition to W3C standards-based web components. Widgets will eventually be removed from the SDK. We are currently working towards the following tentative schedule: All widgets deprecated by Q1 2026 Widgets removed Q1 2027 You can find more information about our transition plan in this blog: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/javascript-maps-sdk-a-full-transition-to-components
... View more
07-28-2025
12:46 PM
|
1
|
5
|
545
|
IDEA
|
Hi @jacobgqc thanks for sharing this idea. We do have a data weighted heatmap which multiplies each pixel's density by the attribute value, but I am guessing that it isn't what you are looking for. Can you share a visual of what you want to achieve?
... View more
07-23-2025
08:38 AM
|
0
|
0
|
326
|
IDEA
|
Hello everyone, good news... We are adding support for labeling multipoint features in version 4.33 which is going out later this month! That capability will of course be available in Experience Builder as well.
... View more
06-16-2025
02:26 PM
|
0
|
0
|
367
|
IDEA
|
Hi @KennyLohr1 , you can still use the basemap IDs to access US worldview basemaps, but the caveat is they must be the "arcgis/outdoor" style basemaps which use the basemap styles service (which is a standard basemap and requires ArcGIS authentication or an api key). // creates an arcgis streets basemap with us worldview
const basemap = new Basemap({
style: {
id: "arcgis/streets",
worldview: "unitedStatesOfAmerica"
}
}); As you mentioned, you can also point to the US basemap style directly to use the enhanced basemaps. I just published a blog this morning covering a variety of scenarios for updating basemaps to use the US worldview, perhaps this will help as well. https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/how-to-use-a-basemap-with-a-specific-world-view-in-your-web-app/
... View more
03-06-2025
07:26 AM
|
0
|
0
|
599
|
POST
|
@AndreV that is a great question. While the presentation of UI elements are being transitioned from widgets to components, the underlying business logic that is available (today via view models) will continue to be available. That means that you will be able to build custom experiences and workflows using the SDK’s business logic going forward. However, as we work to modernize and continuously improve the SDK, it is important for us to know how you are using the business logic to help inform our longer-term roadmap. When you have the chance, please fill out this survey so that we can use your input to inform the SDK’s roadmap. We want to continue to offer an SDK that provides maximum productivity when building your apps and at the same time offers the flexibility you need to build your organization’s specific requirements. I just published a blog that covers our transition to components, as well as the roadmap for widgets that I think will be very helpful in understanding our strategy: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/javascript-maps-sdk-a-full-transition-to-components/
... View more
02-26-2025
11:02 AM
|
2
|
1
|
423
|
POST
|
Hello @baohuachu2 ! Calcite is Esri's design system that ArcGIS web-based experiences use (except for Experience Builder). We continue to invest heavily in it as build new components, enhance existing ones, add guide topics, and do overall improvements across the design system (for example, we recently worked on better responsive design and design tokens, etc). The jimu application framework is specific to Experience Builder. It is not based on Calcite because of the development timeframes (Calcite components weren't available when ExB was being built/released). Many customers have requested that Esri creates a Calcite-based theme within ExB, which would blend well with components coming from the JavaScript Maps SDK (also based on Calcite) and any custom ExB widgets that are built with calcite components. This is planned, but we don't have a release date at this time (to my knowledge - perhaps @Jianxia has a more up to date answer on that). That said, even though we don't have a Calcite theme in ExB yet, you can use Calcite to build custom widgets today. You can find doc on that here --> https://developers.arcgis.com/experience-builder/sample-code/widgets/use-calcite-components/ I hope that helps!
... View more
08-28-2024
12:58 PM
|
1
|
1
|
1280
|
IDEA
|
@RobertScheitlin__GISP, I played around with the above sample to use Calcite & have a cleaner UI: https://codepen.io/Julie-Powell/pen/qBzNgja It is also based on map components 🙂 Julie
... View more
08-15-2024
09:21 AM
|
0
|
0
|
559
|
BLOG
|
We have moved the ArcGIS Maps SDK for JavaScript v4.30 release date to June 12th due to dependencies on the Wednesday releases of ArcGIS Online and Developers. Please keep an eye out for the release blog on June 13th, which will include an overview of key capabilities & enhancements in the release.
... View more
05-07-2024
01:21 PM
|
7
|
3
|
937
|
POST
|
Hi @PRAVEENPATNANA we don't have a native SDK for JavaScript (the JavaScript SDK is for web apps). I will let @MarkBaird help you from the native side of the house. Julie
... View more
12-14-2023
09:41 PM
|
0
|
1
|
2781
|
POST
|
Oh, I might have read your question wrong - you want to display to POSSIBLE routes between the same two points. The network service doesn't support returning multiple alternate routes in a single request. You could pass in a barrier preventing traveling on certain roads which would cause it to take an alternate route, but there is no way to do this automatically.
... View more
12-14-2023
12:36 PM
|
0
|
1
|
985
|
POST
|
@PRAVEENPATNANA to display routes in the JS Maps SDK, I recommend using RouteLayers which allow you to display multiple routes on the map. Here is a blog that outlines how these work: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/introducing-the-new-routelayer/ To see the part that specifically covers displaying multiple routes, go to "Route Visualization."
... View more
12-14-2023
09:25 AM
|
0
|
2
|
997
|
POST
|
Hello @PRAVEENPATNANA, We don't support offline use of ArcGIS Maps SDK for JavaScript. I agree with @MarkBaird, you are better off using one of the Native SDKs instead. Using a native SDK you can calculate routes offline, etc. Julie
... View more
12-14-2023
09:19 AM
|
0
|
3
|
2812
|
Title | Kudos | Posted |
---|---|---|
1 | 6 hours ago | |
2 | yesterday | |
1 | 07-28-2025 12:46 PM | |
4 | 07-28-2025 08:58 PM | |
2 | 02-26-2025 11:02 AM |
Online Status |
Online
|
Date Last Visited |
2 hours ago
|