We Keep Coding

How to make shown colors independent of phone's android dark/light theme?

I need an app that shows exact colors on each device disregarding what Android theme (dark / white) is on that device set.
So I put constraint layouts (same goes in fact for image view and probably other components as well) and make it programmatically set to a particular color, set by a hexa number (tried both 8-digit numbers and 6-digit numbers - dropping the FFs).
I expected that since the color was exactly defind by hexa, the app would show the exact color I needed.
Instead, the app is showing colors similar to what I wanted, but changed. For example - same code with color set on white (#FFFFFFFF or #FFFFFF) is shown as white when I run app on light Android theme, but as grey when I run on a phone set in dark theme mode. The same goes for all the colors - they are all slightly modified by the Android theme.
I set my colors, as follows (app is in Java):
layoutEmptyColor.setBackgroundColor(Color.parseColor(strDesc4)); //i.e. strDesc4 = "#7FFFD4"
Could somebody please let me know, how and where to set my app so that colors shown in it would be independent on Android theme set on the particular phone?
I'm not sure what other code snippets I should put here since I don't have a clue where I should look to solve this problem.

Change color of paper text on a photo. (Bitmap)

I'm developing an Android application. I have photos of a white paper which has some text written on it.
Background is always whitish color.(Color of paper). Text color is always dark grayish. I have these photos on a bitmap format.
What I want to do is changing colors of these bitmaps so text color will become pure black and background will become pure white.
I have some sample code but it's slow and it's not working well if there is a soft-medium shadow on a paper.
What is the fastest and reliable way to do this? I don't want to paint soft-medium shadows to black.

I can offer opencv functions that best fit your need, but I think you should implement it on your backend and use it with restful APIs.
Thresholding will do the job perfectly.You should just set the parameters right.
OpenCV supports a wide variety of programming languages such as C++, Python, Java, etc., and is available on different platforms including Windows, Linux, OS X, Android, and iOS.
You can find your way with its documentation on android.

How can we increase or decrease intensity of flash light android? [duplicate]

Is there a way to set the LED intensity that I desire? I know that to turn on the LED I use:
p.setFlashMode(Camera.Parameters.FLASH_MODE_TORCH);
mycam.setParameters(p);
But this code just turns on the LED. But is there a way to set different intensities to the LED for a stronger light or to reduce the light intensity?

HTC has an alternative API that supports this, however it's only on HTC Sense devices, and as of Gingerbread they've changed the permissions so it's only for their Flashlight app, not third party ones (unless you use root).
But on 2.2 HTC devices you can use it by writing a string to /sys/devices/platform/flashlight.0/leds/flashlight/brightness. This controls if the LED is on and how bright it is. For maximum brightness write "128\n", half brightness write "64\n". Easy to test from adb shell:
echo "128" > /sys/devices/platform/flashlight.0/leds/flashlight/brightness
And finally turn it off by writing "0\n" there.

Short answer is: NO.
Longer answer - maybe on some devices using undocumenterd calls / parameters.
Supported flash modes, and their meanings (and behaviours) differ from device to device.
Your best option is to query supported flash modes, and hope they work as intented.

Try to set different Flash Modes available for Camera parameters.
* FLASH_MODE_OFF
* FLASH_MODE_AUTO
* FLASH_MODE_ON
* FLASH_MODE_RED_EYE
* FLASH_MODE_TORCH
you can set Flash mode using setFlashMode() method.
This was just for camera back light. but if you want to change complete screen intensity. have a look at the example here.

Try to find the code of this function:
private native final void native_setParameters(String params);
I beleive that you will find out if this is possible when you look through it.
Looking at the publics, it seems impossible

I have tried this in my Samsung Galaxy S3 Mini. I have not tried on other devices.
Whenever i do this (while the led is ON):
public void changeIntensity()
{
cam.stopPreview();
cam.startPreview();
}
The LED rotates between 3 levels of intensity. It makes no sense, but it works.

App widget inconsistent sizing between tablet and phone

I am attempting to design an app which reproduces the shortcut styles of the standard app shortcut home screen icons but as a widget. Note, this is currently just looking at the standard Android homescreen.
I have made the following observations using the "Dump View Hierarchy for UI Automator" tool in the DDMS -> Devices view of Eclipse:
The space given in the 1 x 1 square changes depending on screen density, orientation and whether the phone home screen is in "phone mode" or "tablet mode" (start a 4.x emulator and you can tell by the background amongst other things). Screen density effects the size as expected (0.75, 1, 1.5, 2.0 density factor scaling), but the orientation and 'home screen mode' are quite unpredictable. Specifically:
DIMENSIONS FOR A 1x1 'SQUARE' ON THE HOMESCREEN
Phone mode:
Portrait: 80dp x 100dp = 4:5 aspect ratio
Landscape (if available - not thoroughly tested): 106dp x 74dp = 53:37 aspect ratio
Tablet mode:
Portrait: 96dp x 96dp = 1:1 aspect ratio
Landscape: 96dp x 96dp = 1:1 aspect ratio
As you can see, there is barely any consistency whatsoever, but these are the dimensions given to a 'square' on the home screen. It gets even worse when looking at the space actually given to widgets (yes, it does differ from the square space available and used by the system shortcut widgets):
DIMENSIONS GIVE TO A WIDGET IN A 1x1 'SQUARE'
Phone mode:
Portrait: 80dp x 100dp = 4:5 aspect ratio
Landscape (if available - not thoroughly tested): 90dp x 58dp = 45:29 aspect ratio
Tablet mode:
Portrait: 72dp x 72dp = 1:1 aspect ratio
Landscape: 72dp x 72dp = 1:1 aspect ratio
So I'm stuck with:
Inconsistent aspect ratios between phone and tablet modes
Smaller areas given for an app widget then that of an app shortcut in some cases. Consequently, the relative and perceived size of widgets will look very different on a tablet vs phone?
The smaller areas aren't even vertically centred, they are mostly top aligned with a 2dp top margin which means they don't even look aligned with a neighbouring application shortcut to start with, let alone when trying to produce a similar looking shortcut through a widget
To visualise, the following images show a default system shortcut (with a red box surrounding showing the 'square dimensions - which both system shortcuts and widgets always share). Next to it is my widget with the blue highlight showing the bounds of a MATCH_PARENT setup, hence where the widget can actually draw within its 'square':
Phone - Port:
Tablet - Land:
Tablet - Port:
Most important to take from here, is the blue area of the widgets on a tablet does not even include the space where the system shortcut draws its text?
Does anyone have insights into:
Why the home screen is so inconsistent?
Why app widgets are not given the same drawing space as that of a system shortcut / or should it be and I am doing something wrong?
Should I be doing something else, or is it just accepted that for a 1x1 widget which takes up all its given drawing space, it will look 'smaller' (compared to its surroundings) on a tablet than it would on a phone?

And even better, many launchers allow the user to customize the size of their grid. Per the design guidelines for App Widgets, you cannot rely on an exact size on all devices. Instead, determine a minimum width and height and let the home screen determine how many squares the layout takes up.
They do provide some guidance on what you can expect for the minimum size of a cell (and all your numbers are much larger than that it seems), but again custom launchers may reduce this minimum even lower.
I find it best to focus on what components need to be in your layout (buttons, etc) and then follow the Metrics and Grids design guidelines to determine your minimal size (noting the margins are automatically added on Android 4.0+ devices but not on <4.0 devices). Then make sure your layouts are dynamic enough to fill in the space provided to them (centering text, etc as appropriate). Remember widgets are assumed to be a framed, single entry, rather than floating text as noted on the App Widget Design guidelines.

Hey you can manage the scree sizes in layouts you want to create different layouts for different screen sizes and also for landscape and portrait .
create the following layouts in your resource folder like this :
layout-large
layout-small
layout-xlarge
layout-landscape
And then copy your XML files in to it and check in preview screens for different devices you can have a idea based on that you can modify the size of the widgets in your homescreen.

Best practices to use when targeting multiple screen resolutions on Android

When designing an UI, we need to target many android mutations and various screen resolutions.
How to differentiate layout for 480 * 800 and 480 * 854 screen resolutions in android?
how to layout support for various screen in android?
Both questions above recommend to use different Layout code for different screens. Is it really necessary?
http://developer.android.com/guide/practices/screens_support.html
recommends to
Provide different layouts for different screen sizes
Provide different bitmap drawables for different screen densities
But I still think, we can support multiple screens without creating standalone layout for each screen resolution. Or am I wrong?
I know, and I do use, 9-patch for scalable background images (or form inputs, and so on)
and I do use dp (density pixel) to declare sizes relatively to screen density
But what are next best practices ?

I think the answer to this has changed recently, but I'll go over historical solutions.
Pre-Honeycomb, the solution was to create a dynamic layout that could adjust itself to the size of the screen (using 9-patches, dips, layouts that expand/shrink, etc.). This meant that none of your Views could be "pixel perfect", but you could adjust to different aspect ratios that you encounter. Sometimes you would come up with different layouts for landscape and portrait, but beyond that customization wasn't necessary.
With the release of Honeycomb, the problem got a lot more complex. Now you've got dramatically different screen sizes, where your app stretching doesn't look good at all. You've got tablets that stretch from 7" to 10" - which one is "large" vs. "xlarge"? 3.0 and 3.1 were an awkward period, where you had to detect the API version/screen size and configure your app accordingly (supposing your app supports both phones and tablets).
However, everything's changed in 3.2 and beyond. Now, the best practice can be described thus: think like a web designer, not an Android designer. Instead of thinking about phone vs. tablet vs. landscape vs. portrait layouts, think instead of layouts that work on particular screen sizes.
This thought process is detailed by this blog post, and these slides, but I think it's best demonstrated by going to some sample web pages and seeing it in action. Try visiting this page (or this page, or this page) and changing the size of your browser. Notice how they dynamically change layout based on the width - this is what you want in Android as well.
So now you've got a layout that works between screen width 150dp and 400dp; another one that works between 401dp and 800dp; a third that handles 800dp and 1000dp, etc. This way of thinking does not end up with you, as a developer, doing too much more work than before - instead of defining a phone layout, a tablet layout (each with a portrait/landscape layout), you just define a few layouts that work with different widths.
Right now we're in an awkward transitional stage as most people don't have devices that support this practice. So "best practice" is essentially all of the above. In a few years, when everyone's got ICS and beyond, then we can all breath a sigh of relief.
(I apologize if you were looking for specific solutions; this answer ended up being relatively theoretical rather than having concrete answers, mostly because I felt the question was pretty open-ended. If you've got a specific problem you want to solve, I can try to address that elsewhere.)

If you build your views using "dp" it would, basically, be the same size for eack screen size.
In most cases you will prefer that your view will resize itself proportional to the screen size.
Of course, in most cases you will need to build separate layouts for tablets.
But, besides I can recommend you to do the next steps:
1. Add this library to your project.
2. Now in your layout you can write views like that:
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="I'm scalable!"
android:textSize="#dimen/_12sdp"/>
In this example your TextView will scale on each screen size.

These are some suggestions, in random order:
Avoid AbsoluteLayout, I know that it is deprecated, but you can still use it; forget it and use LinearLayout and RelativeLayout instead
Use 9-patch to create buttons and backgrounds, so that they will appear the same for each resolution
Use DisplayMetrics() to get informations about the screen, to show different things in different screens (i.e. to show AdMob "Banner" in smartphones and AdMob "Leaderboard" in tablets)
Create WVGA layout first (this is only a personal opinion, but I've found it a nice way of working): as far as I know the most smartphones are WVGA or at least HVGA (QVGA is not so frequent), so creating a perfect WVGA layout will make you able to satisfy lots of phones, than you can create a different layout for lpdi-screen and tablets (that are a market-share minority too, at the moment)
In conclusion I recommend you to create a layout for phones and on for tablets, that can adjust itself to screen resolution: this will fit the most devices; for borderline devices (i.e. 7" tablets or 5.3" phone) I'd work with different drawables/different XML layouts.

I would suggest as much as possible use Relative calculations rather than Absolute. Avoid Hard coding of numbers for padding, margins etc. Simply give them a value in relation to desired property like Width, height of screen or any component.