本文介绍了如何处理onContextItemSelected在多片段活动的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

限时删除!!

我目前正在努力去适应我的应用程序使用兼容性库为Android V4,甚至到Android提供片段的使用所带来的好处1.6用户。

I'm currently try to adapt my application to use the "Compatibility Libraries for Android v4" to provide the benefits of the usage of fragments even to Android 1.6 users.

到目前为止,这是可能没有大的问题,而是一个上下文菜单的实现似乎更靠谱...

So far this was possible without big issues, but the implementation of a context menu seems to be more tricky...

  • 应用程序的主要活动被延长的 FragmentActivity 类。
  • 的片段都是基于一个它扩展了片段级类。
  • 在该片段类调用 registerForContextMenu() onCreateView()方式和覆盖方法 onCreateContextMenu() onContextItemSelected()
  • The main activity of the applicationis extending the FragmentActivityclass.
  • The fragments are all based on oneclass which extends the Fragment class.
  • The fragment class is callingregisterForContextMenu() in its onCreateView() method and overrides the methodsonCreateContextMenu() and onContextItemSelected().

对于 onCreateContextMenu()这部作品pretty的好。上下文菜单从资源文件膨胀和略微基于所选择的项目修改(这是基于一个ListView ...即使该片段不是ListFragment)。

For onCreateContextMenu() this work pretty well. The context menu is inflated from a resource file and slightly modified based on the selected item (which is based on a listView... even if the fragment is not an ListFragment).

在选择右键菜单项出现问题。 onContextItemSelected()被要求从第一个当前存在的碎片增加了一个。

The problem occurs when a context menu entry is selected.onContextItemSelected() is called for all currently existing fragments starting with the first added one.

在我的情况下片段是用来显示一个文件夹结构的内容。当打开子文件夹片段的上下文菜单和菜单项被选中, onContextItemSelected()首先呼吁上级(取决于有多少片段被允许/可见在这一刻)。

In my case the fragments are used to show the content of a folder structure. When the context menu of a subfolder fragment is opened and a menu item is selected, onContextItemSelected() is first called on the upper levels (depending on how many fragments are allowed/visible in this moment).

现在,我用一种变通方法通过持有最后一个片段的调用它的 onCreateContextMenu()标签上的活动级别的字段。这种方式,我可以调用返回super.onContextItemSelected(项目)一开始的 onContextItemSelected()时,所存储的标签是不一样的getTag()。但是,这种方法看起来有点脏了我。

Right now, I use a workaround by a field on activity level which holds the tag of last fragment calling its onCreateContextMenu(). This way I can call "return super.onContextItemSelected(item)" in the begin of onContextItemSelected() when the stored tag is not the same as getTag().But this approach looks a bit dirty to me.

为什么onContextItemSelected()呼吁所有的片段?而不是一个一个被调用的 onCreateContextMenu()?什么是最优雅的,为什么来处理呢?

Why is onContextItemSelected() called on all fragments? and not just one the one that was calling onCreateContextMenu()?What is the most elegant why to handle this?

感谢先进的。

推荐答案

我找到了一个替代方案。它不会对我的问题,改变任何东西上面,但它使毫无意义的。

I found an alternative. It does not change anything on my problem above, but it makes it pointless.

我有我的应用程序完全删除上下文菜单。相反,我捕捉到一个列表项的longclick和改变在这一瞬间的动作条的可见按钮。从用户的角度来看,这是像一个上下文菜单更加的平板电脑。

I have remove the context menu completely from my application. Instead I capture the longclick on a list item and change the visible buttons of the action bar in this moment.From the user point of view this is much more tablet like as a context menu.

在向后兼容的应用程序的动作条不存在。所以,我决定建立自己的(一种工具栏上的顶部)的设备pre蜂窝。

In backward compatible applications the actionbar does not exist. So I've decided to build my own (kind of toolbar on top) for the devices pre Honeycomb.

如果你想留在上下文菜单中,我没有找到一个更好的解决方案,因为我上面提到的解决方法。

If you would like to stay with the context menu, I did not find a better solution as the workaround I've mentioned above.

这篇关于如何处理onContextItemSelected在多片段活动的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

1403页,肝出来的..

09-06 19:00