When I call the setContentView(myView) method in an AppCompatActivity, instead of setting it directly, it calls through to some sort of delegate which for some reason wraps it in some unneeded layouts. However, I need it to be a direct child of the decor view. I've already disabled the action bar and window title via theme, unfortunately that didn't help. If I do ((ViewGroup)getWindow().getDecorView()).addView(myView) the app crashes immediately on launch when said delegate tries to do something with its unneeded layouts and finds my view instead of them. The worst part is that such a behavior is absolutely undocumented, I found that out myself while debugging trying to understand why does the system disregard setFitsSystemWindows(true) on my root content view (which is a DrawerLayout).
Is there any way to completely disable this behavior? If no, is there any way to use the system Activity class while using the appcompat layout inflater in order to support per-view themes on pre-Lollipop?
I don't support anything older than ICS and I use toolbars inside fragments (without setting them as action bars) so I don't actually need any of appcompat's activity-related stuff in my app; the only reason to extend AppCompatActivity for me was its layout inflater.
Have you tried AppCompatDelegate? It's a helper that provides you with compat behavior without requiring you to extend AppCompatActivity. However, it may well apply same wrapping pattern to your layouts (haven't tried it myself), but anyway worth taking a look.
Related
In some view like AppCompatTextView we can read
This will automatically be used when you use EditText in your layouts
and the top-level activity / dialog is provided by appcompat. You
should only need to manually use this class when writing custom views.
But sometime not, like LinearLayoutCompat
So this means that we should use LinearLayoutCompat directly instead of LinearLayout ?
In case, which Compact Views is correct to use directly?
So this means that we should use LinearLayoutCompat directly instead
of LinearLayout ?
The answer is Yes.
which Compact Views is correct to use directly?
You should be able to use all the Compat views directly without any issue. AFAIK...They are built to provide more compatibility and they tend to be updated more frequently as almost all of them come from Support or AndroidX libraries which receive more frequent updates.
The inbox app features a navigation drawer. Upon clicking on any navigation drawer item a fragment is loaded (most probably) and during this transaction the app theme changes. Changing app theme requires setTheme() method to be called before setContentView(..) in the onCreate() method of the activity. The super fluid UI indicate the use of fragments so how is this achieved without recreating parent activity (otherwise there would have been a lag for sure).
The snooze fragment hase oragne like theme
The inbox fragment has blue like them
You can actually change the theme's style, but only before calling setContentView(#ResId int) method. Something like this perhaps?
getTheme().applyStyle(isDashUser ? R.style.redStatusBar : R.style.blackStatusBar, true);
setContentView(R.layout.my_activity);
If you look closely when changing the page there's a slight graduation between the two colours. This probably suggests they have a system separate from theming to re-colour all the UI elements.
One my apps has a very similar colour change feature, and I just have methods set up to manually re-apply the relevant colours to each UI element. Of course Google probably have some super slick way of doing it that they'll never share with anyone.
I'm trying to use the android:fitsSystemWindows attribute on a view so that it does not get blocked by my translucent navigation bar, but it's not doing anything. The Android documentation on it says fitsSystemWindows "Will only take effect if this view is in a non-embedded activity."
What is an embedded activity? Would it be possible for me to have accidentally created one? And is it possible to get the effect of fitsSystemWindows within one?
An embedded Activity is an Activity which is hosted inside a parent Activity. The common example being the TabHost/TabActivity design. In particular, embedded Acitvities reside in the host's LocalActivityManager, which is conceptually similar to the FragmentManager which allows you to display one Activity inside another.
Given this definition, it is easy to understand why only the host (non embedded) Activity can support the fitsSystemWindows attribute, as any embedded Activities are restricted to the area defined by their host.
It is very unlikely you will have accidentally created one.
See: android: using ActivityGroup to embed activities
I'm trying to do minor tweaks to the layout of items inside an ActionBar, and hitting a lot of problems. It would help if I knew (or even better: could override!) the layout which Android is using for the ActionBar itself.
(Android's layout system doesn't allow you to fully control layout of "items" direct from the item itself - all the options are enabled/disabled based on what type the parent/container layout has)
So, for instance...
try to make a custom ActionView that takes "all remaining space" (because you have no title / don't need a title)
...everything breaks. There are lots of workarounds, all of which have their own bugs (I've tried 3 from SO already, and they all break on different versions of Android / different handsets)
this would be TRIVIAL if I could set the ActionBar's layout to "RelativeLayout" and use "layout_toLeftOf" etc
...but the docs don't seem to answer this, nor do they provide a way of setting it. Any ideas? I don't want to have lots of hardcoded, broken code to workaround the API (because it'll make maintaining this app a nightmare :( )
Have you looked at ActionBarSherlock? It's a support library extension that implements action bar on all versions of Android using single API. Also, when it comes to layouts, I often find it very useful to look at the source code. You can find action bar layouts on the very top of the list here.
Load the view hierarchy and then you will be able to see the views that compose any layout.
http://developer.android.com/tools/debugging/debugging-ui.html
Ok, I am doing something. I have a navigation bar that contains all the buttons for my activities. I have tried the method of Extending the other activities to the "navbar" class.
Here is what I have done so far:
I have extended all the classes to navbar (Except those that will need multiple inheritance).
used an tag in every XML layout.
What I need:
I need classes to handle multiple inheritance
All my classes even those that do not need multiple inheritance, to extend my navbar class.
If multiple inheritance is not possible, I do not mind hardcoding those classes, but multiple inheritance would be very nice :)
thanks in advance.
Java does not support multiple inheritance, sorry.
Rather than roll your own "navbar", you might consider using the action bar on Honeycomb, perhaps then using ActionBarSherlock to support pre-Honeycomb devices from the same code base.
You could do what I did for my app.
Create a "base" activity that all other activities extend.
Fill your menu bar and set up all of the listeners with Intents in it, then allow each activity to handle everything else.
The other option would be to create a XML element with whatever you want in it (if it needs to be more complex than a menu for some reason). You should still use the "base" activity idea for this.
Hope this helps.