AndExplore: LayouInflater-access, Recyclerview-Reference

Hi,
I would appreciate some clarifications regarding some confusion i experienced when following the AndExplore Book:

  • page 153 : we passed the layoutInflater as an argument to our custom ListAdapter class constructor however couldn't we use the layoutInflater from the parent provided in the onCreateViewHolder () function? like the following : override fun onCreateViewHolder(parent: ViewGroup, viewType: Int) = RosterRowHolder(TodoRowBinding.inflate( LayoutInflater.from(parent.context) , parent, false))
  • page 158: we got the reference to our recyclerView using its ID by typing: view.item.apply{//} Couldn't we use the item (aka. recyclersView ID) without typing view.item as we have done with all the previous widgets?
  • I would like to know if there's any disadvantages of using the toolbar provided to us by Android Studio since in the project we got rid of it then we implemented our own ! Is this just to demonstrate for us how to implement our own toolbar or is there any disadvantage of using the default one? or any advantage of implementing our custom toolbar?
Thanks for help Hadi

I do not like using LayoutInflater.from(). I recommend using getLayoutInflater(). That way, if a class overrides getLayoutInflater(), you get the proper inflater.

Ummm… yes. I am not quite certain why I did it that way. :slightly_frowning_face:

Android Studio did not give us a Toolbar. We added one ourselves, to the activity, in “Setting Up the App Bar”. We then switched to using that layout in a fragment, but the Toolbar needs to be in the activity (for use by the Navigation component). That is why we wind up moving the Toolbar from the original activity layout to the new activity layout. So, I am not quite certain what “default one” you are referring to.

Hi,
First of All, thanks for the clarifications and fast reply.
Regarding the last point , sorry for confusion but i think i got the answer from the official documentation:
this is the link

" This class describes how to use the v7 appcompat support library’s Toolbar widget as an app bar. There are other ways to implement an app bar—for example, some themes set up an ActionBar as an app bar by default—but using the appcompat Toolbar makes it easy to set up an app bar that works on the widest range of devices, and also gives you room to customize your app bar later on as your app develops."

I think my confusion was
Toolbar vs Action Bar!?

As I think I mentioned in the book, Google made a mess of all these “bars”. IMHO, “action bar” has two meanings.

One meaning is “the toolbar-like thing that we get from a theme if we do not opt out”. This works, and it is usually my default choice, personally. However, Google promotes developers using Toolbar explicitly, partly with an eye towards more complex scenarios (e.g., collapsing app bar). So, I elected to use a Toolbar in this book.

The other meaning is “a shared spot for menus and toolbar-style buttons that activities and fragments can both contribute towards”. If you are going to use a Toolbar, IMHO it is simpler to make it have the action bar role than it is to create your own API for fragments to control the contents of the Toolbar when the fragment is visible. So, the app is going this route, calling setSupportActionBar() to say “use this Toolbar as the action bar, since our theme did not request an action bar”.