Latest Contributions by MichaelDavis3

‎08-30-2019

Looks like a solid update - thanks Nick! What is the timeline for getting more info out about implementing AR capabilities? I have an app in mind for a test implementation and I need to get it on the project manager's radar. Also what is the timeline for implementing Metal support? Is that more of a year-end type thing?

‎07-29-2019

Sorry I'm not OP. Was just chiming in that the issue sounds similar on the surface.

‎07-29-2019

That did work for me - implemented that workaround on all our v100 apps for the time being.

‎07-29-2019

Sounds like it might be the same server bug that was causing my issue: https://community.esri.com/thread/236290-invalid-renderer-json-in-runtime-geodatabase There is a service patch out that is supped to fix it - I haven't had time to confirm though.

‎07-26-2019

We've had issues with both - but are primarily focused on "new" collector. This is helpful - it sounds like since you are spinning up your own EASession you aren't using the manufacturer SDK but instead are connecting to the accessory and parsing the serial data yourself? I think we would probably have to do something similar to be able to initialize a connection from our app. All we can do with the SDK is listen for connection and disconnection events and act when we are handed some data. It's unfortunate that ESRI's implementation essentially breaks the manufacturer's SDK. I don't suppose ESRI would be interested in publishing or otherwise providing access to your multi-device connection techniques in the Runtime SDK? 😉

‎07-25-2019

Bringing this over from a support ticket I filed through our MyESRI account in April/May. They finally came back today and told me that this wasn't really something they could help with and that I might try posting to GeoNet. Not sure what that means exactly, but to summarize... Our Runtime apps use the EOS SDK to connect to high-precision GNSS devices. So does Collector. When trying to use both Collector and our apps at the same time they seem to get into a fight over who can use the GNSS data stream. Generally speaking Collector seems to win this fight and our devices are not able to read the data stream until we kill Collector on the iOS device. Collector seems to be doing something when you turn on location that "reacquires" this data stream. I'm hoping someone can share what you are doing and we can figure out how to cooperatively use the GNSS data stream. Email sent to Support Services Added a note 12/31/1969 3:00:00 PM Issue Description: We develop mobile apps using the ArcGIS Runtime for iOS (v100 and legacy apps using 10.2.5). Most of these apps include integration of high-precision GNSS devices (iSXBlue, Arrow) using the EOS SDK. Since the addition of high-precision support to Collector we have had an increase in issues related to obtaining a serial connection to these devices in our apps. Conversations with EOS indicate we are both using the same connection protocol and as such will be in conflict with each other when trying to connect to these devices. As of now if any of our apps are open simultaneously with Collector we will loose the ability to record GNSS metadata in our apps once the user initializes a connection to the same device in Collector. The only workaround seems to be force-quitting Collector to free up the connection, which is not ideal for field projects that want to use both our in-house apps and Collector at the same time. What I'm hoping for is a conversation with the developers who implemented the serial connection bits in Collector so we can see if there is a path forward to share the GNSS connection. As it is now using Collector on projects that also use one of our custom apps is becoming a non-starter, forcing those projects to choose one or the other. This is not a choice we want our project managers to have to make and not really something we anticipated having to deal with when we standardized on the ArcGIS Runtime for mobile mapping apps.

‎07-19-2019

Interesting - so would it be correct to assume that edits are considered invalid but new features can still be added? That would explain why those features were able to be saved as new features. It created duplicates, which was inconvenient, but that's better than not saving at all. Previously we were using featureServiceInfo.fullExtent to define the limits of our replica... for this specific service that is defined as: Full Extent: XMin: -1.966968105025479E7 YMin: 4584716.816155555 XMax: -1.3670387279936444E7 YMax: 1.1525350761196049E7 Spatial Reference: 102100 (3857)

‎07-17-2019

Yes - not sure exactly why it was happening, but editing the geometry was triggering "false" on canUpdateFeature and was then being added as a new record by our app. Changing the extent of our .geodatabase file to cover the whole planet resolved the issue for us. As far as I can tell neither the original geometry or the updated geometry were outside of the service's maximum extent which is what we were previously using for our offline .geodatabase extent... so still not sure what was up.

‎07-11-2019

This appears to be due to the new point being outside the replica extent. Not sure yet though because our users were definitely out inside the extent when editing field points and we got duplicate records.

‎07-11-2019

When users save a record in our apps I check if the feature can be updated, and if not I add the feature instead. In a recent app (100.5) we've noticed that if the user updates the (point) geometry canUpdateFeature is returning as false and triggering the creation of a duplicate feature in the geodatabase. Is this the expected behavior? Should I be detecting an existing feature in another way?

‎07-08-2019

See my post further up the thread for a link to an example. Whatever the Windows bug is, it is preventing ArcGIS Server from creating the unique value renderer symbology that is embedded in the .geodatabase file. Sounds like using simple symbology negates the need for this.

‎07-08-2019

I just saw that - honestly had no idea that option existed... might save a ton of time!

‎07-08-2019

Thanks Nick - I have a ticket in through our organization account and we are looking at the possibility of rolling back recent Windows updates. In the mean-time I'm pushing out app updates with hard coded unique value renderers. This seems to be working and will keep our runtime apps functioning... not sure what we will do about any Collector/Explorer users who might be consuming registered feature service published from ArcMap, but I suppose that is a topic for a different forum. Thanks again.

‎07-03-2019

Link to my post in iOS Runtime forum - appears this is affecting runtime checkouts as well: https://community.esri.com/thread/236290-invalid-renderer-json-in-runtime-geodatabase

‎07-03-2019

Our ArcGIS Servers (10.6.1) seem to have started producing invalid runtime .geodatabase exports at some point in the last few days. It looks like the runtime databases no longer contain valid JSON for unique value renderers. Whereas the JSON in the runtime gdb would previously looked like this: {"drawingInfo":{"renderer":{"type":"uniqueValue","field1":"TestPass","field2":null,"field3":null,"defaultSymbol":null,"defaultLabel":null,"uniqueValueInfos":[{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372},"markerGraphics":[{"type":"CIMMarkerGraphic","geometry":{"rings":[[[11.89,1.51],[13.42,1.97],[16.03,3.69],[17.78,6.24],[18.25,7.75],[18.41,9.35],[18.25,10.95],[17.78,12.45],[16.03,15.02],[13.42,16.73],[11.89,17.2],[10.25,17.35],[8.61,17.2],[7.07,16.73],[5.69,16.0],[4.49,15.02],[2.75,12.45],[2.47,11.71],[2.27,10.95],[2.11,9.35],[2.27,7.75],[2.75,6.24],[4.49,3.69],[5.07,3.17],[5.69,2.71],[7.07,1.97],[8.61,1.51],[10.25,1.35],[11.89,1.51]]],"spatialReference":{"wkid":null}},"symbol":{"type":"CIMPolygonSymbol","symbolLayers":[{"type":"CIMFill","enable":true,"colorLocked":true,"pattern":{"type":"CIMSolidPattern","color":[0,197,255,255]}}]}}]}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_84"},"value":"Not Tested","label":"Not Tested","description":""},{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372},"markerGraphics":[{"type":"CIMMarkerGraphic","geometry":{"rings":[[[11.89,1.51],[13.42,1.97],[16.03,3.69],[17.78,6.24],[18.25,7.75],[18.41,9.35],[18.25,10.95],[17.78,12.45],[16.03,15.02],[13.42,16.73],[11.89,17.2],[10.25,17.35],[8.61,17.2],[7.07,16.73],[5.69,16.0],[4.49,15.02],[2.75,12.45],[2.47,11.71],[2.27,10.95],[2.11,9.35],[2.27,7.75],[2.75,6.24],[4.49,3.69],[5.07,3.17],[5.69,2.71],[7.07,1.97],[8.61,1.51],[10.25,1.35],[11.89,1.51]]],"spatialReference":{"wkid":null}},"symbol":{"type":"CIMPolygonSymbol","symbolLayers":[{"type":"CIMFill","enable":true,"colorLocked":true,"pattern":{"type":"CIMSolidPattern","color":[85,255,0,255]}}]}}]}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_85"},"value":"Pass","label":"Pass","description":""},{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372},"markerGraphics":[{"type":"CIMMarkerGraphic","geometry":{"rings":[[[11.89,1.51],[13.42,1.97],[16.03,3.69],[17.78,6.24],[18.25,7.75],[18.41,9.35],[18.25,10.95],[17.78,12.45],[16.03,15.02],[13.42,16.73],[11.89,17.2],[10.25,17.35],[8.61,17.2],[7.07,16.73],[5.69,16.0],[4.49,15.02],[2.75,12.45],[2.47,11.71],[2.27,10.95],[2.11,9.35],[2.27,7.75],[2.75,6.24],[4.49,3.69],[5.07,3.17],[5.69,2.71],[7.07,1.97],[8.61,1.51],[10.25,1.35],[11.89,1.51]]],"spatialReference":{"wkid":null}},"symbol":{"type":"CIMPolygonSymbol","symbolLayers":[{"type":"CIMFill","enable":true,"colorLocked":true,"pattern":{"type":"CIMSolidPattern","color":[255,0,0,255]}}]}}]}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_86"},"value":"Fail","label":"Fail","description":""}],"fieldDelimiter":","},"transparency":0,"labelingInfo":null}} It now looks like this: {"drawingInfo":{"renderer":{"type":"uniqueValue","field1":"TestPass","field2":null,"field3":null,"defaultSymbol":null,"defaultLabel":null,"uniqueValueInfos":[{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372}}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_84"},"value":"Not Tested","label":"Not Tested","description":""},{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372}}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_85"},"value":"Pass","label":"Pass","description":""},{"symbol":{"type":"CIMSymbolReference","symbol":{"type":"CIMPointSymbol","symbolLayers":[{"type":"CIMVectorMarker","enable":true,"colorLocked":true,"anchorPoint":{"x":0.00899999999999999932,"y":0},"anchorPointUnits":"Points","scaleStrokesAndFills":true,"size":14,"dominantSizeAxis3D":"Z","frame":{"xmin":0,"ymin":0,"xmax":19.01102362204724372,"ymax":19.01102362204724372}}],"anchorPointUnits":"Relative","scaleX":1},"symbolName":"Symbol_86"},"value":"Fail","label":"Fail","description":""}],"fieldDelimiter":","},"transparency":0,"labelingInfo":null}} Aside from being considerably shorter this JSON is missing the marker symbols from the unique value renderer object. Here's a screenshot of a JSON diff: This is happening on multiple servers. PLEASE HELP!! Happy 4th everyone 🙂

Online Status	Offline
Date Last Visited	Tuesday

My Ideas

Latest Contributions by MichaelDavis3

Re: Runtime 100.6 is here!

Re: Symbols with Images not displaying - Layer Renderer

Re: Symbols with Images not displaying - Layer Renderer

Re: Symbols with Images not displaying - Layer Renderer

Re: How can we make Collector play nice with Runtime apps and share GNSS connections?

How can we make Collector play nice with Runtime apps and share GNSS connections?

Re: canUpdateFeature returning false when geometry updated

Re: canUpdateFeature returning false when geometry updated

Re: canUpdateFeature returning false when geometry updated

canUpdateFeature returning false when geometry updated

Re: Feature layer not displaying in Explorer app, but displays in AGO

Re: Invalid renderer JSON in Runtime geodatabase

Re: Invalid renderer JSON in Runtime geodatabase

Re: Feature layer not displaying in Explorer app, but displays in AGO

Invalid renderer JSON in Runtime geodatabase

Re: Windows Support as Amazon Store is End of Life

Icon source for callout buttonimage

Re: Trying to create an ESRI portal for my organiz...

Re: Backup In Progress impeding work 2.9.2

Re: Publish Multiple Feature Services From One Ent...

Esri Forestry Group (EFG)

Alaska GIS Users