I want to implement SMS text counter like feature as in Android default messaging application. So that after each 161 character counter should be incremented by one and on deleting of character it should decrease.
Math.floor(chars / 160) + 1
This will divide the number of characters you have by the SMS-limit (160), cut off the decimal place and add "1".
http://www.java-examples.com/find-floor-value-number-using-math.floor
e.g. chars = 170, then (chars / 160) = 1,0625 and floor(1,0625) = 1, the result would be that 170 characters mean 2 SMS.
Something like:
int countSMS = (nbOfCharacters / 160) + 1;
Related
Today while i am coding in Android, i find out a bug in Android and couldnt find possible way to handle it.
Question is
int PERT = Math.round(100 * (Total - StokAdet) / Total);
Everything is pretty good but when Total is 12 and StokAdet is 10, then something magicly happens and result brings me 16.
Normally the result is 16.6666667 but when rounded it must become 17.
But it returns 16.
I hope to hear you. Thanks..
I'm guessing it's because you are doing an integer division here. So 100 * (Total - stokAdet) / Total is 16 already. Probably because Total and StokAdet are ints.
So if we evaluate it step by step as java would:
Total - StokAdet = 12 - 10 = 2
100 * (Total - StokAdet) = 100 * (12 - 10) = 200
100 * (Total - StokAdet) / Total = (100 * (12 - 10)) / 12 = 16
This last bit might seem odd because it should be 16.66666...7 by normal arithmetic right? Well because we are in Java and all of the numbers are integers the output will also be an integer. Integers can't represent the bit after the decimal point (the ".66666...7" bit). Now it might seem crude but what Java does is it just throws away the ".66666...7" bit so 16.66666...7 becomes just 16.
However if either the Total or StokAdet were float values then the calculation would give you your number as expected.
This is fine:
int PERT = Math.round(100 * (Total - StokAdet) / Total);
Just add this below
int i = Math.round(PERT);
Then i is the rounded number.
It's not a bug, it's a feature. H.Brooks answer shows how to get around it.
Why? You are are working in integers. And integers are not rounded up or down with division. They are cut off. In Java, int 1.9999999999999 is always going to be 1, not 2. So take a moment to pick the right variable for the right value.
Further reading: Division of integers in Java
I have a string containing the product details as paragraph, it is from my web service.So I want to display these paragraphs sentence by sentence staring with a bullet.for example
my response is like that
{"Product":"Dell XPS 13","Image":"http://dri1.img.digitalrivercontent.net/Storefront/Company/msintl/images/English/en-INTL-Dell-XPS-13-9343-2773SLV-i7-256GB-Silver-Androidized-CWF-01967/en-INTL-L-Dell-XPS-13-9343-2773SLV-i7-256GB-Silver-Androidized-CWF-01967-mnco.jpg","Description":"The XPS 13 isn't just the smallest 33cm (13) laptop on the planet1, it also has a virtually borderless infinity display.,Its Size 32 inch","Price":"68000","Quantity":"6"}
From its I take Description in to a String and then I want to display it in my Display activity page like below
.The XPS 13 isn't just the smallest 33cm (13) laptop on the planet1.
.it also has a virtually borderless infinity display.
.Its Size 32 inch
Please try as follows:
String sentence;
String text = "The XPS 13 isn't just the smallest 33cm (13) laptop on the planet1, it also has a virtually borderless infinity display.";
BreakIterator bi = BreakIterator.getSentenceInstance();
bi.setText(text);
int index = 0;
while (bi.next() != BreakIterator.DONE) {
sentence = text.substring(index, bi.current());
System.out.println("Your"+" ." + sentence);
index = bi.current();
}
I'm using the library of #LeffelMania : https://github.com/LeffelMania/android-midi-lib
I'm musician but I've always recorded as studio recordings, not MIDI, so I don't understand some things.
The thing I want to understand is this piece of code:
// 2. Add events to the tracks
// Track 0 is the tempo map
TimeSignature ts = new TimeSignature();
ts.setTimeSignature(4, 4, TimeSignature.DEFAULT_METER, TimeSignature.DEFAULT_DIVISION);
Tempo tempo = new Tempo();
tempo.setBpm(228);
tempoTrack.insertEvent(ts);
tempoTrack.insertEvent(tempo);
// Track 1 will have some notes in it
final int NOTE_COUNT = 80;
for(int i = 0; i < NOTE_COUNT; i++)
{
int channel = 0;
int pitch = 1 + i;
int velocity = 100;
long tick = i * 480;
long duration = 120;
noteTrack.insertNote(channel, pitch, velocity, tick, duration);
}
Ok, I have 228 Beats per minute, and I know that I have to insert the note after the previous note. What I don't understand is the duration.. is it in milliseconds? it doesn't have sense if I keep the duration = 120 and I set my BPM to 60 for example. Neither I understand the velocity
MY SCOPE
I want to insert notes of X pitch with Y duration.
Could anyone give me some clue?
The way MIDI files are designed, notes are in terms of musical length, not time. So when you insert a note, its duration is a number of ticks, not a number of seconds. By default, there are 480 ticks per quarter note. So that code snippet is inserting 80 sixteenth notes since there are four sixteenths per quarter and 480 / 4 = 120. If you change the tempo, they will still be sixteenth notes, just played at a different speed.
If you think of playing a key on a piano, the velocity parameter is the speed at which the key is struck. The valid values are 1 to 127. A velocity of 0 means to stop playing the note. Typically a higher velocity means a louder note, but really it can control any parameter the MIDI instrument allows it to control.
A note in a MIDI file consists of two events: a Note On and a Note Off. If you look at the insertNote code you'll see that it is inserting two events into the track. The first is a Note On command at time tick with the specified velocity. The second is a Note On command at time tick + duration with a velocity of 0.
Pitch values also run from 0 to 127. If you do a Google search for "MIDI pitch numbers" you'll get dozens of hits showing you how pitch number relates to note and frequency.
There is a nice description of timing in MIDI files here. Here's an excerpt in case the link dies:
In a standard MIDI file, there’s information in the file header about “ticks per quarter note”, a.k.a. “parts per quarter” (or “PPQ”). For the purpose of this discussion, we’ll consider “beat” and “quarter note” to be synonymous, so you can think of a “tick” as a fraction of a beat. The PPQ is stated in the last word of information (the last two bytes) of the header chunk that appears at the beginning of the file. The PPQ could be a low number such as 24 or 96, which is often sufficient resolution for simple music, or it could be a larger number such as 480 for higher resolution, or even something like 500 or 1000 if one prefers to refer to time in milliseconds.
What the PPQ means in terms of absolute time depends on the designated tempo. By default, the time signature is 4/4 and the tempo is 120 beats per minute. That can be changed, however, by a “meta event” that specifies a different tempo. (You can read about the Set Tempo meta event message in the file format description document.) The tempo is expressed as a 24-bit number that designates microseconds per quarter-note. That’s kind of upside-down from the way we normally express tempo, but it has some advantages. So, for example, a tempo of 100 bpm would be 600000 microseconds per quarter note, so the MIDI meta event for expressing that would be FF 51 03 09 27 C0 (the last three bytes are the Hex for 600000). The meta event would be preceded by a delta time, just like any other MIDI message in the file, so a change of tempo can occur anywhere in the music.
Delta times are always expressed as a variable-length quantity, the format of which is explained in the document. For example, if the PPQ is 480 (standard in most MIDI sequencing software), a delta time of a dotted quarter note (720 ticks) would be expressed by the two bytes 82 D0 (hexadecimal).
This question already has answers here:
Understanding colors on Android (six characters)
(10 answers)
Closed 6 years ago.
I'm working on implementing a widget transparency option for my app widget although I'm having some trouble getting the hex color values right. Being completely new to hex color transparency I searched around a bit although I couldn't find a specific answer to my question.
I want to set transparency by hex color so let's say my hex color id "#33b5e5" and I want it to be 50% transparent. Then I'll use "#8033b5e5" because 80 is 50%.
I found a useful chart here: http://www.dtp-aus.com/hexadeci.htm . With this data I managed to come up with this:
0% = #00
10% = #16
20% = #32
30% = #48
40% = #64
50% = #80
60% = #96
70% = #112
80% = #128
90% = #144
Now the issues start appearing when I get higher than 100 in hex. Hex color codes can only be 8 symbols long right? For example #11233b5e5 (80%) crashes.
What can I do to enable me to use the higher numbers aswell?
Here's a correct table of percentages to hex values for opacity. E.g. for 50% white you'd use #80FFFFFF. To think in terms of transparency instead, flip the order of the percentages (more opaque = less transparent).
%
Hex
100%
FF
95%
F2
90%
E6
85%
D9
80%
CC
75%
BF
70%
B3
65%
A6
60%
99
55%
8C
50%
80
45%
73
40%
66
35%
59
30%
4D
25%
40
20%
33
15%
26
10%
1A
5%
0D
0%
00
(source question)
Short answer: full table of percentages
You can see the full table of percentages to hex values and run the code in this playground in https://play.golang.org/p/l1JaPYFzDkI .
Ok the table tells the results not how to find the results. The next parts explain how you can calculate yourself.
Short explanation in pseudocode
Percentage to hex values
decimal = percentage * 255 / 100 . ex : decimal = 50*255/100 = 127.5
convert decimal to hexadecimal value . ex: 127.5 in decimal = 7*16ˆ1 + 15 = 7F in hexadecimal
Hex values to percentage
convert the hexaxdecimal value to decimal. ex: D6 = 13*16ˆ1 + 6 = 214
percentage = (value in decimal ) * 100 / 255. ex : 214 *100/255 = 84%
More infos for the conversion decimal <=> hexadecimal
Long answer: how to calculate in your head
The problem can be solved generically by a cross multiplication.
We have a percentage (ranging from 0 to 100 ) and another number (ranging from 0 to 255) then converted to hexadecimal.
100 <==> 255 (FF in hexadecimal)
0 <==> 0 (00 in hexadecimal)
For 1%
1 * 255 / 100 = 2,5
2,5 in hexa is 2 if you round it down.
For 2%
2 * 255 / 100 = 5
5 in hexa is 5 .
The table in the best answer gives the percentage by step of 5%.
How to calculate the numbers between in your head ? Due to the 2.5 increment, add 2 to the first and 3 to the next
95% — F2 // start
96% — F4 // add 2 to F2
97% — F7 // add 3 . Or F2 + 5 = F7
98% — F9 // add 2
99% — FC // add 3. 9 + 3 = 12 in hexa : C
100% — FF // add 2
I prefer to teach how to find the solution rather than showing an answer table you don't know where the results come from.
Give a man a fish and you feed him for a day; teach a man to fish and
you feed him for a lifetime
Color hexadecimal notation is like following: #AARRGGBB
A : alpha
R : red
G : green
B : blue
You should first look at how hexadecimal works. You can write at most FF.
I built this small helper method for an android app, may come of use:
/**
* #param originalColor color, without alpha
* #param alpha from 0.0 to 1.0
* #return
*/
public static String addAlpha(String originalColor, double alpha) {
long alphaFixed = Math.round(alpha * 255);
String alphaHex = Long.toHexString(alphaFixed);
if (alphaHex.length() == 1) {
alphaHex = "0" + alphaHex;
}
originalColor = originalColor.replace("#", "#" + alphaHex);
return originalColor;
}
That chart is not showing percents. "#90" is not "90%".
That chart shows the hexadecimal to decimal conversion. The hex number 90 (typically represented as 0x90) is equivalent to the decimal number 144.
Hexadecimal numbers are base-16, so each digit is a value between 0 and F. The maximum value for a two byte hex value (such as the transparency of a color) is 0xFF, or 255 in decimal. Thus 100% is 0xFF.
try this on google search (or click here)
255 * .2 to hex
it will generate 0x33 as a result.
However, google does not round off values so you can only use 1-digit multipliers. if you want to use say .85, you have to get the rounded-off value of 255 * .85 first, then type (rounded-value here) to hex in google search.
I realize this is an old question, but I came across it when doing something similar.
Using SASS, you have a very elegant way to convert RGBA to hex ARGB: ie-hex-str. I've used it here in a mixin.
#mixin ie8-rgba ($r, $g, $b, $a){
$rgba: rgba($r, $g, $b, $a);
$ie8-rgba: ie-hex-str($rgba);
.lt-ie9 &{
background-color: transparent;
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#{$ie8-rgba}', endColorstr='#{$ie8-rgba}');
}
}
.transparent{
#include ie8-rgba(88,153,131,.8);
background-color: rgba(88,153,131,.8);
}
outputs:
.transparent {
background-color: rgba(88, 153, 131, 0.8);
}
.lt-ie9 .transparent {
background-color: transparent;
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#CC589983', endColorstr='#CC589983');
zoom: 1;
}
I always keep coming here to check for int/hex alpha value. So, I end up creating a simple method in my java utils class. This method will convert the percentage of transparency to hex value and append to the color code string value.
public static String setColorAlpha(int percentage, String colorCode){
double decValue = ((double)percentage / 100) * 255;
String rawHexColor = colorCode.replace("#","");
StringBuilder str = new StringBuilder(rawHexColor);
if(Integer.toHexString((int)decValue).length() == 1)
str.insert(0, "#0" + Integer.toHexString((int)decValue));
else
str.insert(0, "#" + Integer.toHexString((int)decValue));
return str.toString();
}
So, Utils.setColorAlpha(30, "#000000") will give you #4c000000
How to convert WiFi level (i.e. -45 , -88 ) in to percentage ?
I want to convert WiFi level in % . I get WiFi level using level ( in dBm format)
I try lot of google but not get proper ans
Problem with this is that is very dependent on the receiving antenna. Some antennas register no useable signal at -90 dBm, some already at -80. You will have a hard time finding 0% (100% strictly being 0dBm).
I have created a Wifi scanner application where I use -100dBm as 0% and 0dBm as 100%, in Java it turns into something like this (MIN_DBM being -100):
public int getPowerPercentage(int power) {
int i = 0;
if (power <= MIN_DBM) {
i = 0;
} else {
i = 100 + power;
}
return i;
}
This is what Microsoft does for dBm <> percent conversion:
https://stackoverflow.com/a/15798024/2096041
Basically -50 .. 0 dBm maps linear to 100 .. 0 %.
Like MS, i would prefer to sit on the safe side and not use -100 as 100% as some answers here suggest.
The WifiManager class has a function calculateSignalLevel, but as it states here, it results in an error if numLevels is greater than 45. Possible workaround could be something like this:
double percentage = WifiManager.calculateSignalLevel(int rssi, 40) * 2.5;
but of course, this will be in steps of 2.5 percents - I don't know your use case but maybe this is sufficient.
As others have stated, calculating percentages is problematic, and there's no simple precise solution for that.
You could derive the percentage from the signal-to-noise ratio, rather than the signal intensity alone, if this information is available. This is probably the desired metric.
An android.net.wifi.ScanResult does not publish the neccessary information (as of Dec 2012), but you might be able to get this information through other means.
Signal = Noise => unusable signal, so you could set 0dB SnR = 0%. Also you could set 10dB SnR to 90% (90% of the signal power is not drowned out in noise), and 100% = no noise at all. More generally,
p = 100% * (1 - 10^(SnR / (10dB)))