Latest Contributions by RichZwaap

You can certainly do that, and that abstraction gets around the view-model needing to know about specific screens within your app, but that's definitely not an MVVM-compliant approach.  I assume that you're passing IRuntimeControls to your view-model, and from there the view-model accesses the MapView?  If that's the case, then your view-model is directly accessing a component of the view.  That not only breaks the guideline that the view-model should not have specific knowledge of the view, but if you're actually making the interface be required by the view-model via dependency injection, then the design is a further step removed from MVVM by imposing requirements on the view in order to use the view-model.  That's the sort of coupling that employment of MVVM is intended to avoid. On the other hand, the controller approach in the example allows the view-model to own and expose an object that will report identify operations to it - should the view happen to use it.  That last bit is key in that it means the view-model is not imposing any requirements on the view layer. Maybe this breaks some true purism of MVVM having code in the code behind.  It's a misconception that MVVM precludes having code in code-behind.  While MVVM would rule out many things that developers would otherwise commonly do in code-behind, the pattern really has nothing to do with whether something is done in XAML or code.  MVVM can still be employed in environments that don't even support XAML like native Xamarin  iOS or Android, and still offers the same benefits.  From the perspective of adhering to the pattern, it's fine, for instance, to consume something coming from your view-model layer in a view's code-behind, to instantiate a view-model, or to manage some sort of interaction between view-layer components. Your approach is certainly valid and presumably very practically useful; there are many different ways of tackling this sort of problem, and solutions need not adhere to MVVM.  But I wanted to clarify a little bit about MVVM and how the approaches here do or don't fit the pattern. ... View more

Have you tried disabling "Use Shared Runtime" and "Use Fast Deployment?"  Those are under Android Options --> Packaging Properties on the project's properties page.  Then uninstall the app from emulator or device and do a full rebuild/redeploy. ... View more

FYI for anyone that might come across this, I've shared a way to handle this in another thread: https://community.esri.com/message/762894-re-accessing-mapview-methods-like-identifygraphicsoverlaysasync-from-viewmodel?commentID=762894#comment-762894 ... View more

I've attached a sample that demonstrates one way of doing this. It includes an IdentifyController utility class that I adapted from an Example App that Mara Stoica‌ is currently working on.  With it, you can listen for identify operations in your view-model by instantiating an IdentifyController and hooking to the IdentifyCompleted event like so: // Initialize the identify controller, specifying the graphics overlay as the target of the identify operation IdentifyController = new IdentifyController() {   Target = graphicsOverlay }; // Listen for identify operations IdentifyController.IdentifyCompleted += IdentifyController_IdentifyCompleted;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Then just add the logic for handling the identify results in the IdentifyCompleted event handler. As far as wiring up an IdentifyController to a given MapView, the sample includes a MapViewExtensions.IdentifyController attached property.  So, with the view-model's IdentifyController instance exposed as a property, that the association can be made in XAML like so: <esri:MapView Map="{Binding Map, Source={StaticResource MapViewModel}}"               GraphicsOverlays="{Binding GraphicsOverlays, Source={StaticResource MapViewModel}}"               samples:MapViewExtensions.IdentifyController="{Binding IdentifyController, Source={StaticResource MapViewModel}}"/>‍‍‍‍‍‍‍‍‍ Hope this helps. ... View more

You don't have to set the BindingContext at the page level.  You can limit it to the control you want to set the binding on, or you can bind directly into the property and not use the BindingContext at all.  So you could have something like: <ContentPage ...>   <ContentPage.Resources>     <ViewModels:ClsRegionPicker x:Key="RegionPickerViewModel" />     <DGViewModel:ClsDataGridViewModel x:Key="ClsDataGridViewModel">   </ContentPage.Resources>   <Picker BindingContext="{StaticResource RegionPickerViewModel}" />   <DataGrid BindingContext="{StaticResource ClsDataGridViewModel}" /> </ContentPage> Notice that the view-models are declared as resources, and then the BindingContext for the Picker and DataGrid are specified separately. ... View more

I've attached a Xamarin Forms version that contains the workaround for iOS.  Note that you'll need to override the OnSizeAllocated method in the page that contains your MapView or SceneView and call PauseRendering/ResumeRendering there.  In the sample, that's done in the MapPage.iOS.cs file that's included in the MapPage.iOS project. -Rich ... View more

This issue has been fixed for the Update 2 release.  I've also put together a workaround that you can use in the meantime, which is included in the attached sample application.  To use the workaround: Add the GeoViewExtensions.cs file to your application Call PauseRendering on your GeoView (MapView or SceneView) before the view is resized Call ResumeRendering on your GeoView after the view is done resizing Note that this workaround is specific to version 100.1.  It is very possible that it will not work with any other release. Hope this helps. -Rich ... View more

There was an issue with version 100.0 that was preventing apps from being submitted to the App Store, but a hotfix was released to address that, and the issue was resolved at 100.1.  Internally, we have taken our samples application all the way through the App Store approval process and have received approval to list it in the store.  The only issue encountered along the way that was specific to the Runtime is that it causes the application size to be large enough that wi-fi is required to install it.  This does not prevent App Store approval, but it will raise a warning during the approval process. ... View more

Hi Brian, The issue can be worked around by removing the MapView from the visual tree when a page is hidden and re-adding it when the page is shown.  In a content page, you can do that as follows: #if __ANDROID__ // We don't need this workaround on other platforms, so limit it to Android protected override void OnAppearing() {     if (!RootLayout.Children.Contains(_mapView))         RootLayout.Children.Add(_mapView);     base.OnAppearing(); } protected override void OnDisappearing() {     if (RootLayout.Children.Contains(_mapView))         RootLayout.Children.Remove(_mapView);     base.OnDisappearing(); } #endif "RootLayout" in the code above would be the UI element that contains the MapView. The basic problem here is that Xamarin Forms' navigation stack appears to render pages one on top of another, rather than one keeping one page in the visual tree at a time.  That leads to the issue you're seeing because there is problem with our MapView (and SceneView) where rendering overlapping views does not work properly on Android. Hope this helps. -Rich ... View more

The final .ipa sizes for apps built with version 100.1 are similar to those for apps built against 100.0.  Note again that this does not prevent release to the App Store; it only means that the app must be downloaded over wi-fi. ... View more

What OS and device/emulator are you seeing this on? ... View more

That message is a warning and does not prevent App Store submission.  As the message indicates, the size limit pertains to the ability to download an app using cellular data and means that an app of that size can only be downloaded using wi-fi.  While that won't prevent your app from being listed in the App Store, I certainly understand that you might want to bring the app size under that limit.  Unfortunately, there's no way to do that when referencing the ArcGIS Runtime in a Xamarin iOS app as of today.  That's in large part due to the breadth of functionality contained within the SDK, but also to some degree how native libraries can be compiled on iOS and the particulars of how the ArcGIS Runtime functionality is packaged for Xamarin iOS.  The large native ArcGIS frameworks you noticed contain the bulk of the ArcGIS Runtime's logic.  The app bundle has to include both of these, as support for both ARM64 and ARMv7 is a requirement of the App Store. Sorry for any inconvenience. ... View more