Hey there Mark, good evening :-)

Howdy, Justin!

Hey there, how are things with you this evening?

I'm fried.

Baked.

Toast.

Sun baked or brain baked?

Been a long day :-)

Oh, brain baked.

Rainy here, not much sun.

Ahh, Ok, speaking of sun, we're sending it your way, it just cleared up here around 5:00, and warmed up finally

Could you ship it overnight? Forecast here calls for rain until the weekend.

LOL, I'll see what I can do ;-)

So hopefully my questions aren't too taxing tonight, they're more general, but hope you can offer some guidance, just let me know when you're ready and I'll fire away

Have at it!

Hello

Howdy, Mike!

OKay, so on our project at the office, we're looking into how to handle different screen sizes on the different devices in our apps. However, they're looking to potentially target 1.5 as the minimum OS that we'll support...

So my questions are about the differences between 1.5 and then 1.6 in terms of resources... So here goes...

If we build an app against 1.5, for resources like drawables and layouts, is it only the -ldpi -mdpi -hdpi etc etc specific resources (like /res/drawable-ldpi) that we can not take advantage or for automatically letting the OS handle getting the correct resources for the correct screen? Or are there others that we don't have access to like layout-land and layout-port?

No, layout-land and layout-port will work.

The -hdpi family is new to 1.5.

er, 1.6.

OK, and that's also too with -small -normal -large as well, only in 1.6 and above?

Correct

However, you can cheat

the screen dimension ones work on 1.5

So if you are only targeting HVGA and maybe QVGA devices, you could use those until you can drop 1.5 support

Are those like -320x480 -480x800? Is that the format you're talking about?

Yes, though the larger dimension comes first (-480x320)

Howdy, Prasanna!

Hi Mark!

OK, very good to know! Hypothetically, if we didn't do that, would we be forced to do all of the checks in code and then branch conditionally to load the proper resources (not desirable as far as I'm concerned)?

Yes, and you'd need to name them all uniquely

Yuck :-P... What a mess... So then this leads to the next question...

there is no way for you to say "please, Mr. Android, give me the resource named R.drawable.foo as if we were on a device with such-and-so characteristics)

When you add a proximity alert to the location manager with expiration -1 is this alert active even after you recharge the phone over night? This does not seem to be the case with my Droid phone. Any ideas?

I thought I read somwhere about another hybrid approach that if we can't to support 1.5 but then still wanted to take advantage of the 1.6-style resources folders, we could build the app against the 1.6 SDK but not use any 1.6-specific API calls, so it would work on 1.5 (minSdkVersion could be set to 3 I think?) but then if it was running on a 1.6 device it would grab from the folders...

Or is that just too messy, would we just want to have the -480x320 folder instead?

And then -800x480, etc etc?

Justin: That's conceivable, but I haven't tried it. I specifically wrote my screen size samples for 1.6+ to avoid this hiccup. Of course, I expected that 1.5 would be dead by now.

Prasanna: I saw your multiple posts on this and have zero advice for you -- sorry!

OK :)

Mike: did you have a question we can merge in here somewhere? Don't want to leave you out in the (proverbial) cold...

question about scroll views

Yeah, I'm hoping we can convince our business partners to go 1.6 and above, it would be a lot cleaner. I'll check out this hybrid approach and see if it works. Otherwise, should we be safe just using -480x320 style directories or are the different densities that would still mess us up. I'll wait until Mike is done :-) Sorry for the lengthy questions! :-O

Mike: go ahead

I'm building a scroll view in code. In the middle of the scrolling content is a button that is supposed to make some of the content below it either visible or invisible

button works ok. The listener sets a boolean and then calls the method to rebuild the scroll view - this time without the content

why rebuild the ScrollView? Why not just use setVisibility() on the things that are supposed to hide/show?

can you do that on a Relative Layout?

Sure

all View/ViewGroups support setVisibility()

ok i'll give it a try. but i would like to get back to my original question as I believe I'll have other uses for it.

sure, no problem

once i've build a scroll view, how to i position it to various points.

i've tried the scrollTo method, but no luck

also, given a view object that is somewhere in the scroll view's layout hierarchy, how do I find it's position in the scroll view?

I have not tried adjusting the ScrollView position through code

I am not aware that you can find out where your position is in the ScrollView, other than perhaps by calculating the sum of the heights of the widgets that precede you

I would have expected scrollTo() to work for you, though

how do you find the height of the widgets that precede you if you are just adding them to a layout with wrap_content.

call getHeight() on them, sometime after they have been laid out

ok

Maybe my logic is not correct … So, if you want the user to be notified when she comes close to an address and you want this notification to be active until she decides to remove it, can you add a proximity alert and assume that it will be active until you do a removeProximityAlert?

Prasanna: I would assume so

OK. Thanks will investigate this further. Catch up with you later Mark!

Mark, wondering if you had any thoughts about the last question I had?

Oh, sorry, didn't realize that was a question in there

Densities are simply not handled in 1.5

Now, it may be that a 1.6 device will read the -hdpi, etc. ones and 1.5 will ignore them

Haven't tried that, personally

OK, as I'm thinking about this, I'm wondering if the screen size folders would help up since it's the icons we're concerned about on different density displays. Probably not going to help I'm assuming?

Screen size folders will help a bit

I would use default folders for your WVGA screens, then use the screen size folders for the 1.5/HVGA and 1.5/QVGA scenarios

WVGA screens on today's devices are all high density

You can then create medium-to-low density icons for the HVGA/QVGA scenarios

but, this is all kinda speculative

Gotcha, and that's probably the most likely type of device we'd encounter on average? (thinking Droid, Nexus One, Incredible, etc, all the best-sellers)

and http://www.radarnow.net/statistics.htm

best info I know of that's current, public, and talks a bit about OS levels and devices

OOhh, excellent info! Hmmm, so I'm gonna process this for a few minutes and see if any other questions come up. I'll give Mike the floor if he has other questions, and I'll chime in if I have some more questions if that works?

cool by me

OK, here's another general question, aside from what we've discussed, is there anything that's really super-compelling about wanting to support 1.6 as a minimum SDK instead of 1.5? Kind of a broad questions, but wondering if there are any big gains going to 1.6?

Text-to-speech was interesting

Otherwise, proper screen size support was the hallmark of the 1.6 release, as far as I recall

Oh, gesture support was added, if you wanted to use those

Hmm, not sure if that would be a real biggie for this project

Oh, so unrelated, did you have transcripts for the chats on your site? I thought I saw them there once but I looked the other day and didn't see them

I send a link for them to the cw-android Google Group

Right now, I'm not maintaining a master page of links to all of them

however, the format is pretty straightforward:

(e.g., http://commonsware.com/office-hours/2010-04-21)

OK, that's cool, I can look for that google group and then find the link. How soon are they posted after the chats?

usually a few minutes

Wow, super fast :-) That's great :-)

just a matter of downloading 'em off Campfire and uploading 'em to the site

mark, another question?

Mike: go ahead

ok, trying to find the layout that I want to hide within my scroll view hierarchy

findViewById doesn't seem to work

define "doesn't seem to work"

looking in the debugger, the object is null after the call to findViewById

ok

on what are you calling findViewById()? the ScrollView?

i think i've got it. apparently you've got to call findViewById on the parent of the view you want to find. correct?

not necessarily the immediate parent

but somewhere up the hierarchy, yes

and the closer you get to the immediate parent, the quicker the lookup will be

Justin: the link to the transcript may be slightly delayed -- I now have a call with somebody in Malaysia at the top of the hour

OK, no worries, if I can see it tomorrow when I'm back at the office that'll be good :-)

ok, larger problem. apparently calling setVisibility on a sub-view of a scroll view causes the scrollview to set itself to the top of the view.

That's disappointing but not entirely shocking

though Dialtacts is somehow doing stuff like this

what discussion groups would you recommend for my level of expertise with Android?

the sorts of questions you are asking here should go to StackOverflow or [android-developers]

they're not really beginner questions per se

it's a blurry line between [android-beginners] and [android-developers], anyway

i've probably got some pretty embarrassing beginner questions at some point anyway

nice thing about StackOverflow -- the blurry line doesn't exist :-)

i'll try them. thanks. See you next time.

Hey Mark, I'm all set here, gonna head out, just wanted to say thanks a bunch for making my day tomorrow go SOOOO much smoother! You shaved off hours and hours of searching for info! Hope you have a good call in a few minutes, will talk with you again soon!

happy to help, and have a pleasant evening!@

You too, take care!