Domain name won't resolve to an IP address.

by Mike Turek » Tue, 28 Sep 2010 06:23:31 GMT

Sponsored Links
 Hello Android Developers,

I am working on a program that will connect to a time server (time-, retrieve the timestamp, and place it in a text field.

However, when I create the socket, I get an UnknownHost Exception for

Some ideas I've gotten to fix it:

1. put the <uses-permission
android:name="android.permission.INTERNET" /> tag right before the </
manifest> tag. I did this, and the change is still there.

2. use the static InetAddress.getByName() function to convert to an IP
address (this still throws the same exception)

When I pass the IP address ( to the socket constructor,
the program works fine. It only breaks when I use the actual domain

Another note. I have written this program in Java and it works
perfectly fine.

If anyone has any ideas, I'd love to hear them! Thank you!


Domain name won't resolve to an IP address.

by { Devdroid } » Tue, 28 Sep 2010 19:27:22 GMT

 > If anyone has any ideas, I'd love to hear them! Thank you!

You could be using DNS which simply malfunction (or your device
got no DNS specified at all - worth checking). Try using other DNS,
or, if you got any domain of your own, delegate something like,


time.mydomain. IN CNAME


time.mydomain IN A

and us that domain. However, if the culprit is DNS, it sill may
not solve your problem. Checking how queriers are resolved
(i.e. by using dig tool) could move you forward.


Sponsored Links

Other Threads

1. What to do about all those buttons?

This is partly a rant, partly a set of suggestions, and partly an
attempt to start a discussion on how to improve a basic part of the
Android UI.  But to skip straight to the punch line: Android phones
have too many physical buttons on them, and those button don't work
very well.  Now let me back up and explain why.

When Apple designed the iPhone, they decided to completely do away
with physical buttons.  Instead, they would have a touch screen that
allowed infinitely configurable UIs.  Each application could have
whatever buttons were appropriate for it.  This was a very good idea
that worked very well in practice, but they did end up making one
exception: the Home button.  They decided that, no matter what options
an application offered at a particular time, you always needed a way
to get out of it, and the only way to guarantee that was with a
physical button.

When Google developed Android, they decided that one button might be
enough for Apple, but it wasn't enough for them.  Why?  Who knows?
Maybe they just thought more was better.  It reminds me a bit of the
mid 80s.  When Apple introduced the personal computer mouse, they made
a big point of the fact that it only had one button.  "All you need to
do is point and click."  But Microsoft decided that Windows mice would
have two buttons, and thus would be more powerful than Macintosh
mice.  And then Unix system vendors of course had to make their
computers even more powerful, so Unix mice all had three buttons!  Of
course, this didn't actually make them more powerful.  It just made
them a lot more confusing to use.

So let's look at the four buttons found on every Android device: Home,
Menu, Back, and Search.  Do they really belong there?  Do they do more
to help or hurt the user interface?

First is the Home button, the one button Apple felt was required.  I
agree with their judgement, and have nothing to say against it.  So
let's move on.

Next is the Menu button.  I can understand the logic behind it: lots
of applications need to display menus, so it makes sense to provide a
standard mechanism for bringing them up.  That sounds reasonable.  So
what's wrong with it.

Well, first there's just the fact that it's unnecessary.  If an
application wants to offer a menu, an on-screen button would work just
as well.  But much more importantly, it turns every menu into a hidden
feature.  There is absolutely no way to tell when a menu is
available.  The user needs to just happen to wonder, "Does this screen
have a menu?", then try pressing the Menu button to find out.  That is
simply a bad user interface.

What can we do about this?  It's probably too late to get rid of the
Menu button, but there are several ways to improve the situation.  One
is for developers not to rely on it.  If you want to make a menu
available, provide an on-screen button as an alternative to the Menu
button.  Another option is to establish a standard indication to tell
the user when a menu is available.  Perhaps this could be a standard
icon somewhere on the screen, or maybe the Menu button could light
up.  But users really need to be told when a menu is available.  They
shouldn't be required to guess.

Next comes the Back button.  At first glance, this seems reasonable.
The idea of a Back button is familiar to anyone who has used a web
browser, and it works very well there.  So why not here?

The problem is that the Back button doesn't actually do what people
expect it to.  Users assume the Back button means, "Take me back to
where I was before."  But it doesn't.  It actually means, "Pop the
topmost activity off the stack of the current application."  As long
as you stay within one application those are equivalent, but as soon
as you start switching between applications the behavior becomes
frustrating and unintuitive.  For example, suppose you are working
with an application.  Press the Home button to bring up the home
screen, then press Back.  You expect it to take you back to the
application you were just in, but it doesn't.  The behavior of the
Back button really needs to be reconsidered and made more rational
from a user's perspective.

Finally there's the Search button which simply has no business being
there.  I suppose this betrays Google's biases.  They're a search
company, so of course they assume that searching is one of the most
fundamental things anyone would ever want to do.  It isn't.  I would
bet that 90% of Android device owners use the search function less
often than other features of their devices, such as making phone
calls, sending text messages, or taking photos.  So why does search
need its own physical button, while a standard application is fine for
all the others?  Answer: it doesn't.  The Search button should be

Ok, those are my very opinionated opinions on the subject.  I'm
raising this subject because I sincerely want to help improve the
Android UI, and I believe it can be improved, and the most prominent
aspects of the UI are the place to start.



2. Stylus and Finger support for Android

After just seeing the iPad released, I noticed that there was no
stylus that comes with the device, how would you take notes?  What I
would like to see from a functional standpoint for a larger screen
platform is a set of default functions for different pointing devices
that are used.

For example if I am handwriting notes with a stylus then android is
reading it as an ink pen, but at anytime I use my finger it reads as a
pointing device and I can select, scroll, zoom etc.  No need to have
to select pen or pointer.

A quick stab at a function list.
-default pen
-double tap - menu with pen functions

single finger
-default pointer
-tap and hold - right mouse menu features
-tap and hold and drag - select

two finger
-everything that has been brought up about multi-touch

larger than a finger - i.e. base of hand resting on the screen while
writing with a stylus


3. Requesting the attributes from the web view in the application

4. $98 android netbook

5. Framework for backup/restore application's private data?

6. cyrket is alive again!

7. Android Tcp client-server connection.