I need to send a USSD code containing a double value, that represents the balance account amount to be transferred. This value is composed by an integer number, and optionally a decimal separator and 2 more digits. My code looks as follows:
double doubleValue = 0.70;
String phoneNumber = "51234567", pincode = "1234";
String ast = Uri.encode("*");
String baseUssd = ast + "234" + ast + "1" + ast + phoneNumber + ast + pincode + ast;
StringBuilder builder = new StringBuilder();
builder.append(baseUssd);
builder.append(doubleValue); //i.e: 1.35, 0.80
builder.append(Uri.encode("#"));
Intent intent = new Intent(Intent.ACTION_CALL, Uri.parse("tel:" + builder.toString()));
startActivity(intent);
My phone treats the doubleValue as 135, 080, etc. ignoring the dot separator character. I hope the final code includes "dot", allowing send the decimal value. Someone solved this problem?
The Java code shown works fine of course assuming that doubleValue is a float or a double.
As suggested here the Intent is handled by OutgoingCallBroadcaster.processIntent() which processes the String given in the Intent by calling PhoneNumberUtils.convertKeypadLettersToDigits() and PhoneNumberUtils.stripSeparators().
The latter one strips everything except numbers, *, #, + and the WILD, WAIT and PAUSE symbols.
This is where your decimal separator is lost.
So either the separator should be escaped to a specific numerical value or substituted by one of the accepted symbols to actually leave your phone and reach the receiver.
Whoever is responsible for the receiving end can probably advice you on properly formatting your decimal number.
Thinking about the way the pinpad, which my bank sent me, works, you always have to enter the two digits after the decimal point and the formatting on the display deals with the position of the point.
So if i enter "1", it is interpreted as 0.01.
Similarly "1023" would be 10.23.
I think the same approach could work nicely for you.
So 1.23 is entered as "123" and 0.80 as "80"
I can't see a reference that limits the characters to 0-9#* but all the examples follow this format. However, your example starts *234, which seems to fit this rule in the specification
Case a) 1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where X=any number 0-4, Y=any number
0-9, then, optionally "* followed by any number of any characters", and concluding with # SEND:
This case is reserved for HPLMN use. When a serving network receives such a message from a
visiting subscriber, it shall pass the USSD message directly to the HPLMN. If it receives it from a
home subscriber, it is up to the network to decide whether to treat it locally or to pass it to the HLR
http://www.etsi.org/deliver/etsi_ts/100600_100699/100625/07.00.00_60/ts_100625v070000p.pdf
In general, I am not sure the HPLMN (Home Public Land Mobile Network) or HLR (Home Location Register) would expect the extra characters, even though the whole character set and even other character sets are allowed in the USSD protocol.
Related
I'm developing sms APP and want to receive sms from the specific numbers. But number can be changed sometime with country code as +923201234567 or sometime without country code 03201234567 how I can compare number from database? because don't know in which format number is saved in database(with country code or without country code)
public boolean isMember(String phone, long id){
String query = "SELECT * from members where phone = ? AND active = 1 AND gid = ?";
Cursor c = dbActions.rawQuery(query, new String[]{String.valueOf(phone), String.valueOf(id)});
return c.moveToFirst();
}
Suppose if the number is saved in database without country code 03201234567 then my requirement is to get true if I compare it with country code. +923201234567. Country code could be changed.
PhoneNumberUtils.compare(); is not useful because it not compare with database.
If you can't acquire the correct information always; then you need to look into heuristics.
Meaning: you could write your own comparisons; and when you encounter two numbers like:
03201234567
+923201234567
you can figure: their "tail" is equal; the only difference is that the first one starts with 0 (so no country code) and the second one with +92. So it might be reasonable to declare those two numbers to be equal.
So a "solution" would do things like "normalize" your input (remove all non-digit content; except for leading + signs); and to then make such "tail-bound" comparisons.
If that is "too" fuzzy; I guess then you should step back and describe the requirement that you actually try to resolve here. Why are you comparing numbers; and what do you intend to do with the output of that comparison?!
Normalize all of the phone numbers into the same format before you put them into the database. That way you can just do a normal db search.
The other thing I've done for phone numbers is to convert all letters into the appropriate number, then remove all non digits, then just compare the last 7 digits.
I'm creating an Arduino based drone that can be controlled through an Android application.
In order to improve the user experience, I'd like to show the accelerometer/compass sensor's values on the application, so I need to send them from Arduino to Android, via Bluetooth. The values are simple integer number between 0 and 180.
The best solution I thought is to concatenate all the values (separated with a comma) in one string, and send it to the app, that will separate the single values (the string will be sent only when the app require it, in this case when a 'z' byte is received by Arduino).
if (Serial.available() > 0) {
if (Serial.read()=='z'){
Serial.println(String((int)sensor1) + ',' + String((int)sensor2) + ',' + String((int)sensor3));
}
}
Here are the App Inventor blocks:
It seems that the values are being received quite well, but there is a critical issue: somethimes the string is not received well, and that cause a lot of errors. Sometimes the received string is (for example) 10,10,10, but somethimes it is 10,10,1010 or just 10,10 ecc...
I also tried to send the values one by one, but the result was nearly the same.
I even tried to set 'numberOfBytes' to -1, using a delimiter byte, but this also was not succesful unfortunately.
I getting quite mad, so I hope there is another way to send thoose integers to Android, or to fix the system I'm already using.
I used Serial.print to send each result and then used Serial.write('>'); as the end marker.
In appinventor designer window set the Delimiter byte for Bluetooth client to 62 (the ASCII value for the > character ).
In the blocks window, use Bluetooth cliant1.Receive text and set number of bytes to -1
App invented will then read until a delimiter is found.
However it will cause the app to hang if it doesn't find one.
the problem is that you are not signaling the end of the string
I used his example on a project and was something like this:
while(Serial.available()>0){
Serial.println(String((int)Sensor1) + ',' + String((int)Sensor2)+ ',');
}
If you compare the two codes the difference will be a " , " the most at the end of the print and it solved the problem for you sitad
I was wondering, does anyone know how to get an address in a textview matched by the Linkify in Android and make it a clickable link?
I think I can figure out how to do this manually, but I was wondering if I have to match the address against a certain pattern so that it does this without me having to do it for Linkify?
I've seen other questions about this, but those are mostly outdated and never really got solved.
Could you point me in the right direction?
Below you can see how I do this manually with a longitude and latitude and the address itself.
mLocation.mImage.setOnClickListener(new View.OnClickListener() {
#Override
public void onClick(View v) {
Intent callIntent = new Intent(Intent.ACTION_VIEW);
//callIntent.setData(Uri.parse("google.navigation:q=" + establishment.getStreet() + "+" + establishment.getHousenumber() + "+" + establishment.getPostalcode() + "+" + establishment.getCity()));
callIntent.setData(Uri.parse("geo:" + establishment.getLongitude() + ", " + establishment.getLatitude()));
startActivity(callIntent);
}
});
Thanks in advance.
Maybe this can help you: http://www.aviyehuda.com/blog/2011/01/27/android-creating-links-using-linkfy/
TextView myLocation = new TextView(this);
myLocation.setText("436 Mayfield Ave, Stanford, CA");
Linkify.addLinks(myLocation , Linkify.MAP_ADDRESSES);
mainLayout.addView(myLocation);
If you look here:
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/webkit/WebView.java#WebView.findAddress%28java.lang.String%29
You'll see that currently only US addresses are supported by Linkify.
Gets the first substring consisting of the address of a physical location.
Currently, only addresses in the United States are detected, and consist of:
a house number
a street name
a street type (Road, Circle, etc), either spelled out or abbreviated
a city name
a state or territory, either spelled out or two-letter abbr
an optional 5 digit or 9 digit zip code
All names must be correctly capitalized, and the zip code, if present,
must be valid for the state. The street type must be a standard USPS spelling
or abbreviation. The state or territory must also be spelled or abbreviated
using USPS standards. The house number may not exceed five digits.
Parameters: addr the string to search for addresses
Returns: the address, or if no address is found, null
Hope this helps anyone trying to figure the same thing out.
I guess the only thing one can do is, building your own matcher for addresses.
I am working on a project in which i am getting value from excel sheet(in assets android) and reflecting data in list view.
problem is:: phone no is not in proper format.
9.777123455E9 instead of 9777123455
When it's a phone number, you should always store the cell data as text, even if it consists only of digits, since a phone number is no mathematical number and when doing operations on it, you want to treat it as a string of characters (i.e. text).
If you input a phone number that looks to Excel like a mathematical number, it will interpret it as a number and in consequence will do things to it that make sense for numbers, but not necessarily for phone numbers, such as displaying it in scientific format.
To force Excel to treat your number as text, precede it with a single quote (apostrophe) when entering it. That is, enter into the cell:
'9777123455
It will be displayed without the single quote, just as you expect a phone number to be displayed and can be processed as text.
double d=9.777123455E9;
NumberFormat formatter = new DecimalFormat("#");
System.out.println(d);
System.out.println(formatter.format(d));
output
9.777123455E9
9777123455
E9 simply means multiply by 10^9
Update:
As #blubberdiblub mentioned, for phone numbers, it makes sense to change it to text. But for other cases, If you need to do mathematical operations leaving it in the scientific format works. You can right click on the column name and select formatting option to set the type of data the column will handle (number , text etc). If you want don't want to change the phone number to text and still see the number, simply increase the width of the column. The number will be shown full (without the "E").
I am now working on a calculator, and everything works fine except for decimal places.
The calculator contains 2 displays actually, one is called fakedisplay for actual operations, and one is called Display, for presenting the desired format, ie adding commas.
When pressing 12345.678, Display will follow fakedisplay and present as 12,345.678, but if i press 12345.009, the fakedisplay will work normally as 12345.009, but the Display stuck as 12,345 until 9 is pressed, and at that time it will show 12,345.009 normally.
However, it is strange that when the user presses 0, there is no response, and until pressing 9, 009 will then immediately append.
I know this arise from the parsing code, but based on this, how could I amend the following code? I really cannot think of any solution... Many thanks for all your advice!
one.setOnClickListener(new View.OnClickListener() {
if (str.length()<15) {
Fakedisplay.append("1");
}
DecimalFormat myFormatter1 = new DecimalFormat("###,###,###,###.#################");
String str1=Fakedisplay.getText().toString();
String stripped1 = Double.valueOf(str1).toString();
stripped1 = myFormatter1.format(Double.valueOf(stripped1));
if (stripped1.endsWith(".0"))
stripped1 = stripped1.substring(0, stripped1.length() - 2);
Display.setText(stripped1);
}
Probably the easiest solution is to not strip off the .0 in the code for every keystroke..
Instead, only strip off trailing zeros (assuming there's a decimal point in there of course) when the user calls for a result. Entering keys such as the digit keys 0 through 9, the decimal point ., or the sign-change key +/- (what I'll call the entry keys) are not generating a result so should not strip trailing zeros.
However, non-entry keys, such as when you press + or - or = on your calculator can freely modify the number.
That will give you a display of the digits being entered as the user enters them but will still strip off trailing zeros when necessary.
You can do that with a modification to your statement (and, as mentioned, only doing this when the user presses a non-entry key):
stripped1 = stripped1.replaceAll("(\\.[0-9]*[1-9])0+$","$1");
stripped1 = stripped1.replaceAll("\\.0$","");
The first statement removes all trailing zeros at the end of a decimal number (other than on if it's really an integer). The second takes care of that case.
No doubt I could make a single substitution if I gave it some more thought but that should be enough to get it functional.