In 100.0, many classes (MapView, ArcGISTiledLayer, etc.) are declared as "final", in 10.2.8, those classes are not declared final which allows developers to extend for practical customization.
It's simply not necessary and too restricted for real development now. Will the team make some moves to unlock the visibilities of those classes so that we can actually make use of this new SDK?
Hi Mike,
This was much discussed within the team. We took the decision that for our architecture, we wanted to specifically design extensibility points, and make sure these worked well, and offered developers appropriate inheritance options that are documented and work effectively. For example, the DefaultMapOnTouchListener was internally architected to allow external developers to inherit effectively. For other classes, we knew that if developers extended them, this might cause problems.
If this is restricting you from developing the solutions you need to, then please let us know what types you need to extend specifically, tell us about your workflows. We are currently working, for example, on extensible tiled image layers. You can let us know here on geonet, or on ArcGIS Ideas , or if you prefer get in touch via a private Geonet message and we'll take it from there.
Regards
Shelly
Say for example, in 10.2.8, our app extends MapView with custom compass and scalebar, and some workaround for unsolved bugs (e.g. https://community.esri.com/thread/172828#comment-620127).
This extended MapView also further extended with customed features with different themes, in different activities within a single app.
I'd been using similar paradigm to build apps with MapBox MapView (com.mapbox.mapboxsdk.maps.MapView) and Google MapView (com.google.android.gms.maps.MapView) where both are extendable.
I hope the runtime SDK could provides better extensibility as the solution that we're building could sometimes exceeed the basic abilities came from the SDK.
Thanks.
Hi Mike,
Thanks for the additional details there, that does help. Currently there's no plans to support MapView extensiblility specifically, but I'll take your examples back to the team for discussion. We have plans to work on scalebar and compass functionality, although I realise that may not fit the app themes that you're working with, so would not necessarily help out there. (Actually, is there a reason that solutions such as adding Views to the MapView (as a ViewGroup) as shown in this sample Map Rotation | ArcGIS for Developers don't work for you? Or just doesn't fit the pattern you want to follow?). I'll come back and update the thread if there are any changes on this topic.
Regards,
Shelly
Our customized map view is reused in multiple activities actually, where compass is needed in every one of them. Our compass also have some higher level user interactions and linkages with the map view rather a simple direction synchronization. We also have sub-classes of our customized map view as well.
Actually, this can be done just like the sample given by Esri, it's good for demonstration purpose. But after refactoring with the reuse-perspective, it makes more sense for us to put those components (including compass) into our customized map view.
Thanks,
Mike.
Interesting that you're subclassing your MapView. Was there a specific reason that you ruled out using a composition approach, instead of inheritance?
For that case, both are ok actually as long as we got full control of the customized map view.
But that's a different situation actually. When we're using ArcGIS Android Runtime SDK (we are using them since 2.x), apart from extending functionalities to fit our requirements, we also did some quick fixes / workaround to cope with the bugs and errors found in the SDK before the official fixes comes in. Inheritance plays an important roles while composition are not likely to contribute well in this aspect.
Thanks Mike. If I get any news about developments in this area, I'll update this thread.