Latest Contributions by Nicholas-Furness

FYI, there is also this post from a while back which might be of interest. It doesn't quite tackle your specific use case and focuses on Mobile Map Packages from Pro, but it does talk a bit about what's going on within them which could be helpful. ... View more

To open local raster files in the SDK, you'll generally need a couple of support files. A world file to describe the image-to-world transformation, and an aux file to specify a spatial reference, so that the SDK knows how to handle that georeferenced image file. See this gist for an example. The links at the bottom talk about the world and aux files, as well as what to name them. I've found that just using the aux file from the gist wholesale (with an appropriate name) and writing out an appropriate world file based off the instructions in the links, and placing them alongside the image file on device storage works well. This will require a Standard license or above, but if you're using Local Server, you're already there (and of course while you're developing, without applying any license, you can also test this out). You should also be able to use Local Server for serving up rasters, but if you can get the aux and world files working that might be a simpler approach. ... View more

Hello Frank. Thanks for reaching out. Firstly, you will benefit tremendously by using the ArcGIS Maps SDK for Swift over direct REST requests (unless you're just making very simple calls to the ArcGIS Location Platform places or geocoding service). We have numerous tutorials at the SDK's homepage: https://developers.arcgis.com/swift/ I suggest you start with this one, which will introduce you to some concepts around API Keys and the SDK in general: https://developers.arcgis.com/swift/maps-2d/tutorials/display-a-map/ But I also suggest you go through the getting started pages at the SDK homepage. You can also see these blog posts that we wrote around getting started with the SDK, although they will probably be slightly out of date as we just made some major changes to how API Keys are created and managed: https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-1-maps-and-app-structure/ba-p/1289024 https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-2-state-and-data-f... https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-3-swift-concurrenc... https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-4-view-modifier-an... The new ArcGIS Maps SDK for Swift is the modern continuation of the old ArcGIS Runtime SDK for iOS. Learn more here where we first announced the modernization of our SDKs back in April 2022, and here, where we cover the initial release of the new SDKs later that year. With that in mind, we do indeed discourage use of the old Objective-C ArcGIS Runtime SDK for iOS (which provided UIKit UX components), and although it is a long-term support release, it will eventually cease to receive support. Apple's stated path forward is Swift and Swift UI, and this is what we've committed to with the ArcGIS Maps SDK for Swift. However, Apple provide an easy way to use the Swift UI components with UIKit using a UIHostingController (see Apple's doc here and here), and we have customers who are successfully doing this. As for authentication, you can learn all about using our API Keys and OAuth here: https://developers.arcgis.com/swift/security-and-authentication/ Which one you will use will depend on the type of app you're building and who will be using it. As a general guide, many Esri end users are direct users of the ArcGIS system and have their own logins which enable access to content and services. These customers may well need to use OAuth authentication. But if you are building apps that are to be used by end-users without an ArcGIS login, an API Key is more appropriate. I recommend you create yourself a free ArcGIS Location Platform account which will allow you to create and use API Keys of your own. There are generous free monthly allowances allowing for development and testing, and which can also be used in production. If your customer has given you an API Key, you can certainly use that and it ensures that any usage beyond the free allowance will be billed to them (or just fail if they haven't set up payment methods), but there are a couple of disadvantages to that that I can think of. Firstly, API Keys are scoped, and if you need to provide access to additional services, the customer who hired you will become a bottleneck. Secondly, you won't have insight into usage levels for the API Keys, nor the ability to create additional ones. However, if the API Key is just going to be used for simple stuff like accessing basemaps and performing geocodes or place searches, you might be able to get away with it. More likely though, using your own account during development and testing will work well, and then the customer can provide an API Key for production. I hope that helps. ... View more

Hello. Before I answer your question, I want to make sure we're talking about the right thing… Firstly, named user vs license strings: As you mention, license strings for paid license levels (Basic, Standard, and Advanced) are purchased in packs. But the Lite level license string is free and can be used as much as you like. If the capabilities of your app are all included in the Lite license, that one Lite license string is all you'll need. See here for which capabilities are available at each level. And see here to get your Lite license string. Next, you say "The Named User license with standard privileges, such as VTPK load, seems like a suitable option.". I want to make sure we're talking the same thing here. "Standard" is a license level that, in brief, allows you to open non-Esri-proprietary local data files, like GeoPackages, Shapefiles, ENC, local rasters, etc. (see this link again for full details of what you get at Standard). However, a VTPK is an Esri-proprietary file (like MMPKs, TPKs, TPKXs, etc.) and so can be opened locally at the Lite level. If that's what you need, Standard might be overkill and Lite might suffice. Now, to the question of renewing licenses. License strings can be used in perpetuity. There is no need to "refresh" the license (they are designed to encompass scenarios where a network may never be available). This is true for the free Lite license string, as well as the string(s) you get when you purchase any Basic, Standard, or Advanced deployment pack(s). Named User licenses can be taken offline for 30 days, as you noted. The pattern is this (as described here) : While online, your user signs in. Your code then requests the license from the portal they signed in to. You apply the license in your app, and optionally serialize it to local storage for later use. Whenever your app is subsequently started (probably while offline), you can de-serialize that license and apply it. No network is required. Of course, if you have a network, your user could sign in again (returning to steps 1 and 2). How does the SDK ensure the license reaches its expiry? The encoded license data downloaded in step 2 includes the expiry date, and the SDK compares that to the current date. Whenever you repeat steps 1 and 2, that new license data will effectively have a new 30 day countdown start date encoded in it. I hope that helps. ... View more

Hello. Thanks for the question. This is expected behavior. Loadable is all about metadata, not object state. The Portal's metadata is loaded once from the actual ArcGIS Online or ArcGIS Enterprise portal, and that doesn't change just because you revoke the credentials that provide access to it. There's some great info here about how the Loadable pattern works, and you can see that once a Loadable object reaches loaded state, it'll stay there. Calling load() on a loaded object is essentially a no-op. When you first call load() on the portal, it needs to load metadata about that portal as mentioned above, and since most (all?) of that metadata requires authentication to read, you see the authentication prompt and caching of credentials. I would create a new indentical Portal object and load that. Hope that helps! ... View more

Thanks for that additional info. Yeah. Something is causing the SDK to wait for a while when removing a vector tile layer. iOS doesn't tolerate that happening on the main thread (which makes the app unresponsive), and so is terminating the app. A couple of questions: Which version of the SDK are you on? Are you able to reproduce this yourself? If so, can you share a simple reproducer? ... View more

At first glance it looks like the user is setting a map on the MapView when the MapView already has a map on it (i.e. replace the MapView's map). As part of tearing down the old map, it seems that we're disconnecting from a vector tile service and waiting for it to disconnect in some way. That shouldn't be happening on the main thread (I'm sure we should never call thread.sleep (see frame 3) on the main thread). Presumably setting the map is done as the result of a user action (e.g. tapping a button), but to help dig in: are there more frames after frame 14 in the crash (frames 15 and higher)? ... View more

@NIANXI39If this is still happening, please contact customer service. You should be able to copy and paste your Lite license key from that bit of the web page that you took a screenshot of. ... View more

Not sure why, but remove the default key has resolved the issue If you set a default API Key, it will be used for all requests so even if you configure OAuth, the OAuth/Authentication Manager workflows won't be kicked off. By no longer setting it, the SDK will interrogate services and any auth config you've set up and use that info to manage authentication. If you need API Keys for specific services, you can still set them directly on those SDK objects (just not globally) and use a mix of API Key and OAuth authentication. ... View more

Hello, HTTP caching, while useful for reducing duplicate requests for the same data as you pan and zoom around the map, and for improving performance for the end user, is not designed to take a map offline. It's not that we prevent that from working, but there is a lot of metadata beyond just the raw map content that needs to be cached and returned by the underlying HTTP stack, and you're at the mercy of how the caching works on a particular platform (with the Kotlin SDK, it's OkHttp). Being able to do this is something that's on our radar, but it's a way off yet. The recommended and supported process for taking maps offline is to proactively download them using the OfflineMapTask API. This is a much more deliberate process; web map and data service configuration is required to enable this behavior, and the application needs to expressly make use of APIs to download the map. You can learn more here. Hope this helps! ... View more

We've released the first public beta of the ArcGIS Maps SDK for Flutter. You can read about it here, and join the beta here. Thanks for all your interest to this point. Please join the beta, give it a whirl, and give us your feedback in the beta forums to help us deliver the best mapping and location SDK for Flutter there is. ... View more

This article should help. It will be on your portal item settings for the vector tile layer: https://doc.arcgis.com/en/arcgis-online/manage-data/manage-hosted-tile-layers.htm#ESRI_SECTION1_0561B66EE826482297DDE002A94048B0 ... View more