Ken Truitt

Ranch Hand
+ Follow
since Aug 23, 2007
Merit badge: grant badges
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ken Truitt

With the 2.2 emulator running, I determined that despite having set the bounds of the drawables in the Imageviews in one
class, they were back at zeroes for the doDraw() in the SurfaceView subclass. That's odd, isn't it?

After some more screwing around I found the only way I could get these drawables to display in my SurfaceView was to
change the file names and do without the ImageViews. This went just for this one set of drawables--other imageviews
(displaying non 'pegs' -- you'd have to know my app) worked just fine.

As it happens, I have reason to believe somebody (or somebodies) got to my laptop and messed with it. Maybe this is some
kind of malicious code or something. Probably not, but anyway, I had to recode all the support for my drag and drop stuff
because I could no longer utilize ImageView's onTouch functionality (or the handling code I'd written into my subclass).

I don't know really what the issue was, but it's all good now. File this one in the folder marked 'X'.
13 years ago
And now I've discovered that actually putting ImageViews in the linearlayout in the main xml doesn't do it either--the images
still aren't visible. But when I set the background color to something that would be visible over the SurfaceView background,
there were indeed squares of the appropriate color visible. I then set the imageviews programmatically again and added background color and saw them again. From this I take it that the imageviews (and linearlayout they were in) ARE above anything that would otherwise obscure them and are visible, but the *drawables* in the imageviews aren't being displayed for some reason.

Now, to find that reason.
13 years ago
Since I know you are all riveted by this topic, I will update the situation: bringChildToFrong(), in several different places, hasn't
solved the problem--neither calling the linearlayout to front nor each individual imageview in the linearlayout has stopped this
odd random behavior.

It HAS dawned on me though that these new phones might be running 2.2 and not 2.1--so I downloaded it and indeed I get the
screwy behavior on the emulator--where I can do something about. So it shouldn't be long before I figure it out.
13 years ago
I asked about this earlier. Anyway,

The top level layout in my activity is a framelayout. I have completed, debugged and tested this app and it works exactly like it should
in all respects on my g1 and on various emulators. But on 3.7-inch displays running 2.1+, some imageviews packed in a linearlayout
are not visible. I know that they are there because you can touch and drag them with effect in the app. So I assume somehow
they have gotten under one of the other views.

Framelayout stacks everything that is added to it, one on top of the other--the only way you will see more than one child of a frame layout is if they smaller than the screen and are placed apart from eachother.

Oddly, sometimes the imageviews ARE visible--it is random. Anyway, I've been trying to combat this with framelayout.bringChildToFront(View v) on the linearlayout without success.

I wonder if anyone has any insight into how the behavior could be random like that, and how I should code these imageviews
to keep this from happening.

13 years ago
I'm not sure what you're talking about. You are trying to view (and edit) an xml file in eclipse?

Your xml file references something from a sun package?
13 years ago
Hey folks it would be great if someone--anyone--could download my app from the market ("BrainBuilder") onto
their 2.1 device and tell me if they're getting this problem that I related in my previous post.

It would get GREATER if someone might suggest some ideas to help me track down the issue. Given that
the imageviews display sometimes, and sometimes they don't, i can only imagine some kind of thread-like
issue. But I haven't spawned any threads.

Does it make sense to imagine that sometimes the linearlayout loads before the surfaceview (or other obscuring
view) and other times it doesn't?

AS I DO NOT HAVE A 2.1 DEVICE, I CANNOT TEST IT MYSELF (and yes, it works fine on the 2.1 emulator)


ps if you download it and don't want to keep it, remember to return it within FIFTEEN minutes
13 years ago
What I am suggesting is to make all of your dimensions relative
to the device width and height, so that means NO lookup table.

So the only hard value you get is say int w = gridView.getWidth();//or set it from onDraw()
then when you set your ImageView bounds you set the width to
something like int myViewWidth = Math.round(W * .12f); //round or cast to (int), 12% of width
and you do ALL of your dimensions like that. A bit tedious but
that's the only way to make sure your app scales appropriately to
whatever screen its in.

I'm not sure when GridView would have the dimensions--it would in onDraw but it
might somewhere else

13 years ago
I'm no expert but here are some observations:

I tried to call gridView.getHeight() at my onCreate(), in order to use this to set my ImageView dimentions.
but getHeight() return zero. now I know that UI dimentions are set only after onCreate exits.

You can override the GridView class and intercept the dimensions in onDraw by calling native GridView.getHeight() or
whatever, and pass those to a static field in your Activity, or pass a reference to the Activity to your overridden
GridView class. Point is, the dimensions are available by the time doDraw() is called in the GridView.

I tried to set the imageView size with a set of hard coded values, depend of the grid size.
this work nice on my emulator, with a fixed sized screen. if I want to support different screen sizes and resulotions, this is the wrong way to go.

Find a good place to get the dimensions of the device screen and base all your other values on those--They should be available
in your GridView creator or in its doDraw() method. Not sure where the best place to get them is, maybe even onCreate().
Anyway you can then set all of your variables/dimensions scaled to the screen resolution of the device your app is running
on. This assumes that you have setContentView([GridView]) ie your GridView is the activity's top View, so that it fills the
screen and its dimensions are the screen dimensions.
13 years ago
Ok, I made some changes, checked on another phone in a store, and still the same problem, which is
described below.


I have a framelayout that has, so far as we're concerned with here, a surfaceview added to it, which
would occupy the entire screen, and then a linearlayout, which would lie over that screen. It has always
worked in the emulators, but when I tried it on some 2.1 phones in a store, the imageviews in the
linearlayout (vertical) didn't show. I know they were there somewhere because they behaved correctly
when I clicked where they should be. I think my clicks would click through the surfaceview. So I'm
guessing somehow, despite being defined in the correct order in the xml, the linearlayout is getting in
the framelayout AFTER the surfaceview, so it's obscurred. This happened 8 out of 10 times when I
was in the store. 2 times it worked just right.

The imageviews are added to the linearlayout programatically shortly after oncreate(). any ideas on
how this could happen? If you have a 2.1 phone and don't mind, it's BrainBuilder on the market. Return
it after you're done for no charge, as you know.

In the xml below, the relevant linearlayout is id=pegLayout. But first is the method that is called (now) at
the end of oncreate() in my one activity to populate the linearlayout with actual imageviews (subclassed to

And now the xml...

13 years ago
[actually i'm going to have another go at this myself--sometimes
helps to write it out]
13 years ago
You all realize this thread was more than a month old? Anyway, the test that this comes from at is pretty
buggy. Like many of the tests listed in the FAQ, it has a very good interface but the questions need editing. It
*could* be a great resource i they'd debug it and edit some of the wrong questions.
I explained the rules that govern this situation, as I understand them, as best as I could above.
So in this question I would look at the two compiler issues first:
1)is the (cast) type in the same inheritance tree as the reference to be cast?
2)assuming the cast is allowed by the compiler, is the resulting assignment of
the (cast) type to the reference on the left side of the '=' operator legal?

[line numbers added by me]

In line 1, a is in the same inheritance tree as BB (it's AA--the superclass) so compiler test 1 is passed.
Then for the second compiler question, is the assignment legal if the cast is allowed--a BB reference can
always be assigned to a BB reference, so that's good. Finally, the 3rd question to evaluate has to do with
the runtime issue of the actual type of the object in the reference being cast. It's actually a BB, and the cast
will succeed if the (cast) type is the same type or a superclass of the actual type (if the cast type IS-A
[reference type]). BB IS-A BB, so this statement checks out with all three tests--it compiles and it runs.

In line 2, test 1 is passed because CastingQ is in the same inheritance tree as AA; test 2 is passed because,
assuming the cast is allowed, a CastingQ can be assigned to a reference of the same type, CastingQ(d).
So this statement compiles, but does it run? Does it pass test 3?--is the actual object in b, a BB (it started with
a CastingQ, but it was assigned a BB in line # 1 above), the same or a superclass of the (cast) type--CastingQ?
No, it's a superclass of CastingQ. So a failure in test 3 leads to a ClassCastException, as stated in my previous post.

The analysis for line # 3 above is exactly the same except that before attempting to cast the a reference to CastingQ,
it is successfully cast to BB.
This is an interesting question--I don't think they are any more difficult in terms of logic than the real test.
What makes them tougher, and most of these 3rd party test prep packages, is that, in order to try and make
their product as valuable as possible, they include more of the api than is presented in K&B. I think I had a
question on ConcurrentHashMap, for instance. Then there's the two-argument version of String.split(), and so
on. These kinds of questions are guarranteed to keep your mock scores humble. But's that's not the worst thing in
the world, is it?
For my exam preparation I wrote some 300 mock exam questions based principly on K&B, and I also wrote
a Java quiz engine to quiz myself with the questions. The quiz engine works from the command line.

I've put the single-class source file and the 300-question ".jq" file up on my website if anyone wants
to try it. The questions were written by someone who knows what's confusing to actual certification
candidates and some of them are pretty good. And they're 90% correct.

The quiz interface is nothing special, but the questions really are good at pointing out gotchas and
difficult concepts in K&B. Check them out at jQuiz.

Note: each download file is a simple text file that was created in unix and I put it back into Windows format--
if it opens in your browser rather than prompts you for a download, then go back and right-click the link
and use the save as option. Then open it in notebad on your machine.
I have been very pedantic here because I think the subject is rather confusing. I think if you look at my (revised)
3-step analysis, though, it details *all* of the factors to consider in evaluating reference casts. When I can I like
to understand every detail explicitly. I'm sure you have it so it's all good.