-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to use the same Drawer object in different activities? #1385
Comments
@acosti if you can not use one activity with fragments (which is definitely the correct implementation) you will have to go a different approach. There is definitely NO chance to have the drawer static. What you can do is to have a helper class which creates the drawer for you (with the same logic) and you just call this helper in all your activities. But the drawer |
Ok, so my question would be: The rational stems from the fact that it is not cheap for me to create the drawer, as it is highly customized and interacts with various other components of the app. So recreating it each time from scratch would be suicidal in terms of performance. |
@acosti yes that's possible. You can keep the |
Ok mike, thanks. Appreciate the help. |
excuse me Mike but it does not seem to work. I am getting an explicit runtime error: |
@acosti oh I forgot about this behavior as I had to prevent people calling The easiest solution would be that you just keep the "expensive" information global and just rebuild the drawer as normal. I assume getting the items is expensive for you so just keep those items globally or so? |
yeah I guess that's the sane solution for my crazy problem. either way, thanks for the swift responses. your library has saved me tons of time. |
@acosti you could do a pull request and add a method this would then allow you to do this. And it will still prevent reusing the |
@acosti created a new version v5.3.5 which allows this. |
Hello, I have tried to use the .reset() method you supplied but I'm facing issues.
What I did was:
And then it crashed. |
@acosti I think this may be related to the Can you try to also call |
Holy shit that was fast. Thanks man, really. Same result unfortunately. Let me paste the whole log here.
|
@acosti hmm it fails here: https://github.com/mikepenz/MaterialDrawer/blob/develop/library/src/main/java/com/mikepenz/materialdrawer/DrawerBuilder.java#L1629 Weird enough as this one is inflated newly during are you sure you called it? |
I'm sure. Here's the process:
|
could you please send this steps as sample so I can debug it? thanks |
hmm that's gonna be a bit tough. let me try to pull something together for you to see. |
Ok, this will be tricky. Please bear with me and I'll be glad to respond to any question ASAP. Each activity that contains a Drawer uses the following code: private void initDrawerForActivity(Context activityContext)
{
// Get the activity
AgombiNavActivity activity = (AgombiNavActivity) activityContext;
if (sSharedDrawer == null) {
sSharedDrawer =generateDrawer(activityContext);
}
else {
sSharedDrawer.reset();
}
sSharedDrawer.withActivity(activity)
.withDrawerLayout(-1);
} The drawer generation code of private DrawerBuilder generateDrawer(Context context) {
// Get the menu items
RealmResults<AgombiComponentRealm> menuItems =
NavigationManager.getInstance().getMenu();
List<IDrawerItem> drawerItems = new LinkedList<>();
for (final AgombiComponentRealm menuItem : menuItems) {
// Get the drawer item externally
PrimaryDrawerItem item =
AgombiViewLoader.getInstance().initializeMenuItem(context, menuItem);
drawerItems.add(item);
}
// Get the footer externally
ViewGroup footer = AgombiViewLoader.getInstance().initializeDrawerFooter(context);
DrawerBuilder drawerBuilder = new DrawerBuilder()
.withTranslucentStatusBar(false)
.withDelayDrawerClickEvent(300)
.withDrawerItems(drawerItems)
.withFooter(footer)
.withFooterDivider(false);
// TODO: turn footer to sticky (removing its divider as sticky doesn't work - attempt to solve)
return drawerBuilder;
} Now, the activity calls for the build function. But it isn't so simple. public void injectView(ViewGroup activityLayout) {
Drawer projectedDrawer = null;
Toolbar potentialToolbar = getToolbar();
// Check whether a toolbar is required. If so, build a combined Drawer + Toolbar
if (potentialToolbar == null)
{
projectedDrawer = sSharedDrawer.build();
}
else
{
projectedDrawer = BuildDrawerWithToolbar(sSharedDrawer, activityLayout, getToolbar());
}
} And the following is the extra code that builds the Drawer given a Toolbar... private Drawer BuildDrawerWithToolbar(DrawerBuilder drawerBuilder, ViewGroup activityLayout, Toolbar optionalToolbar) {
AttachToolbarToLayout(activityLayout, optionalToolbar);
// Create the drawer
return drawerBuilder
.withToolbar(optionalToolbar)
.withActionBarDrawerToggle(true)
.withActionBarDrawerToggleAnimated(true)
.build();
} Damn. Let me know if you can catch anything, Mike. |
Updated the formatting for easier access |
@mikepenz How would I use fragments to do this? I'm not that familiar with fragments. |
@acosti sorry for the late answer. It's quite complex the above. Perhaps posting a "zip" containing the simple sample code would be easier |
@caralin3 if you have one activity with fragments. Just use the listener and change out the fragments if the user selects a new one |
@mikepenz Do you have a link that can help me create a fragment? |
@caralin3 the official android documentation shows how to comit fragments to a container view just use the listener to detect selections of the user, and switch out the fragment |
hey @mikepenz, I'm trying a new approach: instead of redrawing the drawer anew on each activity, and instead of having the "1 activity - many fragments" implementation: I'll do 1 activity - many activities. So basically, same implementation I guess as you'd have with fragments except with activities and self-managed. My question is, how would you approach such solution? I was entertaining the idea of simply (I hope it's simple) overriding the drawer's layout in order to add the "content frame". from there it should be easy to do the layout inflation on setContentView's override. your thoughts? |
Soneone tried with Dagger2? |
@acosti I remember there was a library which did exactly this. Keeping one activity but filling it up with different views depending on the context. I am not quite sure if this is a good or the best approach. Android comes with a pretty good and feature rich concept of It is also rather simple to split things up into fragments, and to handle fragments and doing the switching with the |
Ok to finally close this issue. After some more digging and debugging and trying. It is not really possible to reuse the same The optimal solution for this usecase is to remember the complex data you have to fetch, and then just build the drawer with the items, based on the already loaded data. |
Hello,
I'm getting an error if I attempt to hold the Drawer object and display it more than once.
Is it possible, for performance considerations, to create exactly one (static) Drawer and use it in other activities?
I realize the best-practice would be doing one activity with fragments, but this is not the case.
Thanks
A Costi
The text was updated successfully, but these errors were encountered: