自定义ViewPager让孩子GoogleMap的控制水平滚动 [英] Custom ViewPager to allow child GoogleMap control to scroll horizontally

问题描述

我正在使用的GoogleMap（V2 API）一ViewPager内部的片段里面。我是有原来的问题是，ViewPager被捕捉所有水平滚动手势因此如果用户开始在垂直或对角线方向上的地图只能被拖动。所有水平拖动被抓获的 ViewPager 。我发现，该解决方案是创建一个派生 ViewPager 类和重写 canScroll 方法。在查看被拖动传递给此方法，这样你就可以根据查看它的类型作出决定。

在我的情况，我的片段是 SupportMapFragment （从 com.google.android.gms.maps 包），它给了我的GoogleMap对象进行交互。然而，实际控制我收到了ViewPager的 canScroll 法类型的 maps.jb 。我有固定的里面我的自定义ViewPager级以下code中的问题。不过，我觉得不舒服检查这个类的名字时，我不知道这件事。什么是maps.j.b？这是在运行时动态创建类？是否有可能在该框架的更新版本来改变类型？鉴于只有View对象，有没有检查该阻力是由地图控件发起的更强大的方法是什么？

  @覆盖
保护布尔canScroll（视图V，布尔checkV，INT DX，诠释的x，int y）对{
    如果（v.getClass（）。的getName（）。等于（maps.j.b））{
        返回true;
    }
    返回super.canScroll（ⅴ，checkV，DX，X，Y）;
}
 

解决方案

  

这在运行时动态创建类？

这可能是一个ProGuard的重命名的输出。

  

是否有可能在该框架的更新版本来改变类型？

AFAIK，是的。我不知道，ProGuard的保证了名将之间建立保持不变。

请注意，这将是依赖于库项目。当你把对库项目的新版本，类名可能会改变。但是，因为这是绑在自己的应用程序，在紧要关头，你可以坚持用这个名字的游戏，只需要当你在库项目的新版本修复了这个名字。

话虽这么说，我同意基于名称匹配的是恶心。

  

由于只有View对象，有没有检查该阻力是由地图控件发起的更强大的方法是什么？

好了，因为这不是一个图形页面，我们没有办法知道什么precisely一个 maps.jb 是。我们知道这是不是一个图形页面，因为它不叫图形页面，和谷歌离开了那名独自（通过 -keep 指令在ProGuard的配置，presumably），所以我们可以从我们的应用程序使用它。

<打击>您可以尝试创建自己的 MapFragment 用自己的图形页面，看看是否有你得到一个图形页面，而不是 maps.jb （这可能是图形页面<内部的一些子类/ code>使用 SupportMapFragment ）。如果获得通过实际的图形页面，那么你可以做直接的平等检查，如果传入的对象是你的 MapFragment 的图形页面。

或者，你可以看看的instanceof 说，一个 maps.jb 是图形页面。

无论这些都保证可靠随着时间的推移，无论是作为可以想象谷歌可能会改变使得图形页面被包裹在一些事项。不过，我的猜测是，它更可能是稳定高于生成的类名。

maps.jb 从 SurfaceView 继承。因此，单程半可靠地检测是否有查看传入 canScroll（）是，如果<测试code>（五的instanceof SurfaceView）。不过，如果地图V2做别的事情后（例如，扩展了 TextureView 的API等级11+），或者如果你的 ViewPager 页面还有一个 SurfaceView （例如， VideoView ）。

我已经申请问题，以试图得到一些稳定的制作方法这个决心加入到地图V2 API。

I am using a GoogleMap (v2 api) inside of a Fragment inside of a ViewPager. The original issue I was having was that the ViewPager was capturing all horizontal scrolling gestures so the map could only be dragged if the user started in the vertical or diagonal directions. All horizontal dragging was captured by the ViewPager. I found that the solution is to create a derived ViewPager class and override the canScroll method. The View being dragged is passed to this method, so you can make a decision based on the type of View it is.

In my case, my Fragment is a SupportMapFragment (from the com.google.android.gms.maps package) which gives me a GoogleMap object to interact with. However, the actual control I receive in the ViewPager's canScroll method is of type maps.j.b. I have fixed the problem with the following code inside my custom ViewPager class. However, I don't feel comfortable checking for this class name when I don't know anything about it. What is maps.j.b? Is this a dynamically created class at runtime? Is it possible for the type to change in a future update of the framework? Given only the View object, is there a more robust way of checking that the drag was initiated by a map control?

@Override
protected boolean canScroll(View v, boolean checkV, int dx, int x, int y) {
    if(v.getClass().getName().equals("maps.j.b")) {
        return true;
    }
    return super.canScroll(v, checkV, dx, x, y);
}

解决方案

Is this a dynamically created class at runtime?

It's probably the output of a ProGuard rename.

Is it possible for the type to change in a future update of the framework?

AFAIK, yes. I am not aware that ProGuard guarantees that the names will stay the same between builds.

Note that this will be dependent upon the library project. When you take on a new edition of the library project, the class name may change. But, since that's tied to your own app, in a pinch, you could stick with the name game, and just need to fix up the name when you take on a new edition of the library project.

That being said, I agree that matching based on name is icky.

Given only the View object, is there a more robust way of checking that the drag was initiated by a map control?

Well, since this isn't a MapView, we have no way of knowing what precisely a maps.j.b is. We know it is not a MapView, as it is not named MapView, and Google left that name alone (via -keep directives in the ProGuard configuration, presumably) so we can use it from our apps.

You could try creating your own MapFragment with your own MapView and see if there you get a MapView instead of a maps.j.b (which might be some internal subclass of MapView used by SupportMapFragment). If you get passed the actual MapView, then you can do direct equality checks to see if the passed-in object is your MapFragment's MapView.

Or, you could see if instanceof says that a maps.j.b is a MapView.

Neither of those are guaranteed reliable over time, either, as conceivably Google could change matters such that the MapView is wrapped in something. However, my guess is that it is more likely to be stable than the generated class name.

maps.j.b inherits from SurfaceView. Hence, one way to semi-reliably detect whether or not a View passed into canScroll() is to test if (v instanceof SurfaceView). This fails if Maps V2 does something else later (e.g., extends TextureView on API Level 11+) or if your ViewPager pages have another SurfaceView (e.g., a VideoView).

I have filed an issue on this to try to get some stable means of making this determination added to the Maps V2 API.

这篇关于自定义ViewPager让孩子GoogleMap的控制水平滚动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！