Account switching in navigation drawer #1537
Conversation
|
Ugly as hell... |
|
I don't know if you want to add more dependencies but you migh wanna check this out https://github.com/mikepenz/MaterialDrawer |
|
Seems to be a very good lib, what do you think @AndyScherzinger @jancborchardt @davivel |
|
@tobiasKaminsky I'll take a look and pimp it :) I also stumbled across the lib but with the more recent additions to the AppCompat Drawer implementation I am not sure it is worth the dependency. I'll see if we can add the functionality with the AppCompat lib. The neat thing about the Lib is everything comes out of the box (sticky footer, vector support, account switcher) on the other hand it also relies n the AppCompat lib and thus we would then always stay in sync with the versions imho which might be paintful in case we need a bug fix release from that lib which forces an AppCompat update. |
|
Yep, it should definitely look like the switcher in the linked library. :) Also, the last entry of the dropdown should then be »Add account« so we can completely remove this section from the settings. |
|
In that case we probably should utilize the library with the mentioned benefits like:
Downside might be that besides a certain AppCompat lock (atm 23.2.1) due to the lib is that it adds some more AppCompat libs and lib internal stuff, see: https://github.com/mikepenz/MaterialDrawer/blob/develop/library/build.gradle @davivel what is your opinion? |
I remember that we discussed this and said that the drawer is just a switch for the accounts and should not function as add/remove. This would also keep the drawer clean and simple and focus on the tasks that are often used. |
|
The account switcher would automatically bring such a feature, b/c the user switches swaps the list and the below menu/actions so this would be an option to use if we make use of the lib. Else we should keep it simple since the fully blown implementation like the one offered needs a lot of effort to implement by yourself.
|
|
After a couple of hours of playing around with the actual implementation I couldn't get anywhere style-wise yet 😞 |
|
I'm still working on it moving on to the actual |
|
Screenshots of the drawer using the Google Support lib can now be found here: #1552 (comment) |
|
Just to understand: which lib do you mean? |
|
As for the dependency discussion I am referring to https://github.com/mikepenz/MaterialDrawer as for the latest comments by me I am referring to the support lib from Google/Android. As for the https://github.com/mikepenz/MaterialDrawer lib we do get a fully implemented, abstract drawer lib at the cost of a competing appcompat lib dependency which makes things complicated. As for the later that means a bit more work now but then we are "just" depending on the google compatibility libs we are already depending on to support material design all the way back to 4.0 |
|
Ok, I understand. I would also rather keep the deps small and implement the account switching by ourselves. |
|
The problem I had was with the display of the accounts in the list especially with their size, disctances between radio button icon and circle-letter icon. Besides that I will anyways try to implement it the "standard" way if one can call it that as it is shown in many apps flipping the menu item/list for a accounts list via the account displayed in the drawer's header. Question is if @jancborchardt is fine with the then changed visuals and if the overall decision trying to implement it ourselfs is also fine with @davivel (which I guess so, since we would not use a lib for that :). So right now I am simply waiting for Jan's comment on this :) The visual difference between the actual implementation and the Google one is font size and weight... |
|
Looks good to me. Our implementation actually has nicer whitespace and the name text properly left aligned with the other list item text. :) |
|
So moving to the "new" implementation would be fine? The alignment "only" matters until we move to the toolbar instead of the actionbar which I would have done already but had an unsolvable problem with handling the icon state for drawer/up/back so with 1.8 I simply went back to the (old) action bar. Whenever we move to the actionbar which I would strongly suggest we do then the drawer will hover above the bar and thus the alignment will be fine. Also using the toolbar has some more benefits like customizing and animation/hiding. But in order to do that I might then be in need of some support from @davivel since to me it seemed some event propagation during folder navigation messed of my toolbar icon state. |
| <!--android:layout_height="2dip"--> | ||
| <!--android:background="@color/list_item_lastmod_and_filesize_text" />--> | ||
| <TextView | ||
| android:layout_width="fill_parent" |
There was a problem hiding this comment.
Please, as a general rule, use "match_parent"; "fill_parent" is obsolete.
|
@tobiasKaminsky , I made some comments just in case. @AndyScherzinger , is this included in #1559, or makes it obsolete? |
|
#1559 renders this PR obsolete, but we should keep it until 1559 is merged and out in the wild (already in beta since end of last week) |
|
Sorry, I don't understand. Why should be keep this open if it's obsolete? |
|
We can close it but I would like to keep the branch itself for now just in case I need to peek for some of Tobias' code. This shouldn't happen, but you never know. |
|
Oh, that's no problem. Closing as subsumed/merged by #1559. Thanks, @tobiasKaminsky & @AndyScherzinger |
As wished in #1383