Latest Contributions by JeremyRoberts2

Hello.  I went ahead and added in something like the following in MapView... onLayerViewStateChanged: {    console.log("LAYER NAME: "+layer.name);    var stateFlag = layerViewState.statusFlags;    if (stateFlag == Enums.LayerViewStatusActive)       console.log("layerViewState Active");    if (stateFlag == Enums.LayerViewStatusNotVisible)       console.log("layerViewState Not Visible");    if (stateFlag == Enums.LayerViewStatusOutOfScale)       console.log("layerViewState Out of scale");    if (stateFlag == Enums.LayerViewStatusLoading)       console.log("layerViewState Loading");    if (stateFlag == Enums.LayerViewStatusError)       console.log("layerViewState Error"); }   This resulted in... qml: LAYER NAME: USA Soils Map Units qml: layerViewState Not Visible qml: LAYER NAME: USA Soils Map Units qml: layerViewState Active   So seems like the end result is that it is "Active".  I also checked map.operationalLayers.get(0).visible and it is "true". Thanks for the feedback!  I'm still baffled and don't know why it isn't visible. ... View more

This is great news!  We will try it out. Thanks! ... View more

Hi James! We downloaded 100.10.  Initial tests appear to show the memory issue is fixed.  We will continue testing this.  It appears as though the feature tiling requests getting queued up and causing worse performance in our queries, because they get slapped at the end of the queue, is still there.  In our case we can pan the map a few times, and then try to query a feature and it takes 13 seconds to return that single query because it has to wait for the huge pile of tiled based requests to finish.  Was there anything ESRI was able to implement in 100.10 to help alleviate this issue?  Is there a flag or something we can define locally to turn off tiled based requests now? Thanks! ... View more

Hi Lucas, Your reply was very enlightening.  I was not aware of this helper .app.  So I looked at the package contents and in my case, the WebEngineProcess.app helper actually is getting copied in correctly.  What appears to be happening is that if I sign the whole app package, it somehow corrupts that WebEngineProcess.app helper.  Before signing, it is approx 26kb and runs fine.  After signing it becomes 48kb and the webview no longer works.  Any idea what is going on here?  True, if I subsequently manually copy back over WebEngineProcess.app in /Helpers it starts working again.  But one would think the signing process shouldn't break it.  The command I am using to sign our app package is... codesign --keychain $home/Library/Keychains/login.keychain --deep --force --verbose --timestamp -s "mysigningkey" --entitlements $PROJSOURCEROOT/mac/entitlements.plist --options runtime WebViewTest.app ... View more

@JamesBallard1, Thanks for the reply!  We will be anxiously awaiting 100.10 🙂 Given that our iPad users are essentially locked into one of the old versions of our app, because of this memory issue (and also the 100.9 issue), do you happen to know if there is any work-around we can implement on our side with 100.7?  As in, is there maybe a config file that can be tweaked after installing the SDK on our machines, or is there a setting on our ArcGIS servers or feature layers that might override whatever is causing 100.7 to consume memory?  Or anything like that?  Just curious.  Likely it is a more significant issue where the fix can only be required with an SDK code change, but I thought I'd ask just in case there was something we could do on our side to hold us over until 100.10. Thanks! Jeremy ... View more

I can confirm that it looks like 100.9 does not exhibit the issue.  So that is good.  Our problem though is that it appears 100.9 has a different issue which is making us hesitant to upgrade.  Please see this post from my colleague who works on the same app... https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/tile-based-feature-requests-for-extent-any-way-to-revert-to/m-p/184867/highlight/true#M899 I'm worried getting rid of one issue by upgrading, will introduce another issue in our app 🙂 mostly due to the number of requests being queued up and therefore the overall time to return an identify taking longer (since it is behind a large queue).  Any other suggestions? ... View more

Ah, yeah I do see it under <app_bundle>/Contents/Resources/qml/Esri/ArcGISExtras.  Thanks.  So then it seems as though on my machine if runtime is installed, it is trying to use that location rather than the one in the app.  Do you think there is some link that needs to be changed during the build process?  Do I need to run install_name_tool on something to get it to point to the file in the app_bundle?  I'm not sure what library is calling it.  We have its import inside main.qml and in various JS files.  Seems like to run install_name_tool I'd need to know what runtime file is referencing Extras. P.S. - I ran the following to make sure all dylibs within my app bundle have no reference to my runtime installation... #!/bin/bash for i in $(find . -name "*.dylib"); do     otool -L $i done Then examined the output searching for "jr9128".  Nothing was found. Could the runtime installer be setting some path that causes the app to try to access the file outside the bundle?  This is only an issue on my machine because it does find the file at the runtime path (which has a foldername specific to me) and of course that particular copy of libArcGISExtrasPlugin.dylib is not notarized.  If we don't attempt to notarize our app at all with Apple it runs too presumably because it doesn't have the extra checks on everything. ... View more

I have not tried that.  But this begs the question, do I need to manually copy libArcGISExtrasPlugin.dylib into the Frameworks folder of the app? ... View more