IssueTracker

[Comment deleted]

Note: According to documentation addToBackStack is optional.
Since the app crashes and the back button does not retrieve the correct fragment, I would reconsider the priority.

LifeCycle of the App
04-07 20:34:46.115: D/Fragment_1(15309): onCreateView Fragment_1
04-07 20:34:46.115: D/Fragment_1(15309): onResume Fragment_1
Click to open 2
04-07 20:34:49.148: D/Fragment_1(15309): onPause Fragment_1
04-07 20:34:49.148: D/Fragment_2(15309): onCreateView Fragment_2
04-07 20:34:49.148: D/Fragment_2(15309): onResume Fragment_2
Click to open 3
04-07 20:34:53.633: D/Fragment_2(15309): onPause Fragment_2
04-07 20:34:53.633: D/Fragment_3(15309): onCreateView Fragment_3
04-07 20:34:53.633: D/Fragment_3(15309): onResume Fragment_3
back Button. Since 3 is not on backstack, app returns to 1 (not pausing 3)
Here Frag 1 and 3 are running and displayed overlaying!
04-07 20:35:03.653: D/Fragment_1(15309): onCreateView Fragment_1
04-07 20:35:03.653: D/Fragment_1(15309): onResume Fragment_1
back Button on 1 - App exit
04-07 20:35:23.474: D/Fragment_1(15309): onPause Fragment_1
04-07 20:35:23.474: D/Fragment_3(15309): onPause Fragment_3

-----

LifeCycle 2 with random navigation and app crash

04-07 20:36:35.311: D/Fragment_1(15504): onCreateView Fragment_1
04-07 20:36:35.311: D/Fragment_1(15504): onResume Fragment_1
open 2
04-07 20:36:37.764: D/Fragment_1(15504): onPause Fragment_1
04-07 20:36:37.774: D/Fragment_2(15504): onCreateView Fragment_2
04-07 20:36:37.774: D/Fragment_2(15504): onResume Fragment_2
open 3
04-07 20:36:40.527: D/Fragment_2(15504): onPause Fragment_2
04-07 20:36:40.527: D/Fragment_3(15504): onCreateView Fragment_3
04-07 20:36:40.527: D/Fragment_3(15504): onResume Fragment_3
back button -> returns to 1
04-07 20:36:41.478: D/Fragment_1(15504): onCreateView Fragment_1
04-07 20:36:41.478: D/Fragment_1(15504): onResume Fragment_1
open 2 (Note: Here 1 should be paused. Instead 3 is paused)
04-07 20:36:45.462: D/Fragment_3(15504): onPause Fragment_3
04-07 20:36:45.462: D/Fragment_2(15504): onCreateView Fragment_2
04-07 20:36:45.462: D/Fragment_2(15504): onResume Fragment_2
open 3 (now 1 is paused instead of 2)
04-07 20:37:03.341: D/Fragment_1(15504): onPause Fragment_1
04-07 20:37:03.351: D/Fragment_3(15504): onCreateView Fragment_3
04-07 20:37:03.351: D/Fragment_3(15504): onResume Fragment_3
back button (now 2 is paused and system crashes)
04-07 20:37:09.908: D/Fragment_2(15504): onPause Fragment_2
04-07 20:37:09.908: D/AndroidRuntime(15504): Shutting down VM
04-07 20:37:09.908: W/dalvikvm(15504): threadid=1: thread exiting with uncaught exception (group=0x41444930)
04-07 20:37:09.908: E/AndroidRuntime(15504): FATAL EXCEPTION: main
04-07 20:37:09.908: E/AndroidRuntime(15504): java.lang.IllegalStateException: Fragment already added: Fragment3{4171b0e0 #2 id=0x7f070000 Fragment_3}
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.FragmentManagerImpl.addFragment(FragmentManager.java:1128)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.BackStackRecord.popFromBackStack(BackStackRecord.java:722)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.FragmentManagerImpl.popBackStackState(FragmentManager.java:1484)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:490)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.Activity.onBackPressed(Activity.java:2167)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.Activity.onKeyUp(Activity.java:2145)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.view.KeyEvent.dispatch(KeyEvent.java:2633)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.Activity.dispatchKeyEvent(Activity.java:2375)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1903)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.view.ViewRootImpl.deliverKeyEventPostIme(ViewRootImpl.java:3701)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.view.ViewRootImpl.handleImeFinishedEvent(ViewRootImpl.java:3651)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:2818)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.os.Handler.dispatchMessage(Handler.java:99)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.os.Looper.loop(Looper.java:137)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at android.app.ActivityThread.main(ActivityThread.java:5227)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at java.lang.reflect.Method.invokeNative(Native Method)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at java.lang.reflect.Method.invoke(Method.java:511)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:562)
04-07 20:37:09.908: E/AndroidRuntime(15504):    at dalvik.system.NativeStart.main(Native Method)

This happens also if not ActionBarCompat/getSupportFragmentManager but only default Fragment/getFragmentManager (v14+) is used.

We could use the tools: namespace for those too, e.g.

<merge
  tools:parentTag="LinearLayout"
  tools:orientation="vertical"
/>

It would be even better if we could "point" to a context in other layouts, e.g.
   tools:parent="@+id/myContainer"
and then the IDE would find myContainer and use its configuration (tag and attributes etc) for rendering. But perhaps there are many scenarios where you don't have a static layout where the <merge> is inserted? Having to create a real layout resource for this would be bad. Maybe supporting both types would be worthwhile?

I can see a problem with tools:orientation in terms of support.
Since it probably easier to just point to current attributes (android:*) of merge tag, then adding support for all available or not yet available views and their attribute names.
I'm not sure how exactly it works internally, maybe this will be not an issue?

Usually I have two scenarios of using merge:
1. re use piece of layout in multiple static layouts
(Usually, parent should be the same, but if it is not how to detect/select what is correct parent to draw for?)
2. use it as layout for custom view (ViewGroup) to avoid extra parent.

Very useful ticket. This important for design preview.

<merge
  tools:parentTag="LinearLayout"
  tools:orientation="vertical"
/>

Looks bad, duplicate code for attributes. And a different set of attributes for different layouts. For example, RelativeLayout not have attribute 'orientation'.

What happens when parent layout changed? You need change all merge layout, double work for simple task.

I do not know how best to implement this task.
But I think it is not bad to review this option:

<merge
  tools:parentLayout="@layout/my_parent_linear_layout"
/>

We just indicate parent layout of our resources and IDE copy all attributes from my_parent_linear_layout.xml root layout.

Ant option to specify root tag of layout file:
<merge
  tools:parentLayout="@layout/my_parent_linear_layout"
  tools:parentLayoutId="@+id/red_panel_layout"
/>

This copy attributes from child layout with id 'red_panel_layout' of file my_parent_linear_layout.

For the cases where we do not know the final layout, runtime creation:
<merge
  tools:parentTag="LinearLayout"
/>

or

<merge
  tools:parentClass="com.example.MyCustomLayout"
/>

For addition attributes may be use something like 'style'?

<merge
  tools:parentTag="LinearLayout"
  tools:style="@styles/PreviewMergeStyle"
/>

Where style contains something like this:
<style name="PreviewMergeStyle">
  <item name="android:orientation">vertical</item>
</style>

And we can use same style for parent layout runtime creation with constructor parameter 'defStyleAttr':
public View (Context context, AttributeSet attrs, int defStyleAttr)

What do you think about this?

And what about define parent XML layout which contain include and you will se merge rendered directly into your parent layout.

+ 1 for this

FYI - note that in 0.5.8 we have Show Included In support ( http://tools.android.com/recent/androidstudio058released ) so if you set
<merge xmlns:tools="..." tools:showIn="@layout/includer" ...>
you can get the layout rendered with the intended tags surrounding the <merge>. That obviously requires for you to have that other layout which includes this one, which may not be the case for some usecases for <merge>, but there probably are many cases where it *does* help.

Hi guys, it's an important feature now with transition, where there is no include in any layout.

My idea is try to cover up at least a few more scenarios. The shownIn helps in some situations, however how about if we get a tag called "renderOn". Would be something like:

"tools:renderOn:[FrameLayout, LinearLayoutVertical, LinearLayoutHorizontal, etc..]"

"tools:renderOn:nz.co.gavazzi.MyCustonViewGroup",

"tools:renderOn:@layout/activity_transition",

and specially for transition:

"tools:renderOn:@layout/activity_transition"
"tools:containerId:"@+id/my_container"

Regards

This still needs a solution for Compound Controls (/Components/Views), where the <merge> layout is inflated from code.

Lets go iOS if Google isn't able to provide a good IDE!

@20 pretty sure xcode isn't any better. Also, it requires you to have a mac.

I guess it works like a charme! :-) Are you really developing on a device other then a MAC??!

@22 Please stay on the subject. It doesn't matter on what I work, as Android-Studio is supported on all major OSs.

+1 For getting this implemented ASAP

I'm also interested in getting this implemented.

I guess this ticket is a dub of https://code.google.com/p/android/issues/detail?id=53145

Any chance of getting this supported to support passing a class for the view group for the merge tag?

Makes sense to support passing a layout but in some cases where compound components are used in a custom view group this solution doesn't work at all and leaves the preview tool useless.

In the near future a <merge> tag will support a tools parentTag attribute which will be shown in the property inspector (feature in 2.2).

When the parentTag is present:
1) LayoutLib will use the specified class to render the merge view.
2) All attributes of the specified class will be available in the advanced property sheet (not the inspector) for the <merge> tag.
3) Only the layout properties corresponding to the specified parent (instead of all possible layout properties) will be associated with the children of the merge tag.

Great news! Looking forward to this tool.

It was released as part of 2.2. You additionally need to give layout_width and layout_height attributes on the <merge> tag to render it properly in the preview.

@31 with "tools" namespace, right?

See @29 "a tools parentTag attribute". So yes.

Yes, tried it. For example:

tools:parentTag="RelativeLayout"

@34 Wait, where was it announced? Can I use it now? Are there other tags related to this?

I can confirm that it works as advertised when giving the parentTag and widht/height. Thanks for the addition. :)

Also, if you use a LinearLayout for your parentTag, you may also set
tools:orientation="vertical"
and it will work OK.