Hello

howdy, Mike!

did i get the jump on everyone?

yup

fire away!

here we go. i have a layout issue

want the layout to look like this

This is basically a listview with 2 rows and then a tableview with 2 rows

OK

problem is that the edit text box at bottom isn't reachable in landscape mode

what edit text box?

so i tried to put it into a scroll view

I don't see one in the screenshot

that greyed out line with the words "MD" in it

oh

ok

so i put it into a scroll view.

now it looks like this

what is "it"?

(btw, howdy, Jay!)

Hello!

Mike: what exactly did you put into the ScrollView?

layout looks like this

You can't put a ListView in a ScrollView

i put the listview and the tableview inside a scroll view

doesn't work well

problem is the edit text depends on the values chosen in the listview. can't put the edit text at top

so, don't put the ListView in the ScrollView

i'll try that.

basically, have the ListView atop the ScrollView, where the ScrollView has the rest of your widgets

or, put them side-by-side, for landscape (list on left, field and button on right)

ok thanks

ideally, users should not have to scroll forms, so if you can reorganize the landscape layout to avoid it, so much the better

think back to the LunchList tutorial, where we reworked the detail form to put stuff more laterally rather than vertically stacked

i'll look at that

Jay: do you have a question?

Do you know if it is possible to turn on the screen and bypass the keyguard (i.e. behave like an alarm clock) with Android versions before 2.0?

beats

er, beats me

never looked

It looks like most of the flags for WindowManager that do those things were added in 2.0.

I figured it would be a long shot. :)

that sounds vaguely familiar

but I haven't had a need to look at that, and that's esoteric enough that it won't make the books for a looooooooooooooooooooong time :-)

Yeah. The only reason I think I was able to figure it out for >=2.0 is by looking at the DeskClock source code.

sorry I couldn't be of greater assistance on this one

Mike: do you have another question?

ok

I've gotta run. Thanks Mark!

see ya!

yeah i've got another

go right ahead!

we have a custom search function. users are trying to use the hardware search button

is there some way to detect and intercept when the user has pressed the hardware button?

I believe it calls onSearchRequested()

thanks

howdy, Jeff!

Hi :)

that's it for me

Jeff: do you have a question?

Mike: ok!

Yep (typing) :)

I'm trying to stack a ShapeDrawable and a BitmapDrawable in a LayerDrawable

I want the ShapeDrawable to be square, and be able to offset it from the upper left & change its size (I'm using it as a crop-cursor)

I got it to sort of work by wrapping the ShapeDrawable with an InsetDrawable,

but now I can't figure out how to actually change it.

Because InsetDrawable has no obvious setInset(x,x,x,x) method.

First, am I going about this the right way?

Or is there a better way to overlay a square of arbitrary (and dynamic) size that's going to be moved and resized by finger strokes on top of a bitmap?

um, well, you're going *way* the heck out of my depth on these things

:-)

so, I have nary a clue whether or not this is the "right way"

ok, let me give a better description of what I'm trying to accomplish.

going back to the InsetDrawable, there are android:insetLeft and kin XML attributes -- any reason you can't use those?

also, the constructor lets you supply the four inset amounts

Because the xml is static, and I need to be able to resize the square and move it?

oh

ok

(the idea: the user will drag the interior of the square to move it over the underlying pic, and grab an edge to make it larger or smaller)

yeah. that doesn't sound like InsetDrawable's purpose in life

Does Android have any real equivalent of a software sprite?

beats me

I'm *so* not a graphics guy

ie, a bitmap with transparent areas that you can arbitrarily position as the top layer.

beats me

:) 2D graphics seems to be the dark, unexplored alley of the Android universe

well, it's certainly dark and unexplored in my books

;)

_Hello, Android_ has some stuff on it, maybe 30 pages or so

however, that's in the context of a Sudoku game

not quite as interactive as what you're envisioning

The javadoc from Google on InsetDrawable is almost complete gibberish.

yeah, a lot of those classes are that way

when I think "sprites", I think of drawing on the Canvas

I've almost gotten the impression that I'm supposed to subclass ShapeDrawable and override the getPadding(Rect) method, but when I tried, it didn't seem to work.

is there a reason you're trying to do this via Drawables?

when all you have is a hammer, everything starts to look like a nail? ;-)

ah

OK, as far as canvases go...

is the idea with a canvas that you overlay everything onto a single canvas? Or do you use one canvas per layer, with transparencies, and stack them all like I'm

trying to do so far with the BitmapDrawable and ShapeDrawable in a LayerDrawable?

ummmm...did I mention that I'm *so* not a graphics guy?

lol.

I haven't seen much discussion of the layer approach

that being said, I tune out of a lot of that stuff

you might take a shot at StackOverflow, if you haven't already

Yeah, I'm having a rough time, because the only examples I can find that involve overlaying a pointer or crosshair on something involve doing it over Google Maps.

Posted there a day and a half ago.

I would think there's gotta be an open source project for this sort of thing you could examine

Me too... but I haven't found any yet. It's weird, because

cropping a pic from the camera gallery seems like such a blatantly obvious thing that

someone would eventually have to do.

DivideAndConquer and SpriteMethodTest might be interesting for you to examine, based on name/description

these are all written by Googlers

Hmmm.. ok, that looks intriguing :)

some may be a bit stale

there is also a CropImage class as part of the Gallery3D project in the Android open source project

actually, that reminded me... have you heard reports of URIs returned by the gallery's pick intent working on older phones, but failing inconsistently on newer phones (like the Epic4G, DesireHD, etc)?

you mean ACTION_PICK?

yeah.

for the MediaStore?

I've seen it happen once on my own phone (Epic), but never managed to replicate it.

yes.

um, that would be bad if that's not working

The first time I heard about it was from someone with a Desire.

every time I turn around, there's another hole sprung in the CTS...

also, is there any real difference between INTERNAL and EXTERNAL media store, or is it something Google intended to have at one point that just kind of became moot?

CTS?

not sure -- haven't used MediaStore much

CTS = Compatibility Test Suite

ah.

devices must pass it to qualify for the Android Market

makes Swiss Cheese look like the Rock of Gibraltar :-(

I have a hunch that it's a bug that only manifests itself with super-hires pics (like 5+ megapixels)

possibly

or maybe has something to do with a header that's technically optional, but universal among windows apps and omitted by whatever Android uses to encode the jpeg file.

is the bug that the user doesn't get a chance to pick, or that the user's selection never makes it back to the activity calling startActivityForResult()?

oh, you mean like due to a rotation event? Possibly.

wasn't thinking that, though that'd be another scenario

what scenario did you have in mind?

I interpreted "failing inconsistently" as meaning a force close dialog

I was trying to determine when that dialog was appearing

however, that might have been an invalid assumption on my part

ah. No, in this case, there does seem to be an actual byte[] being generated that gets uploaded to my server, but the php lib that does the image processing chokes on it.

well, that's weird

That's kind of why my best theory so far is that Android omits something that the php image lib depends on, but is technically optional.

conceivable

is there a way you can "tee" the upload, so the file gets stored verbatim, even if the PHP library doesn't do anything with it?

then you could see if other image processing tools can read the file

if it's gibberish, lots of apps should fail on it

That was what I was going to try next. It's actually an app I inherited from someone, and the part that does the image uploading is the part I understand the least of all ;-)

howdy, Ales!

Hi

So, I kind of figured rewriting it myself (and adding the image-crop and rotation features) would be a good learning exercise that might leave me with a better idea of where something is going wrong.

sounds reasonable, though my ability to assist will be relatively modest, since that's not my cup o' tea

Ales: do you have a question?

Yes. Is RelativeLayout slower then other layouts like LinearLayout?

not to the extent anyone would notice

I haven't tried creating a million of them to see

is there some specific scenario you have in mind?

I can position maybe all widgets with just one RelativeLayout, but don't know if that is "optimal"?

RelativeLayout will tend to be cheaper on RAM, and stack space, than nested LinearLayouts

all else being equal, one RelativeLayout is the more efficient answer than nested LinearLayouts

however, not everybody is comfortable with RelativeLayout

Even though OS must search for all widgets to be aligned?

it has to touch all the widgets in either case

hmm interesting

IMHO, you are substantially more likely to be bitten by "out of stack space" errors that RelativeLayout can help fix than you will have problems with RelativeLayout being perceived as too slow

thank you

(still looking at the code in SpriteMethodTest) ;)

ah, I was just going to ask if you had another question

if either of you come up with a question, chime in

Actually, do you mention anywhere in your books whether there's an easy way to put a cancel button and an OK button horizontally in a row, have them collectively fill the width, with a small bit of padding between them?

well, I don't have that specific scenario covered

I've seen a few scattered examples involving complex layouts, but nothing that seems to be an easy case of "anchor this button to the left, this button to the right, and grow both to fill the width with a N pixel gap between them"

use LinearLayout, with android:layout_width="0px" and android:layout_weight="1" for both

also, assign android:layout_marginLeft and android:layout_marginRight to achieve your gap

awesome, exactly what I was looking for :)

in the latest _The Busy Coder's Guide to Android Development_, I have a new section and sample related to using android:layout_weight for percentage-based scenarios like this

oh, another issue you might have encountered... is multitouch something that can gracefully degrade for older android phones, or is it something where you have to literally build two different versions?

ie, be ignored on an old phone, but work on a new one?

that's impossible to answer in the abstract

ah, ok.

multi-touch results in additional touch events, which you won't get on incapable hardware (e.g., resistive screens)

whether or not your *use* of those additional touch events will "gracefully degrade" is an application question

ah. ok. I was actually getting a little ahead of myself, that's next weeks' project ;)

the CropImage method in AOSP you were talking about earlier is the one that's in the AOSP camera app, right?

I think so

it was showing up in Gallery and Gallery3D, but I think those house the "camera app" as well, IIRC

OK, I think that'll definitely give me some good leads to explore :)

Can LinearLayout's percentage be changed in Java code. Let's say if I want to set different percentage on different resolutions?

ye

er, yes

get the LinearLayout.LayoutParams for the widget via getLayoutParams()

adjust as needed

then call setLayoutParams() to make the change

ok, will have a look. Thank you.

Thanks for your help, bye.

bye!

Thanks for your help!

bye!

see ya!