hello mark!

howdy, scottt!

i don't have any questions. i just popped in since i finally got a chance

OK

as you can see, it's a wee bit quiet today

the tampa bay android developers group is doing well: 65 members at the moment

that's pretty good

my folks spend the winter months in appropriately-named Winter Haven

if I get down there sometime during a non-holiday, I'll let you know, in case there's anything I can do for your group while I'm in the area

i remember you mentioning that. my folks used to live near there

that would be very cool

we recently started a group app. but its starting out a bit slow with everyone doing the new school-year thing

yeah, understood

BTW, is this your group: http://www.meetup.com/Tampa-Bay-Android-De…

since a Scott T is in charge, I'm guessing that's yours :-)

its tuff not to just do the design and the coding myself, but i'm hoping to identify future partners for commercial projects

yeah, that would be me

i've been distracted doing on-site contract work, but i reacently worked it out to cut back my hours. my goal is to do a serious retool and get my android dev creds so that i can do that professionally

sounds like a plan

I don't keep in tune with the contract markets, but I get the sense that Android is doing fairly well in terms of opportunities

bonus is that there's a lot of remote work avail. which is what i find the best.

yes, it's great to be able to take on jobs beyond the immediate vicinity

if the number of craigslist and dice posting is any indication, then yeah its a good market right now

(but i don't know for sure. it could be that a lot of the cl ones are of the non-serious "we'll pay up to $200 for an app that does the following 50 things")

DICE never really suffered from that, back when I used them

i like the remote stuff cuz i'm most creative late at night

ah, OK

I'm most sleepy late at night

i also found i like working for smaller places. not too much into the mega-corp dilbert thing anymore

aw, c'mon -- with remote work, you won't even know if your boss' hair is pointy

true. but the mega-corps don't seem to tolerate remote work

well, that's all in the packaging

"remote work", no

"hiring a consulting firm", yes

ok. if you put it that way...

howdy, Julius!

hi everybody

hello julius

Julius: do you have a question?

oh yes

fire away!

I have a gridview which has some images (in the context of Honeycomb+) and I am wanting persistent highlight when these are selected.

there's only two people, so it's open season at the moment

I'm following your book which is working

however I'd like the highlight to show over the top of the view rather than underneath

(heh)

I was wondering if you'd come cross that problem

um

it's a bit specific...

:)

the "activated" construct is a background

so, you wouldn't be able to use that

heh background over the top probably doens't make sense

your best bet, off the cuff, would be to construct your grid cells with this in mind

right

e.g., put an ImageView over top of your other contents via a FrameLayout

then affect a change to the ImageView for the cell(s) you want "activated"

I was thinking about holding the state in the item in the adapter

you'll need to hold it somewhere

assuming that this isn't part of the data model, then the adapter is probably an OK spot

cool

I have another question if scottt doesn't have one

scottt: did a question come to mind?

nope, go ahead Julius

cool

I'm having some trouble with onActivityResult being "hit" in a Fragment

what I wanted to know is:

if I call startActivityForResult(... from a Fragment, is it any different from calling it from an Activity?

ie. will onActivityResult be called in both cases?

the docs suggest that calling startActivityForResult in a Fragment just uses the Activity to start the Activity

haven't tried it

yes

so I figure it doesn't make a difference either way.

one imagines that there's a bit of code in there that routes the result to the fragment

this is where the Android Compatibility Library comes in handy

while we don't have Honeycomb source, we do have ACL source, in the SDK

yeah appartently if you don't call super in the Activity's onActicityResult, onActivity Result in the Fragment won't get called

ah O see

I

yeah I should check that out

been using that for tabs and fragment stuff

er ActionBar stuff

taking a peek at the source now, hold on

interesting

they merge in the fragment ID into the requestCode

you can only use the lower 16 bits for the requestCode

oh so it might make a difference afterall

then, onActivityResult() of the Activity will pull the fragment ID out of the requestCode and call onActivityResult() of the Fragment

so, if a Fragment calls startActivityForResult(), the result *can* make it back to it, if the activity chains to the superclass as you indicated

right so calling myActivity.startActivityForResult is different from myFragment.startActivityForResult

subtly, yes

(bugger...)

?

I would have thought this would be a good thing

oh well...

yeah I guess

I have a few things I need to change :)

you can always call getActivity().startActivityForResult() if you want the activity-only behavior

yes it is granular which is good - you're right

just - you know I'm migrating an application from Activities to FragmentActivities and Fragments

hopefully with few profanities

which means some of my AsyncTasks which sometimes use myActivity.startA... will need to change

:)

oh yeah sorry bout that

huh? just a joke

it's colloquially (if that's a word) not really that bad :)

why would an AsyncTask call startActivityForResult()?

oh good

say I have an AsynTask that goes to check the status of something then in onPostExecute it makes the decision to start an activity

that seems like an odd flow

go on :) always looking for improvements

what sort of work is being done in doInBackground()?

going to a server online to check whether there is a credit card

hmmmm...

I guess that makes sense

if there is make a purchase perhaps or show a creditcard addition screen

right

yeah, OK, I probably overreacted

oh no please I'm all for anyone giving me better ways of doing things

thank you for looking that source up

I'm a bit slow at reading that stuff

I'll get there, but you know... :)

yeah, the Android code is sometimes tough to follow

Ms. Hackborn's stuff tends to be a bit easier for me to follow, and I think she wrote the ACL

well it seems like it's really well written which for me makes it hard to follow :p

the commenting seems pretty good

well it's just about that time. Thank you again for your help! Stilll looking out for that beer fund

since I'm not a beer drinker, you'll be waiting a while for that

have a great day!

yes beer is more a variable :)

you too!

thanks, you too bfn!

mmmmmmmmmmmmm.... $BEER!

hahahah