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.
Related
I am working with Google's autocomplete widget for Android, but for some reason it appears to only be capturing the street number and name, but no other part, of the completed address. Here is a screenshot where I entered 91 Hudson Avenue into the autocomplete box:
Here is the snippet of my Java code which obtains the place name from the widget after a place has been selected from the drop down list:
#Override
public void onPlaceSelected(Place place) {
address = place.getName().toString();
}
The value of address is always 91 Hudson Ave without a city, state, or country, despite that I chose one of the options from the drop down menu. My guess is that there is some silly configuration step which I am missing.
If you want any other information about my setup, let me know and I can edit as soon as I get a chance.
It is because of you are doing this:
address = place.getName().toString();
You should be doing this:
ddress = place.getAddress().toString();
d
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.
As I am typing autocomplete address using http://maps.googleapis.com/maps/api/geocode/xml?sensor=false&address=** I would like to prioritize within that city any address that begins with the following name .For ex: if I type mount and priority is California then it should give back Mountain view as the recommendation answer.How do I do that .I really appreciate any help.PLease let me know with respect to the above api call.Thanks in advance.
See https://developers.google.com/maps/documentation/geocoding/#Viewports
The short of it is that you can add a 'bounds' parameter that specifies lat-lng points to hint to the geocoder that you wish to look within a particular area. An example from that page is:
http://maps.googleapis.com/maps/api/geocode/json?address=Winnetka&bounds=34.172684,-118.604794|34.236144,-118.500938&sensor=false
I have contact like "+919672525253".Now i extract the country code like "91" from that number.Now if number is like "9672525253" and if i extract the country code then it will give me "967".So after extracting the country code how can i check that remaining number is valid mobile number for that country code or not?
EDIT
If any body know the mobile number length country wise then also i can solve this problem.like in india 10 digits.
You pretty much can't. For example in the US mobile numbers and landline numbers are indistinguishable, they have normal area codes just like landline numbers. Even if it were possible every country does it differently and it is also constantly changing as numbers run out new prefixes are added and things change and their is no pattern you could match against or database you could do a lookup against.
Take a look at libPhoneNumber (bundled in ICS) which can help validating a phone number (see PhoneNumberUtils).
There's a MobileType you can get after validation but as stated in the source and by Ben, in some region this will not work.
EDIT:
Some validation code (here we need to check the phone is a valid one assuming it's a french one):
boolean isValid = false;
PhoneNumber number = null;
try {
number = this.phoneUtil.parse(phone, "FR"); // phone is number in internationnal format "+xxxxxx"
isValid = this.phoneUtil.isValidNumber(number);
} catch (final NumberParseException e) {
// ...
}
isValid // is the phone number valid according to the library?
this.phoneUtil.getRegionCodeForNumber(number); // this gets the country code of the phone as found by the library (for example "US", "CH", "GB", ...)
This works for us but you'll need to try it to see if it suit your need.
i have a EditText in my activity where i take a phone number from user.. Now user provides a number activity and based on xml rules you i have to tell whether application routes the phone number or not.
This is more of a java question, you need to know how to build regular expressions. So I assume you know how to fetch the value of the edit text. Lets assume you have loaded the phone number in a String phoneNumber. So now how do you check against a regular expression:
import java.util.regex.Pattern;
import java.util.regex.Matcher;
....
Pattern pattern = Pattern.compile("\+0[8-9][0-9]{2}-[0-9]{2}-[0-9]{3}");
Matcher matcher = pattern.matcher(phoneNumber);
if (matcher.matches()) {
// The phone number matches the template given. do the routing.
}
In th eexample I have given I am searching for phone numbers that start with + (note that + is a special character for regexes, thus I need to escape it, the same holds for $, ., ^), then I expect a zero, 8 or 9, then exactly 2 digits, a dash 2 more digits and 3 more digits. The if matcher.matches() will return true only if the phoneNumber is exactly of the described format. Hopefully this will give you a brief introduction to the regex power of java.
ITU: National Numbering Plans can help you with the harder problem.
Your question is poor enough that any one of my link, Boris's regex-centric answer, or an answer that focused on nothing more than Android's GUI could be what you're really looking for. Please keep this in mind for future questions.