I have been developing an app over the past few months getting ready for publication. Everything was looking just perfect. I was doing a few things with text in buttons - using my own 9-patch button backgrounds, changing the default font, repositioning textbuttons with setX() and setY() etc. I had some big buttons and smaller ones. Some were a tight fit amongst other objects on the screen, but it all worked, the buttons looked perfect on a variety of tablets and phones.
Then I remembered one last thing on my todo list which wast to change the android:minSdkVersion in my manifest from 8 up to 11. I needed to do this because the setX and setY methods are only available on android 3.0 and higher. But as soon as I did this, the text within my buttons was all screwed up. For a start it was white instead of black - easily fixed. But also the padding round the text was completely different. Buttons were now overlapping each other and looking unbalanced in a variety of ways.
So my question now is this: Is there any way to say "this software must only run on Android 3.0 (api 11) and above" AND "let all the text button characteristics be set to whatever that were with api level 8".
I have no idea why such things would happen - but it's better to just support the older platforms if you can help it. For example, if the only thing keeping you from using API 8+ is the setX() and setY() methods, you can use ViewHelper in the NineOldAndroids project to do this and support the lower API. For example:
ViewHelper.setX(myView, myXValue);
ViewHelper.setY(myView, myYValue);
Related
I recently found out that TextViews on Android are shown blurry / fuzzy when they are scaled in the 1.0-1.49 range.
I am not sure why this is happening, but it looks like a raster version of the unscaled version is used when the view is scaled on the XY axis in this range. However, the problem disappears if the view is scaled with a value above 1.5 (150%). Please check the attached screenshot collage in full resolution: https://i.imgur.com/A31ZC1N.png
The attached screenshots are from a real device, running Android 7.1.2 (API Level 25).
I have also tested this on an emulator running Android 9 (API Level 28), the results are identical. However, on my other device (OnePlus 6, Android 9), this issue is not present, everything scales nicely, without fuzziness.
A workaround for me was disabling HW acceleration on the current activity:
<activity android:hardwareAccelerated="false" />
Another workaround was setting a software layer on the parent of the view that is being scaled:
((View) mScaleValueTextView.getParent()).setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Both of these will result in the TextView being scaled without the mentioned issue, but these methods have drawbacks, the first one that I noticed was that TextView's shadow caused by the elevation property was not drawn.
In order to demonstrate the default behavior, I created sample app where I added a TextView and a SeekBar that controls the scale, ranging from 100% to 200%.
The view is scaled by this method:
private void scaleView(View v, float scaleValue) {
v.setScaleX(scaleValue);
v.setScaleY(scaleValue);
}
You can get the entire sample app here.
Since the same code behaves differently across devices and the issue is occurring just between the mentioned scale range, I assume this is the result of a lower-level performance optimization that may or may not be implemented on some devices.
Is there any way to disable or work around this in a clean manner, without unwanted side effects?
I have requirement that , In my application I have an image that occupy the full screen,after 5 second it will slowly slide up upto 50% of the screen and stay there. Remaining 50% screen occupy another image same like it slide up from bottom to below of first image.
How I can do it?
You can start here.
There is a lot to learn on Android Animation and Graphics.
you need to use the animations API of android.
however, since the handling of animations has changed between pre-honeycomb and honeycomb, you need to decide which android versions are supported on your app.
if you have the minSdk to 11 or above, you can use the new API .
otherwise you can use the old API . you can also use the NineOldAndroids library that mimics the way the new API works, using the old API.
for both, you can look at the API demos of google (or the library i've mentioned).
so, for making the animation you've mentioned, you can use the ScaleAnimation (old API) and use the screen width as the parameters for before and after .
In an app I'm developing, I need to layout 2 to 5 buttons as if on the edge of a circle. The app starts with 5 buttons, but buttons gradually disappear (based on user input) until there are 2 of them.
I thought I would use an AbsoluteLayout control, and set the position of each button in code (taking into account the screen size). However, it says more or less everywhere that AbsoluteLayout should not be used. Since I'm targeting this app to Android 2.2 and up, I can't use the fancier layouts introduced with ICS.
I know I can use a RelativeLayout and play with the margins, but this seems less intuitive, and just as error prone, as using AbsoluteLayout.
Do I have any reasonable alternative?
I think, you dont have many alternatives. Except relative layout you mentioned, you could of course use FrameLayout and set left and bottom margin to position your buttons correctly.
I have realized that there are at least two background colors on Option menu of Android. On the HTC Hero, the background is white and on Samsung Galaxy S II, the background is black.
This became a problem when I set the icons for the background menus. Is there some way to detect the background color of the Option menus in Android?
Possible solutions:
Don't use icons.
Design icons according to the guidelines - http://developer.android.com/guide/practices/ui_guidelines/icon_design_menu.html. There are three different guidelines for up to 2.2 (white background), 2.3 (black background) and 3.0+, so it's a lot of work...
As Profete162 suggested, use #android:drawable/ic_menu_*
For Android 4.0+, you can also set the light / dark Holo theme, which is guaranteed (at least in theory) to remain unchanged across different phone manufacturers - so it'll look the same in HTC Sense, Samsung TouchWiz etc.
That's indeed a very annoying issue.
On my implementation, I always try to use standards icons from android.R.drawable.IC_menu_*, so I am sure these icons are part of the framework and users are always positively surprised to see their generic icons in my app!
That gives a really good continuity in the user experience on the device, but that doesn't answer your question, but at least provide a workaround.
Here are for instance all android 2.2 icons: http://androiddrawableexplorer.appspot.com/
You can trust me, using these icons will always fit your colors.
First of all to answer your title question:
You can reference and read the background of the options menu by reading the attributes of the current theme. The attribute for this is panelFullBackground. E.g. set it as the background of a textview in XML¹:
<TextView android:background="?android:attr/panelFullBackground"
... />
Note that the background seems to be a solid color, but it's not - it's actually a bitmap. If you look closely you can see a grey border at the top (android 2.3+), or a drop shadow (<= android 2.2), so its'a bit difficult. Luckily there is a different attribute called panelColorBackground which matches the background color of the drawable as close as possible. So if you want just the normal background color, use this instead.
¹ This can surely also be read from code, but I don't know how from the top of my head at the moment, maybe I'll look it up and edit it in later.
Regarding icons
So you have the color as stated above, but you still have to process it to know if it's a dark or a bright color. You can do that, but that's not the usual way to deal with these icons and probably a good bit of work until you cover all the possible cases - not to mention that you have to create icons for each variant.
Normally you should adopt the platform menu icon style. This works across all devices and looks familiar to your users (custom icons that dont follow this often look "wrong" - e.g. astro file manager does this I believe).
You can do that by hand (see the guidelines), but the way better alternative is the Android Asset Studio.
It comes in two flavors:
As a webapp
Integrated in the latest version of the ADT plugin for eclipse
(under File->New->Other->Android Icon Set)
The workflow for both is pretty similar, select the point "Menu Icon" and follow the wizard. It will promt you to enter a simple, black and white bitmap of your desired icon that just outlines it's shape. After you specified one, the asset studio will generate everything for you. Play a bit around with the "clipart" option, that has a few example bitmaps ready to see how it works. When finished, the webapp gives you a simple zip which can be extracted into your project directory, the eclipse version adds it directly to the project that you select in the wizard.
The background color can be anything, because its implemented in Framework by manufacturer. You can't read it, in fact you will never need to read it.
Just create your custom menu layout in res/menu folder, set style and use it.
I am developing my first Android application. I have created a relativelayout with two buttons and one autocomplete text view. The three controls display correctly on the emulator. However, when I create the apk file and install it on my Samsung Galaxy 5, the buttons show jagged edges, and the top and bottom lines 'sink' a bit and the text view gets an appearance of rounded square brackets on either side with horizontal edges sunk by a half millimeter or so.
Any help in understanding what is happening and how to fix it is highly appreciated.
I'm guessing that Samsung is using their own theme in your app. You can override this theme by making one yourself.
This will help you: http://developer.android.com/guide/topics/ui/themes.html
I think I got the answer. It was perhaps because I had not defined Minimum SDK version and target SDK version in the manifest (uses-sdk node).
Adding the following two attributes to the uses-sdk node in manifest file solved the issue. I hope this is what was really necessary.
android:minSdkVersion="7"
android:targetSdkVersion="7"