howdy, ummm...

Hi

can I call you Clever?

:-)

how can I help you today?

sure...but it's just a name, I'm not really that clever

if i was i would've actually come up with something clever

I have a few questions I'd like to go over today

fire away

First and foremost, I'd like to know how to create a gradient background

background for what?

I have to make a splash activity with a background gradient from white to a light grey

it's for a window background

I'd use a ShapeDrawable

Can you define it in your layout.xml file

Ok

Is that in one of the books

?

ShapeDrawable is, yes

it's lightly covered in the Advanced Android book

Thanks

in the discussion of custom ListView selectors

What exactly is a View focus?

well, focus in Android is not significantly different than focus in any other OS

it is the individual widget to which key events will be delivered

focused widgets usually have a different background (e.g., orange border)

can a container with no clickable elements maintain a focus?

I've run into problems where one element 'steals

the focus for the window

you can apply android:focusable and android:focusableInTouchMode on any View

even ones that are not naturally focusable

and it seems the solution is either to define the widget as not focusable, or to block descendents from taking the focsu from their paretn

just make sure you don't screw up the use of D-pads, trackballs, arrow keys, and the like

how do each of those parameters work?

they take a boolean

you might consider just using the <requestFocus> element in your layout to manually assign the focus to some more appropriate widget

I mean how do they work, what do they mean?

okay cool, I've seen that before

um, android:focusable makes a widget focusable (true) or not focusable (false)

I would just add it inside the tags for any widget?

yes

e.g., <Button ...><requestFocus></Button>

so if a widget is not-focusable it can't be clicked, but you can change that programmatically right?

focusable and clickable are independent properties

ah okay

usually clickable widgets are focusable

but that doesn't have to be the case

though it should be for decent navigation sans touchscreen

if a parent widget has the 'focus', and a user clicks on one its children, will the child register the click event?

beats me

Also, I have a post on stack overflow for a google-tv app that I'm having a problem with...do you think you could take a look at it?

got a link?

try adding android:nextFocusLeft to your WebView, identifying the thingy you want to get the focus

WebView is a little odd with these sorts of events, so that may not help, but it is worth trying

it doesn't work

it's not a big deal

you could try WebViewClient and shouldOverrideKeyEvent() and manually force the focus

how do you manually force the focus?

call requestFocus() on the widget that you would like to have the focus, IIRC

yes, that's right

ah... cool

so I can use requestFocus() on any widget and it will take the focus, right?

well, with the verb being "request", I don't think it's a rock-solid guarantee

but, yes, that's the theory

Have you had problems with the graphical layout editor constantly crashing eclipse?

no

I have never had the layout editor crash Eclipse

I found some other ppl who had this problem on stack overflow

if you can consistently reproduce it, file a bug on b.android.com

I will do that

where in eclipse would you set up the java sdk that you build your project on?

Hello!

Hi Frank

Clever: either Project > Properties or the overall Preferences, depending on whether you want it to affect one project or all

howdy, Frank!

Frank: do you have a question?

yes, but It will take a couple of minutes to prepare...

I'll let you know

OK

Clever: do you have another question?

Actually I'm ready

Frank: minutes must be shorter where you are :-)

anyway, go ahead

I want to control the layout when a multi-line textedit is entered. In particular to add buttons

E.g. a "done" button.

I'm afraid some users won't know that they should use the back button.

why isn't the "done" button there all the time?

Which "done" button? The one on the soft keyboard?

I have no idea

you said you wanted to "add buttons... E.g., a "done" button"

I am merely using your words

Scenario: a users selects an multiline textedit

android open softkeyboard

users types

then he has to hit back to return to the normal layout

I would like to give the user a visible solution, instead of relying on him knowing that he has to use the back button.

so, you are *not* trying to "control the layout" (as you wrote), but rather put a Done button in the input method editor

right?

The button was just a solution that I imagined to solving this UI "problem". Other elegant solutions are welcome ;-)

OK

you can ask the input method editor to have a "Done" action button, traditionally in the lower right corner

add android:imeOptions="actionDone" to your EditText

Isn't that being used in this case as the enter key for multi-line text?

ah, yes

now I understand

honestly, users will know to use BACK in that situation

otherwise, they can't do much with their devices

Just looked at Google+ App. :)

if you want an action that does something with the results of what they typed in, having a Button or something for that makes sense

and saying you aren't going to enable that button until you have valid input makes sense

I do find it annoying myself that you have to click back to get out a text editor

They put the send button in the Action bar so it is always visible.

right

the button or action bar item is to process what's in the EditText, not so much to dismiss the keyboard

though usually it does that too

if anyone has another question, chime in

Well in my case it's a Save button, and there is another field that the user can change. I guess I'd really like to customize the layout the user sees when the softkeyboard is open...

personally, I doubt that will be very user-friendly

er, otherwise

that being said, you are welcome to change the visibility of a button or something, showing it when the user is in the EditText and hiding it othewise

Well Google+ and Plume a Twitter client do things like that, and I consider them well designed.

to each their own

regardless, it tends to be easier to hide and show things that should be visible conditionally, as opposed to adding and removing them

So I'd just capture the onClick event and do whatever needs to be done layoutwise?

probably not onClick()

probably when it gets the focus

onFocus, or

yes

OK, thanks I'll give it a shot

yeah, setOnFocusChangeListener(), defined on View

any questions clever? Or should I go on?

either of you can ask questions when you have them, particularly since we're running out of chat time

I'm wondering what you consider are best practices for sharing code between different activities?

what sort of code?

Actually scratch that. What about DB access from several threads.

if you are using the same SQLiteDatabase object, it will serialize the operations

I've had some exceptions because of conflicts.

OK so you suggest I only use one SQLiteDatabase. How would you implement that?

from what I've seen, that typically arises when you have multiple SQLiteDatabase objects

ContentProvider or your own singleton

depending on how much of a fan of the ContentProvider facade you like

er, you are

Hi..I'm back

howdy, David!

I'm somethingclever..I had a network issue

David: the chat is ending in ~7 minutes -- do you have a question?

I haven't done ContentProvider yet, so I'll take Singleton as a first approach.

ah, OK

I actually have a question about ContentProviders...I don't know If understand the benefit of them vs just accessing a database

Great transition!

1. they provide an abstraction layer, to try to insulate clients from changes in the DB structure

ok

2. they handle inter-process scenarios nicely, which otherwise would require a lot of work

ok

3. they give you the ContentObserver change-monitoring framework

however, on the downside:

A. they are exported by default, meaning any app can read/write data with impunity

ok

B. their interface dumbs things down (e.g., you can't do a JOIN, GROUP BY, etc. directly)

ok

C. you can't ever close your database (which is supposed to be OK, but bugs me)

D. your output is limited to Cursors and streams (for file access)

ok

on the whole, I tend to use ContentProvider only where necessary

however, "necessary" is increasing in scope

what about using adapters as ContentObservers?

what about it?

can't you get the same functionality with an Adapter, calling notifyDataSetChanged() or some method like that?

if you call that method (I might have the name wrong) I believe the adapter will re-query your dataabase

ContentProviders, via ContentObservers, tell you when the data has changed

proactively

vs. a polling model

ah okay

you still have to requery the provider to get the results

well, that's a wrap for today's chat

next one is Tuesday, 4pm Eastern

Thanks Mark!

have a pleasant day!

Thanks