Latest Contributions by dotMorten_esri

Due to a limitation in Xamarin.Forms itself we unfortunately can't support it at this point. Having said that, I'd actually recommend against showing too much info in the callout itself as it blocks the map - especially on a mobile device. Instead use the callout to quickly identify a feature by-name, and use the image button in the callout to go to a more full-screen feature-centric view to work with the feature. ... View more

If you want to move it interactively, you can use the SketchEditor which supports dragging geometries around. If you want to do it programmatically, you can use PolygonBuilder and iterate through the vertices and offset each vertex by a certain amount (this is actually what the SketchEditor does as you're dragging the feature around). ... View more

Thank you! Since Initialize succeeds, it means the deployment worked fine and you pre-reqs are met. It appears the application crashes when trying to create the native view, which I haven't seen before. One more thing you could try is:  - Go to the project settings and under debug tab, check on "Enable native code debugging".  - Set up the symbols server as described here: https://community.esri.com/community/developers/native-app-developers/arcgis-runtime-sdk-for-net/blog/2019/10/08/announcing-availability-of-arcgis-runtime-sdk-for-net-symbol-files-for-debugging  Then re-run the application, and you should get a much better stacktrace of where it crashes. Once it does crash, go to the Debug section in VS's file menu, and select "Save dump as...". If possible could you share that somewhere for me to download and send me a link (mnielsen (at) esri.com), and we can try and debug what is really happening. Thank you for helping troubleshooting this. ... View more

@Alex: This thread is about UWP throwing, but you're mentioning WPF. I think you started another thread specific to WPF (or are you seeing the same issue with UWP too?) ... View more

If you create a completely new WPF Application, add the Esri.ArcGISRuntime.WPF nuget package, then just add this code:    Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.Initialize() what happens? When you run the template-based apps, what happens? (ie what exception, and where?) Also could you try creating a .NET Core 3.0 WPF Application and do the same thing? Do you also have the required VCLibs installed on your PC? Which version of Windows are you using? ... View more

Yes it's ok that you finish eating 🙂 You can send it to Mike or directly to me (mnielsen (at) esri.com). Also thank you for trying out the .NET Core bits! Much appreciated. That's exactly why we pushed them out a little early (before 3.0 even went final) so we could get some of this feedback. ... View more

I've done several perf testing runs comparing .NET Core and .NET Framework. I see the interop performance about double in speed (similar to what we were already seeing with UWP's .NET Native runtime), but in grand scheme of things those are very small overheads, so in practice it didn't make much difference in real-world scenarios (as most of the work is actually done in native code, and it is the exact same native DLL being used by both). There might be a few places here and there where you'd see some of .NET Core's new features have an effect, but don't expect to see a huge benefit yet. Also make sure you compare Release build performance. In addition we're not (yet) taking full advantage of things like Span<T> etc (and neither is the WPF framework), so we potentially have room for improvement, but as mentioned earlier the bottleneck is actually rarely the .NET side of things, so it would really only have limited impact. We're currently having a high priority on performance on the .NET side of things, and diving into various hot-paths and making targeted optimizations where we can, and will use new language features just for the .NET Core build when that makes sense. You should hopefully see some improvements here and there in v100.7, but this is work that we will continue over many releases. It's hard to rely on DrawComplete and the async set-viewpoint methods for performance testing, as they are timer-based, so even on a slow machine, a zoom is going to take roughly the same amount of seconds (but it might skip some frames and be more "choppy" to keep up), and DrawComplete is unfortunately slightly unreliable right now and might be several frames off. Also your resolution for these tests would be limited to (at-best) the framerate during the operation. Also make sure you perform these tests without the debugger attached. DefaultConnectionLimit: we default to 6, but will respect it if you set a _higher_ default value (as long as it's not int.MaxValue). Anything beyond 10 doesn't seem to have much effect, but once you do go above 6, you'll start seeing quite a lot of CPU usage, so I really don't recommend changing it (in .NET Framework is 2 and we used to use that. By changing it to 6, we saw about 2.5x improvement on tile loading. Going to 10 was about 3.5x faster, but CPU usage started to spike. Higher than that had little-to-no effect. We settled on 6 as it appears to be the defacto standard and in our testing also showed a good trade-off between performance and CPU usage). If you have a sample app you can share that shows the differences you experience between .NET Core and .NET Framework, I'd love to take a look. I'd definitely not expect things to run slower (albeit I wouldn't expect it to be much faster either). ... View more

FYI I've filed a request to update the incorrect .NET Core doc:  https://github.com/dotnet/dotnet-api-docs/issues/3319  From my understanding the http/2 implementation in .NET Core isn't fully complete, which is why it isn't default. Once .NET Core considers it feature complete, you should automatically see v2 requests happening. I think that's a better approach than we forcing a version number on the requests (and until then you can use the workaround you found) ... View more

We are still evaluating whether to default to HTTP/2 or not. At this point we've decided to use the default version of .NET core and not explicitly set it. See https://github.com/dotnet/corefx/blob/release/3.0/src/System.Net.Http/src/System/Net/Http/HttpUtilities.cs#L17   As mentioned above our .NET Core support isn't fully finalized yet. Wrt tile performance I'm not entirely following: Are you saying the behavior is different from .NET Framework? We shouldn't be making requests to the server again for the same tiles if the server said that the tiles can be cached. ... View more

If you just don't set the attributes and add it to the table, won't the feature get its default values once you pull it back out of the table? ... View more

I'm assuming the Android issue you're seeing is a different callstack. I actually happened to reproduce the WMTS issue today, both with VS16.3 and VS4Mac 8.3. It only happens with a very specific app and at about the same ratio you're seeing, and since I recently updated VS2019, I'm wondering if that is related. Up until today, your case was the only one, but we now have two PCs that reproduces it. Sorry I don't have much to go on yet wrt resolving it, but it appears the symbol table for native calls is getting messed up (the specific method happens to be the last method if you sort them all by name, so I think that's more random and doesn't really have anything to do with WMTS). On the up-side it appears to be project specific, so there's probably some still-to-be-discovered project setting that causes this. ... View more

Could you share which specific version of Visual Studio you are using on the build server vs the builds you make locally? We might have a lead that this could be due to a mono bug recently introduced. ... View more

If you know the schema of your data, you could include an empty shapefile with your app, then copy it somewhere and add features to it. Of course this only works if you know which columns and geometry types you'll be needing up-front. ... View more

The exception means you're adding a layer to a map, when it's already in a map. ... View more