howdy, Suzanne!

howdy, Mark!

first, I fixed my db column (and Studio got fixed too)

cool!

so now I have a list pulled from a SimpleCursor adapter, but it's very slooooow

can I subclass SimpleCursorAdapter to recycle views? do you have an example?

slow to load? slow to scroll? something else?

slow to scroll, with a big db

SimpleCursorAdapter already does row recycling, AFAIK

what are you displaying in the list?

baby names :-) plus a background image

maybe it's the background?

background is per row?

I think bg is per list view

you might experiment with removing that, but I doubt it is your problem

so the only thing in the row is a TextView?

yes

when you say "a big db", how big?

I found this example, but it extends CursorAdapter http://stackoverflow.com/questions/4102219…

db is about 200 rows - maybe not big by your standards

yeah, that's not big

> 1MB is big

(BTW, howdy, Julius!)

(hi all)

when I scroll, list background goes black and waits ... then redraws bg and shows new rows

well, maybe I was wrong about the background being the problem

ok. i'm doing lv.setBackgroundResource

Romain Guy has some posts on that, as I recall, either in the Articles area of the Android Developers site, or on his personal blog

you might consider trying Traceview to see what it tells you

(BTW, howdy, David!)

Hi Mark,

okay, will do

Julius: do you have a question?

hi yes:

I have two IntentServices each of which performs writes to my application's database. I get SQLiteExceptions (error code 5: database is locked) if both are running at the same time. Should I bind to the IntentService to find out if an IntentService is active when an application starts?

well, ideally, you synchronize access to the database

(so as not to start the other process if teh user requests it)

why do you need two IntentServices?

oh ok... I'm not sure how to go about that

they're both getting data from different places

so one is from online and the other is from a local source MediaStore

I wouldn't consider that a strong design criterion for having more than one IntentService

so maybe I should combine them into one

?

that would be my gut instinct

ok great :)

use different action strings, or extras, or something to tell one command from the other

ok that sounds good

thanks you

David: do you have a question?

Yes. What is the best way to transfer data received by Socket to other Activities?

Let's back up a step. What is opening/using the socket?

It is UDP socket.

OK. What is opening/using the socket?

Android runs a Server.

OK. What is opening/using the socket? Is it a service?

I need to parse UDP packet by server to retrieve some information.

I guess I don't understand your opening/using the socket.

OK.

In Java, you will be creating a Socket or ServerSocket object.

Somewhere, there is a line of code that does this.

That line of code will be in a class.

That class might be a Service, or it might be an Activity, or it might be something else.

I got that, and runs okay. Android app is receiving data from other clients which initiates traffic.

I mean UDP server/client is running okay.

OK, but you are not answering my questions, which means I cannot help you.

What sort of class has the code which is opening your Socket or ServerSocket? Is it a Service?

Oh I see. It is Activity. I am consider to use Service.

Yes, your first move should be to have your socket be managed by a Service.

Otherwise, you cannot "transfer data received by Socket to other Activities", since you will be closing that socket when you move to the other activities.

But Service is not on all the time, isn't it?

It is far closer to "on all the time" than is an activity

Activities are destroyed frequently.

Users press the BACK button, rotate the screen, etc.

Android kicks activities out of memory if they are not on the screen (e.g., user presses HOME button)

That means a packet is arrived, server will run?

There is no "server"

You have a socket

You listen on the socket

This is done by a background thread in a service

when the packet arrives, the service does something, perhaps on another thread if it might take a while

(so as to not interrupt your ability to read packets off the socket)

Thank you.

The Services chapter of _The Busy Coder's Guide to Android Development_ outlines a variety of ways your service can send information about this packet to an interested activity.

I cannot tell you which is best without knowing more about your app, and that is probably beyond the scope of this chat

I will closely look at

So, I recommend you review that chapter.

umm.. everyone seems idle now.. so, Hi!

can I start a new question

howdy, yuku!

?

hi again mark!

everyone else has had a turn, so go ahead

I'm not sure if you always monitor all stackoverflow android question?

no, particularly when I am traveling, like this week

so, actually I want to re-ask this question http://stackoverflow.com/questions/4583484…

do you have any opinion about how to implement pull-to-refresh in android?

nothing better than the answers you were already given

what was wrong with the code that johan supplied?

really? which one from no 1 and 2?

I have no idea

I have not looked at johan's code

He gave you the link

it's the 2-point rated answer

bear in mind, I have never used a pull-to-refresh app in my life, so I only have a vague notion of what it even means

I have, but I haven't tried it personally, because it requires animating on the list view using API level 8

hmm, ok, I see, let me see if I can find some info for you

BTW, at this point, I would assume the Twitter app will never be released

(bugger... :))

really? what happened to twitter?

they probably took over the app, if I had to guess

(oh that's Kiwi speak not offensive!)

http://www.youtube.com/watch?v=5mzn9Wrk7ss jump to 0:25

:: shrug ::

I haven't the foggiest idea how to do that

heck, just the touch events are pushing the boundaries of my experience

basically you can pull down the listview and see something on the top of the first item

actually animating based on touch events is well beyond those boundaries

you might look at the implementation of SlidingDrawer and see if you could leverage that as a starting point

so you think we still need to mess with the touchevent?

hmm

I'm imagining a SlidingDrawer effectively above the ListView

nice idea

yeah

as the drawer opens, the ListView resizes smaller

there's a few gaps in the SlidingDrawer implementation compared to what you would need, but it's the closest thing in android.widget I can think of that would be a starting point

ok, thanks mark!

you could try hunting around to see how the notification drawer works, but I have no idea where that code might live

Suzanne; do you have another question?

Yes - you were right - it was the background image. Would using a simple background color affect ListView performance?

that's the article I was thinking of

okay, I'll read it - thanks

however, it's not on performance so much as look

ahh

you probably want to set the cache color hint

aha .. will try it, thanks

a bit over halfway through the article is the part you need

ok

Julius: do you have another question?

hi yes:

I have a Cursor which I pass into an AsyncTask as a parameter and work through the Cursor. The Cursor is managed using startManagingCursor in an Activity. If I destroy the Activity I get a StaleDataException. Just wondering if you've got any idea why this is occurring or what would be a better thing to do.

I would not pass a managed Cursor into an AsyncTask

ah ok

if the activity is destroyed while doInBackground() is rolling, you'll have some sort of problem

:)

ok

not sure if that's the StaleDataException -- I'd've expected another name

general rule of thumb: don't pass into AsyncTask anything that depends on Activity that you plan to use in doInBackground()

it tryies to access a cursor that doesn't exist from memory

ok

thanks for that - it sounds sensible.

:)

bfn

thanks, mark - bfn

yuku: do you have another question?

howdy, fitz!

fitz: do you have a question?

hello.

howdy, cody!

cody: do you have a question?

hi mark! thanks for the great packages and documentation

you're very welcome

i *did* have questions earlier but i was able to answer them / figure out my issue.

great!

but i will just ask again to see if i was on the right track....

i am using merge adapter and I originally had a regular Activity (NOT ListActivity) and i had a layout with a ListView which I injected with content, and then beneath the listview i had various other views, basically being placeholders for "sorry, no data here" (with visiblity set to gone, which i would switch back to visible when needed). anyways, i was seeing 2 issues

i would populate my merge adapter and its sub-adapters with a bunch of data, and it would render just fine

but on swipe down - the top view in my activity with fundamentally shrink in size, it would go like 1/2 screen width

AND

no click events were happening until after i "primed" the activity by clicking the MENU button. i could click around and they would get queued up but no fire, and then if i clicked the MENU button they would all fire at once.

it was somehow swallowing my events

my solution: switched my Activity to ListActivity and ditched those placeholder layouts

and both problems went away

that's wild

yeah. so my overall question then is

does MergeAdapter require a ListActivity?

i seem to have it working just fine in a reg Activity

but maybe i should switch it too

not seeing those issues on my other activities

but wild indeed

MergeAdapter should not require ListActivity, AFAIK

thats what i thought, especially after looking at the source it seems pretty generic

but good to know

btw, do you still recommend to inflate views with the 3 param style: inflate(R.layout.foo, parent, true)?

yes

necessary for RelativeLayouts in rows

i saw a stackoverflow thread where you said you might have given us all bad ideas by doing 2 param with null

oh, wait

not, true

inflate(R.layout.foo,parent,false)

i might be able to find it

right

I thought inflate(R.layout.foo, null) was OK a while back

Romain Guy set me straight

yep, thats the thread. he piped up

is that just with RelativeLayout ?

it's the one case I know of

...just an issue with....

makes sense, since a RL will get its layout from its parent, which is the list view. which he addresses in another question of mine

ok, i think it makes sense now

fitz: you haven't had a chance yet -- do you have a question?

hah, sorry for taking over

ok. im good. thanks mark!

ok, does anyone have a question?