Latest Contributions by CalebPourchot

I'm using the javascript api and for any given identify operation on the World Imagery layer you get a handful of Citation results. When you look at their properties, it would seem you could pick the one that represents the tile at the current zoom level using the "FROM_CACHE_LEVEL" and "TO_CACHE_LEVEL" fields, but in my experience these are not reliable. So you have many situations where you can visually see the change from older tiles to newer tiles and yet the citation dates don't change. So, unless there is something I'm missing, this feature is pretty useless. Even the sample map at  https://www.arcgis.com/home/item.html?id=c03a526d94704bfb839445e80de95495 is pretty useless. It just displays all the citations in a page view. If you really care about the date at the zoom you are looking at, there is no way to tell which date applies. Does anyone have a good idea about how to do this reliably?  ... View more

Hi Michael, I'm still seeing a lot of these turning up in my iOS logs with version 100.4: ArcGIS-arm Esri_runtimecore::Labeling::Label_engine_2D_::remove_label_class(std::__1::__map_iterator<std::__1::__tree_iterator<std::__1::__value_type<int, std::__1::shared_ptr<Esri_runtimecore::Labeling::Label_class_> >, std::__1::__tree_node<std::__1::__value_type<int, std::__1::shared_ptr<Esri_runtimecore::Labeling::Label_class_> >, void*>*, long> >) ArcGIS-arm std::__1::__function::__func<Esri_runtimecore::Labeling::Label_engine_::schedule_remove_label_class(int const&)::$_10, std::__1::allocator<Esri_runtimecore::Labeling::Label_engine_::schedule_remove_label_class(int const&)::$_10>, bool (Esri_runtimecore::Labeling::Label_engine_&)>::operator()(Esri_runtimecore::Labeling::Label_engine_&) ArcGIS-arm Esri_runtimecore::Labeling::Label_engine_::update_labels() ArcGIS-arm std::__1::__function::__func<pplx::details::_MakeVoidToUnitFunc(std::__1::function<void ()> const&)::$_2, std::__1::allocator<pplx::details::_MakeVoidToUnitFunc(std::__1::function<void ()> const&)::$_2>, unsigned char ()>::operator()() ArcGIS-arm pplx::details::_PPLTaskHandle<unsigned char, pplx::task<unsigned char>::_InitialTaskHandle<void, Esri_runtimecore::Map_renderer::Label_layer::prepare(std::__1::shared_ptr<Esri_runtimecore::Map_renderer::Drawable::Render_properties>&, std::__1::shared_ptr<Esri_runtimecore::Map_renderer::Display_properties> const&)::$_2, pplx::details::_TypeSelectorNoAsync>, pplx::details::_TaskProcHandle>::invoke() const ArcGIS-arm pplx::details::_TaskProcHandle::_RunChoreBridge(void*) ArcGIS-arm Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*) ArcGIS-arm Esri_runtimecore::Common::Queued_thread::process_message_(std::__1::shared_ptr<Esri_runtimecore::Common::Message_queue::Message> const&) ArcGIS-arm Esri_runtimecore::Common::Queued_thread::execute_() ArcGIS-arm Esri_runtimecore::Common::Thread::thread_proc(Esri_runtimecore::Common::Thread*) ArcGIS-arm void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(Esri_runtimecore::Common::Thread*), Esri_runtimecore::Common::Thread*> >(void*) libsystem_pthread.dylib _pthread_body libsystem_pthread.dylib _pthread_start libsystem_pthread.dylib thread_start and... ArcGIS-arm Esri_runtimecore::Labeling::Label_engine_::remove_graphic_label(int) ArcGIS-arm std::__1::function<void (int)>::operator()(int) const ArcGIS-arm Esri_runtimecore::Labeling::Feature_family::remove_labels(Esri_runtimecore::Labeling::Label_class_ const&, std::__1::function<void (Esri_runtimecore::Labeling::Label_family&)> const&, std::__1::function<void (int)> const&) ArcGIS-arm Esri_runtimecore::Labeling::Label_engine_2D_::remove_label_class(std::__1::__map_iterator<std::__1::__tree_iterator<std::__1::__value_type<int, std::__1::shared_ptr<Esri_runtimecore::Labeling::Label_class_> >, std::__1::__tree_node<std::__1::__value_type<int, std::__1::shared_ptr<Esri_runtimecore::Labeling::Label_class_> >, void*>*, long> >) ArcGIS-arm std::__1::__function::__func<Esri_runtimecore::Labeling::Label_engine_::schedule_remove_label_class(int const&)::$_10, std::__1::allocator<Esri_runtimecore::Labeling::Label_engine_::schedule_remove_label_class(int const&)::$_10>, bool (Esri_runtimecore::Labeling::Label_engine_&)>::operator()(Esri_runtimecore::Labeling::Label_engine_&) ArcGIS-arm Esri_runtimecore::Labeling::Label_engine_::update_labels() ArcGIS-arm std::__1::__function::__func<pplx::details::_MakeVoidToUnitFunc(std::__1::function<void ()> const&)::$_2, std::__1::allocator<pplx::details::_MakeVoidToUnitFunc(std::__1::function<void ()> const&)::$_2>, unsigned char ()>::operator()() ArcGIS-arm pplx::details::_PPLTaskHandle<unsigned char, pplx::task<unsigned char>::_InitialTaskHandle<void, Esri_runtimecore::Map_renderer::Label_layer::prepare(std::__1::shared_ptr<Esri_runtimecore::Map_renderer::Drawable::Render_properties>&, std::__1::shared_ptr<Esri_runtimecore::Map_renderer::Display_properties> const&)::$_2, pplx::details::_TypeSelectorNoAsync>, pplx::details::_TaskProcHandle>::invoke() const ArcGIS-arm pplx::details::_TaskProcHandle::_RunChoreBridge(void*) ArcGIS-arm Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void*) ArcGIS-arm Esri_runtimecore::Common::Queued_thread::process_message_(std::__1::shared_ptr<Esri_runtimecore::Common::Message_queue::Message> const&) ArcGIS-arm Esri_runtimecore::Common::Queued_thread::execute_() ArcGIS-arm Esri_runtimecore::Common::Thread::thread_proc(Esri_runtimecore::Common::Thread*) ArcGIS-arm void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(Esri_runtimecore::Common::Thread*), Esri_runtimecore::Common::Thread*> >(void*) libsystem_pthread.dylib _pthread_body ... View more

I have spent the last couple days trying to narrow down what's happening and i'm not getting very far. It appears that it only happens on Release builds, mostly on Android. However, it will work well for a bit, then suddenly not work.  I downgraded to 100.3, but as far as I can tell there was no change, so it doesn't appear to be related to 100.4. The small exception may be that I'm not seeing it on iOS release builds anymore. However, it really is hard to tell because of how the problem comes and goes.  I'm at a loss for how to troubleshoot this. The only output I see in a debug build that may or may not be relevant is this whenever I open the map: 10-26 08:19:02.338 W/OkHttpClient(12489): A connection to https://www.arcgis.com/ was leaked. Did you forget to close a response body? 10-26 08:19:02.338 W/OkHttpClient(12489): A connection to https://static.arcgis.com/ was leaked. Did you forget to close a response body? Any direction would be appreciated. Thanks. ... View more

FYI - it seems to have started working again just now after not working most of this morning. It's curiously sporadic. ... View more

Hi Morten, iOS and Android. Any number of different devices. It's affecting all of my users. Interestingly, I had a user also try Collector and it was failing to load basemaps as well... I haven't had a chance to try the downgrade yet, but will post again if that seems to change anything. Thanks, Caleb ... View more

That's great news. Thanks Mike Caleb ... View more

I wish I could. I can not reproduce the crash. This is just a report i'm getting from the field. I'm just looking for anything that might steer me towards how to repro it or speculation about what it could possibly be. Thanks, Caleb ... View more

I'm having the exact same problem with all the latest ecosystem updates. ... View more

I've put the project on my Google Drive. I hope that works for you. https://drive.google.com/file/d/0B17QHmpiB_4ma1NBVlk0ZGpJaEk/view?usp=sharing I will also say that I can no longer reproduce the problem after a recent android system update.  ... View more