Latest Contributions by JeffSiemens

Behavior works as advertised. Thanks Mark. ... View more

Thanks Mike! That's exactly what I was looking for! ... View more

Hi Morten, Sorry I should have followed up with you on this earlier. Your original question about whether or not the build server VS versions varied significantly got me thinking that this might indeed be the problem, since our versions did vary significantly. Unfortunately, I've now upgraded the servers, so I can't tell you exactly what they used to be, but it was 2017 on the build server (unknown exact version), and 2019 for development (15.2.x). For the current ios build we're on 8.2.6 (2019), and for Android we're on on 16.2.5 (also 2019). Upgrading these servers did actually address the ios crash, but not Android. And even for ios, while the crash did go away, we still were experiencing map initialization failures, which actually turned out to be caused by some fairly hacky stuff we were doing on startup. Effectively, in order to ascertain 'true' edit/delete/add-feature capabilities, we are basically doing a test add/edit/update and checking to see if the Runtime throws an exception, and then rolling back the edits. Rolling back edits it seems was causing the crash with WMTS, but there was also ocassionally the stack trace below, which seems a lot more related to what we were doing. I still have no idea why rolling back edits would cause the WMTS issue, but it seems to be gone now through a combination of upgrading the build server, and deferring our hack to test editing capabilities. BACKGROUND THREAD 27 - CRASHED ArcGIS-arm64 Esri_runtimecore::Geodatabase::Table::revert_changes(Esri_runtimecore::Geodatabase::Difference_from, boost::optional<Esri_runtimecore::Common::Date_time>) ArcGIS-arm64 std::__1::__function::__func<auto Esri_runtimecore::Mapping::Service_feature_table::undo_local_edits(Esri_runtimecore::Mapping::Task_options const&)::$_36::operator()<Esri_runtimecore::Common::Weak_visitor_ptr<Esri_runtimecore::Mapping::Service_feature_table>, Esri_runtimecore::Mapping::Task_completion_source<void>, Esri_runtimecore::Mapping::Task_options>(Esri_runtimecore::Common::Weak_visitor_ptr<Esri_runtimecore::Mapping::Service_feature_table>&, Esri_runtimecore::Mapping::Task_completion_source<void>&, Esri_runtimecore::Mapping::Task_options&)::'lambda'(), std::__1::allocator<std::__1::allocator>, void ()>::operator()() ArcGIS-arm64 std::__1::__function::__func<Esri_runtimecore::Mapping::Task<void>::Task(std::__1::function<void ()>, Esri_runtimecore::Mapping::Task_options)::$_1, std::__1::allocator<Esri_runtimecore::Mapping::Task<void>::Task(std::__1::function<void ()>, Esri_runtimecore::Mapping::Task_options)::$_1>, boost::any ()>::operator()() ArcGIS-arm64 std::__1::__function::__func<Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0, std::__1::allocator<Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0>, boost::any ()>::operator()() ArcGIS-arm64 pplx::details::_PPLTaskHandle<boost::any, pplx::task<boost::any>::_InitialTaskHandle<boost::any, Esri_runtimecore::Mapping::Task_implementation::Task_implementation(std::__1::function<boost::any ()>, Esri_runtimecore::Mapping::Task_options)::$_0, pplx::details::_TypeSelectorNoAsync>, pplx::details::_TaskProcHandle>::invoke() const ArcGIS-arm64 pplx::details::_TaskProcHandle::_RunChoreBridge(void*) ArcGIS-arm64 Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*) ArcGIS-arm64 Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*) libdispatch.dylib _dispatch_client_callout If you're wondering why we're doing this hack to check edit capabilities, it's because we don't have a good way from the ArcGIS Runtime to check whether or not the user has permissions to update/delete/add. The CanUpdate, CanAdd, CanDelete properties on a FeatureTable don't take licensing and anonymous access into account (see bug ENH-000124520), and LayerInfo OwnershipBasedAccessControl is not populated in all cases (case #02370084 with Esri support). For full reference, here is our code to truly check if the user has for example update permission: If there was a nice little method we could call in the Runtime, that would save us from having to do all this hacky work! public override async Task<bool> UserCanUpdate() { var license = ArcGISRuntimeEnvironment.GetLicense(); if (license.LicenseLevel == LicenseLevel.Lite && Capabilities.SupportsUpdate) { // If we have a Lite-level license, the previous check is not enough to ensure that we are reporting correct values, // we have to assert that anonymous adding and editing are also allowed for this layer (e.g. it must be a publicly shared // layer with editing enabled) if (_supportsAnonymousUpdate == null) { _supportsAnonymousUpdate = Layer.FeatureTable.CanUpdateAnonymously(); } bool supportsAnonymousUpdate = await _supportsAnonymousUpdate; return supportsAnonymousUpdate; } return Capabilities.SupportsUpdate; } internal static async Task<bool> CanUpdateAnonymously(this FeatureTable table) { bool canEdit = false; if (table is ServiceFeatureTable sft && sft.LayerInfo.OwnershipBasedAccessControl != null && sft.LayerInfo.OwnershipBasedAccessControl.AllowOthersToUpdate) { // If the layer has Ownership-Based Access Control (OBAC) configured AND users other than the creator are able to edit the // feature, we can skip manually testing the update operation and instead can rely on this property. canEdit = sft.LayerInfo.OwnershipBasedAccessControl.AllowAnonymousToUpdate; } else { try { // If we are using a Lite level license and the layer does not support OBAC, the best we can do is attempt an "empty" update // and catch the error if it fails. (the CanUpdate() method does not return accurate results in this case). var testFeature = await table.QuerySingleFeatureAsync(); if (testFeature == null) { // If there are no features, we'll have to add a dummy one for testing (which we will remove after). testFeature = table.CreateFeature(); await table.AddFeatureAsync(testFeature); } if (testFeature is ArcGISFeature arcgisFeature && arcgisFeature.LoadStatus != Esri.ArcGISRuntime.LoadStatus.Loaded) { // Need to load the feature before calling the update. await arcgisFeature.LoadAsync(); } // Test update. await table.UpdateFeatureAsync(testFeature); canEdit = true; } catch { // The update failed, so we know for sure that we both cannot update nor delete (since delete is never a // standalone permission). canEdit = false; } finally { // Ensure we clear out any edits we made. try { await table.ClearLocalEditsAsync(); } catch (Exception) { } } } return canEdit; }   ... View more

Hi Morten, Sorry I was a little light on details.  We've seen it consistently on iOS and Android. The app is an offline data collection app, but the crash is occurring on startup (no editing being done), loading an online web map. The last line our lines indicates that we're about to load the map, and then the app crashes. It's occurring about 30-40% of the time on startup, and it's not occurring on builds out of Visual Studio for some reason (only off our build server) which makes it a little more difficult to troubleshoot. I'm just a little confused why it would doing anything to do with WMTS when we don't have any WMTS layers. I will try to get some better diagnostics and see if I can provide you with more details. Jeff ... View more

I don't believe I'm calling any task returning methods without await their result.  Below is the code from the view model for a command that is bound to the view using data binding. Note that the code below is 'simplified' so that is sufficiently illustrative of what I'm trying to achieve. There are no warnings in the build about non-awaited tasks. I have verified that exceptions are caught by putting a throw new Exception() inside of the second SubmitEditsAsync(Map map), and the error is caught and handled. It looks like the error is occurring outside of the call stack (on a separate thread) in the ArcGIS Runtime.         private async void SubmitEditsAsync(OfflineArea offlineArea)         {             try             {                 await SubmitEditsAsync(offlineArea.Map);             }             catch (Exception e)             {                 await _dialogHandler.ShowAlertAsync(e);             }         }         private async Task SubmitEditsAsync(Map map)         {             // Create the sync task             var syncTask = await OfflineMapSyncTask.CreateAsync(map);             syncTask.SyncOfflineMap(new OfflineMapSyncParameters() { SyncDirection = SyncDirection.Upload });             // Create the job             var job = syncTask.SyncOfflineMap(new OfflineMapSyncParameters()             {                 RollbackOnFailure = true,                 SyncDirection = SyncDirection.Upload             });             // Await result             var result = await job.GetResultAsync();         }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Here are the headers for the request that fails (returns http 304): POST /arcgis/rest/services/LA_StreetMap_DesignBase_Unsecured/MapServer/90/query HTTP/1.1 Host: mot-arcgis.latitudegeo.com:6080 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Connection: keep-alive If-None-Match: 1402076183 Connection: keep-alive Accept: */* User-Agent: ArcGISRuntime-NET/100.2.1 (iOS 11.4; iPad5,3) Referer: http://arcgis.com/ Content-Length: 4989 Accept-Language: en-ca And here are the headers for a similar request in Windows that works (returns http 200): POST /arcgis/rest/services/LA_StreetMap_DesignBase_Unsecured/MapServer/90/query HTTP/1.1 Referer: http://geocortexmobileviewerskg3azj8gvpd4/ Accept-Encoding: gzip, deflate User-Agent: ArcGISRuntime-NET/100.2.1 (Windows 10.0.16299; x86; UAP; Windows.Desktop) Content-Length: 4982 Content-Type: application/x-www-form-urlencoded Host: mot-arcgis.latitudegeo.com:6080 Connection: Keep-Alive Pragma: no-cache If you'd like, I can also get you a Fiddler trace. ... View more

Thank you for letting me know! I look forward to the next version. ... View more