How to determine screen resolution programmatically

5592 views
Skip to first unread message

Philip

unread,
Dec 30, 2007, 7:48:52 AM12/30/07
to Android Developers
Hello,

Is there any way to programmatically determine the screen resolution
of the device?

Thanks

Ian

unread,
Dec 30, 2007, 10:31:17 AM12/30/07
to Android Developers
On Dec 30, 4:48 am, Philip <ProfessionalAssKic...@gmail.com> wrote:
>
> Is there any way to programmatically determine the screen resolution
> of the device?

Yes, but be careful what you want. This code in your Activity:

@Override
public void onCreate(Bundle icicle) {
. . .
WindowManager w = getWindowManager();
Display d = w.getDefaultDisplay();
int width = d.getWidth();
int height = d.getHeight();
. . .

will get you the *physical* display resolution. This is *not* the
size of your application, due to the status bar, title bar, etc.

To get your application's window size, as far as I know you have to
wait for

View.onSizeChanged(int width, int height, int oldw, int oldh);

to be called; this is *after* you've already created your GUI. This
means that if you're doing your own layout, you'll have to adjust it
in View.onSizeChanged. You can see how I handled this in Scrambled
Net:

http://code.google.com/p/netscramble/

Look in the source for BoardView:

http://netscramble.googlecode.com/svn/trunk/ScrambledNet/src/org/hermit/netscramble/BoardView.java

Ian



Philip

unread,
Dec 30, 2007, 11:31:09 AM12/30/07
to Android Developers

hackbod

unread,
Dec 30, 2007, 12:41:51 PM12/30/07
to Android Developers
You would be better off doing this in onLayout(), before calling up to
the super-class. The onSizeChanged() happens after layout has
finished for the view, meaning making these kinds of changes there
will result in a second layout having to occur in order to apply your
changes.

Actually, for what you are doing with BoardView, the best thing would
be to just implement your own layout manager -- derive directly from
ViewGroup, and implement onMeasure() and onLayout() yourself.
> http://netscramble.googlecode.com/svn/trunk/ScrambledNet/src/org/herm...
>
> Ian

Rick Genter

unread,
Dec 30, 2007, 1:40:13 PM12/30/07
to android-d...@googlegroups.com

On Dec 30, 2007, at 9:41 AM, hackbod wrote:

> You would be better off doing this in onLayout(), before calling up to
> the super-class.


This reminds me of a question I've been meaning to ask: When is the
correct time to invoke the superclass's implementation of an on*()
method?

So far I've been following the rule that the superclass's
implementation should be invoked at the start of the overriding method
when the method is in the "enabling" part of the lifecycle (onCreate,
onStart(), onResume()) and at the end of the overriding method when
the method is in the "disabling" part of the lifecycle (onPause(),
onDestroy(), etc.). So my onResume() methods always look like;

@Override
protected void onResume() {
super.onResume();
// my Activity's onResume() code goes here
}

and my onPause() methods always look like:

@Override
protected void onPause() {
// my Activity's onPause() code goes here
super.onPause();
}

So far this seems to be working, but I'd like to do this the "right"
way and couldn't find any definitive documentation.
--
Rick Genter
rick_...@comcast.net

hackbod

unread,
Jan 2, 2008, 4:39:43 AM1/2/08
to Android Developers
On Dec 30 2007, 10:40 am, Rick Genter <rick_gen...@comcast.net> wrote:
> This reminds me of a question I've been meaning to ask: When is the
> correct time to invoke the superclass's implementation of an on*()
> method?

Unfortunately, there isn't a simple rule: it entirely depends on the
method and what you want to do.

> So far I've been following the rule that the superclass's
> implementation should be invoked at the start of the overriding method
> when the method is in the "enabling" part of the lifecycle (onCreate,
> onStart(), onResume()) and at the end of the overriding method when
> the method is in the "disabling" part of the lifecycle (onPause(),
> onDestroy(), etc.).

For most of these hooks, I wouldn't worry too much about it -- the
onXxx() methods are there for the application developer to plug in
their own code, so the system classes generally take care of doing any
work that must happen before/after the application at the appropriate
point before/after the onXxx() method is called. This is certainly
the case for all of the Activity, IntentReceiver, Service, and
ContentProvider callbacks.

For the specific case of Activity.onCreate(), Activity.onResume(),
Activity.onPause(), Activity.onStop(), etc., you will be fine with
calling the super class implementation first. Of course, if you are
deriving from your own class, it may do work in one of these methods,
and you may need to call the super class in a particular order, but
that is up to you.

One thing that is slightly different is Activity.onKeyDown(), since
there is some default implementation supplied by the system (at least
causing BACK to finish the activity), so you may care more about when
you call the derived implementation. Generally for key events, I
would suggest first checking for any keys you are interested in
yourself, and then if it is not one of those calling through to the
super class and returning its result.

The view hierarchy classes are a little more complicated. For
example, standard widgets like TextView and ImageView implement
onDraw() to render themselves. If you are deriving from one of these,
you can decide when to the call the super implementation based on
where you want your own drawing to appear. There are also the
dispatchXxx() methods that you can override, and if so will very
carefully want to decide when (or even if) you call the super
implementation depending on the behavior you want to create.

Rick Genter

unread,
Jan 2, 2008, 7:54:28 AM1/2/08
to android-d...@googlegroups.com
On Jan 2, 2008, at 1:39 AM, hackbod wrote:

[An eloquent explanation of when to call super.onXxx()]

Thanks. Your explanation made perfect sense.

--
Rick Genter
rick_...@comcast.net

Reply all
Reply to author
Forward
0 new messages