TYL 20 (Date: 07/20/2016)
It seems that, from Android Studio 2.2 Preview 5, autoconnect icon from Layout Editor, is displayed only if we use ConstraintLayout. If you have another type of view as root view, the icon won’t be displayed.
If you add the ConstraintLayout manually from xml (from “text” mode, not “design”) as root view, and you had in the beginning, let’s say, a LinearLayout, you must close the xml file and reopen it in order for the Design view to be refreshed.
TYL 19 (Date: 07/18/2016)
colorPrimary attribute declared in AppTheme cannot be overridden programmatically. These attributes are just “read-only”. If we need to change the theme we have to:
- use “?attr:colorPrimary” in xml for our views
- use setTheme before setContentView() within a base Activity class
- recreate() the Activity in order to take effect
TYL 18 (Date: 07/14/2016)
When using NavigationView or NavigationDrawer, calling sync state is necessary or else your hamburger icon for NavigationView won’t show up.
TYL 17 (Date: 07/13/2016)
app:layout_scrollFlags="scroll|enterAlways" This flag is used to define how the toolbar should react when the list is scrolled. In this case, when the list is scrolled, to toolbar will hide.
TYL 16 (Date: 07/13/2016)
android:theme="@style/AppTheme.AppBarOverlay" Setting this theme, the default color of the text on the tabs and toolbar will be changed from black to white. If not set, the text will be black and would look like this:
TYL 15 (Date: 07/113/2016)
android:fitsSystemWindows="true" Boolean internal attribute to adjust view layout based on system windows such as the status bar. If true, adjusts the padding of this view to leave space for the system windows. Will only take effect if this view is in a non-embedded activity. If not set on the DrawerLayout, the status bar would look like this which is wrong.
TYL 14 (Date: 07/11/2016)
If you need to get the primaryColor from current theme in an xml file in order to set it to your view, you can do this by using ?attr:colorPrimary. But you should be aware that this attribute cannot be used for drawable resources below API Level 21 (Lollipop). The app will crash.
TYL 13 (Date: 07/10/2016)
This property is mandatory to be set for a content containing a scrollable view (a FrameLayout in my case which will be replaced by a fragment with a RecyclerView) when using CoordinatorLayout together with NavigationView. If not set, the first item in the list will not be visible as it will be behind the tabs. And when set, the first item in the list is below the tabs and fully visible.
CoordinatorLayout MUST NOT be used in fragment’s xml. If the CoordinatorLayout is set inside fragment’s xml, the views from the bottom of the screen might not be visible.
That if we use TabLayout and we don’t add this property to the TabLayout widget in xml,
the tabs won’t be scrollable and their width will be wrapped like below:
So, don’t forget to add the “scrollbale” property.
That inflatedId for a ViewStub overrides the existing ID of the view that was just inflated.
That the notifyDataSetChanged for a viewPager is mandatory if you change the data set (the number of items from a list). If not called, the following error will be displayed:
“java.lang.IllegalStateException: The application's PagerAdapter changed the adapter's contents without calling PagerAdapter#notifyDataSetChanged!”
That in a viewPager getItemPosition(Object object) is triggered only by notifyDataSetChanged.
That difference between FragmentPagerAdapter and FragmentStatePagerAdapter is that FragmentPagerAdapter never removes fragments from the FragmentManager, it only detaches and attaches them, while FragmentStatePagerAdapter will remove the items and recreate them when used with getItemPosition() POSITION_NONE.
In general, FragmentPagerAdapter is used for fragments that are permanent.
That PagerAdapter.POSITION_NONE will remove and recreate all the fragments that are alive from the adapter. It is usually used because notifyDataSetChanged doesn’t work by itself on a viewpager.
That when we open a Fragment using replace() method together with addToBackStack() the previous Fragment will go again through all the lifecycle of the Fragment when the back button is pressed. When we open a Fragment using add() method, the previous Fragments preserved its state when the back button is pressed (Fragment will not go again through all the lifecycle).
That viewPager works ok inside another ViewPager on which there is a scrollview.
wrap_content doesn’t work on a viewPager. Since a ViewPager loads separate pages, and not all at once, it won’t know what ‘wrap-content’ actually means.
That even if you set a height dimension for a view and then use “include” to include your layout, using wrap_content in the include tag will ignore the dimension, you have to set the dimension again exactly like in your layout. In fact it ignores any dimension rule, They have to be set again in the include tag.
That if you already have layout_height set in your xml, it will not be overridden if you set it again in a style. (It kinda makes sense :))