hello, Jeff!

how can I help you today?

Hi!

regarding loaders. your opinion on "oncontentchanged vs restartloader"

my opinion on loaders is "just say no"

lol.

alternatives?

event bus, AsyncTask, etc.

okay, I'll have to look into that.

the only problem that CursorLoader solves that I think is a worthwhile problem is the reload-the-Cursor-when-the-data-changes feature

and that can be handled by other means, ranging from your own ContentObserver (if you're using a ContentProvider for other reasons) or a general-purpose event bus

I'm using AsyncTaskLoader

I think AsyncTaskLoader is abstract

I use ormlite to query a local sqlite database.

so you have an OrmLiteLoader or something that extends AsyncTaskLoader

that sounds like the SharedPreferencesLoader and SQLiteCursorLoader that I implemented and eventually dropped, as they were impractical

I have a loader that extends AsycnTaskLoader.

I will definitely look into alternatives, but I am working within a framework that is heavily dependent upon loaders developed by other people. So, given that constraint, when is oncontentchanged used and when is restartloader used?

beats me

or, more accurately, I forget

you're referring to your AsyncTaskLoader implementation, right?

yes.

I just want to know the proper way to allow for the loader to reload itself when data changes.

give me a moment to review my implementations -- hold on

thanks.

OK, I'm back to "beats me"

okay, perhaps another question then on a different topic?

it's at least worth a try :-)

(I was only using forceLoad(), not dealing with either of your requested methods)

i've got an app with lint messages complaining about using getSupportActionBar instead of getActionBar.

however, if I replace them then getActionBar is underlined in red as not being defined.

off the cuff, sounds like a Lint bug

Ok.

my app only targets the nexus 7

so perhaps I can just get rid of the app compat stuff?

absolutely

any gotchas to worry about when doing so?

there's no good reason to use AppCompat with a minSdkVersion 11 or higher

none that I can think of

I inherited this project so...

ah

can you point me to a URL on how to do the upgrade or is it pretty easy?

well, one gotcha: are you using MediaRouteActionProvider?

no

(BTW, howdy, EGHDK -- be with you shortly!)

Step #1: remove the appcompat-v7 library project reference from your project

Step #2: fix all the compile errors that result from Step #1

Step #3: beer

:-)

it's pretty straightforward

got it. thanks!

you'll wind up fixing your theme, removing the app: attributes in your menu items, and no longer inheriting from ActionBarActivity

straightforward but tedious?

and changing imports to their Android SDK standard ones

tedium depends on the size of the app

bigger apps might require doing Step #2 and Step #3 repeatedly, in a loop

okay but if I remove the reference will it be pretty obvious what things break?

i.e., the IDE complains about it?

lotsa red

oh yeah

haha. ok.

thanks.

EGHDK: your turn -- do you have a question?

Hey Mark. First issue. I have activity A, then B. I press home. In my GCM receiver I set a notification with a PendingIntent to open Activity A. I get a notification. I click the notification. I'm at A. I press back, I go to B, then back again, and I'm at A. How do I clear my entire task and only have A open?

I used FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_SINGLE_TOP as flags on my Intent

that is wrapped in the PendingIntent

that keeps it in your task, but wipes out the task

FLAG_ACTIVITY_NEW_TASK would start a separate task

Interesting. Because I didn't do exactly that (I did) setFlags()NEW_TASK and CLEAR_TASK

but it didn't work.

that's Google's official guidance on the subject

and it still didn't work.

CLEAR_TOP/SINGLE_TOP worked for me the last time I tried it

it's been a while, though, since I played with that

Okay. I will try that. If it doesn't work. Any recomendation on debugging this?

Because I thought for sure the answer here: http://stackoverflow.com/questions/5979171/clea...

task information is probably in adb shell dumpsys somewhere

would work.

And it didn't. So I'm thinking it's because of my pendingIntent.

possibly

unfortunately, where I had this in the book was in a previous generation of tutorials

and I failed to reimplement it in a regular book sample

which I'll have to address at some point

Alright.

Is there anything I can do in the activity?

To clear all the tasks behind it?

nothing that would deal with this on a one-off basis

which is usually what you want for this sort of scenario, rather than saying the activity *always* has the behavior

let me swing back to Jeff for a bit, and I'll be back with you shortly

Jeff: do you have another question?

Yeah but I figure as a fail safe for now. I'll pass an extra, so I know that intent came from a notification, and on onCreate I'll wipe the other activites from the task.

OK, EGHDK, back to you

I guess I will have to look into this tomorrow. I'm not in front of my workspace right now.

I have another question though.

go right ahead

I have a list view with two distinctly different row layouts.

I've had this working for quite some time.

I was using all of the proper adapter API to specify that I have two types of list items.

Recently it seems like I get back the incorrect viewHolder.

I specifically don't, but in crash reports I do.

you're getting ClassCastExceptions?

AViewHolder cannot be cast to BViewHolder.

And it is MIND boggling how thats happening.

that's tough to answer in the abstract, sans code

how are you associating the ViewHolder with the row?

the one-argument form of setTag()?

Yeah.

by the time you have retrieved the ViewHolder and are getting the ClassCastException, have you done much else with the row?

IOW, are you sure the issue isn't that row recycling itself is somehow breaking, and you're actually getting row type B when you should be getting row type A?

If it's null then I do the initial setting up of view holders

I think that's whats happening. I'm getting type B when I should get type A.

do you perhaps have an inconsistency between your getItemViewType() and getView() methods?

where getItemViewType() might return A when getView() thinks it should be B, or vice versa?

But I've never gotten the crash to occur, and I use it all the time.

So I'm finding it tough to fix.

It seemingly works perfectly most of the time.

you could try having the Test Monkey beat on it a while, and see if it can trigger the error

Do you think that listView could be handing me back the incorrect view holder?

I can't rule it out, but I'd say the odds are better that the problem is in your code somewhere

(BTW, Jeff, if you're back, let me know)

Yeah. For now, I think I'm gonna catch the classcastexception, and then call getViewA again, with the view holder set to Null. So that it'll just regenerate as it woiuld the first time around.

I've never had the error happen before. But now the activity handles multple adapters, and that seems to have caused it. Even if the other adapters are never set

But overall is my pattern correct? getView() { if (typeA){getViewA} else if (typeB){ getViewB}}. And I have two separate view holders. Thats the general idea... right?

that's fine, so long as your if (typeA) is really based on getItemViewType()

or uses the *exact* same algorithm as getItemViewType() uses

Yeah. it is getItemViewType.

WHich at first I thought was the problem, but watching that romain guy video on listView. He seemed to say that it was smart enough not to hand you back the wrong thing.

correct

Okay. Whats the deal with classes that have a period in the name? ie ActivityManager.RunningTasks?

What's the name of that kind of class?

they are public static inner classes

InnerClass?

Anytime I encounter them I have a problem using them.

Using the constructor in the docs didn't do anything.

ActivityManager.RunningTaskInfo()

My object was null.

you don't create instances of that class

Just "that" class, or any public static inner classes?

not all public static inner classes

but probably more than just "that" class

Is there any easy way to tell when I'm not do create an instace of a class?

Okay. Got to run. I'll let you finish your answer and I'll pick up on this question next time. Thanks.

in general, the easy way is to read the documentation

in this case, the documentation lacks the pointer back to the method on ActivityManager where you get instances of this class

Okay. So it wasn't my "fault", but if I read into ActivityManager I probably wouldn've found my answer.

Great thanks.

Have a good night.

have a pleasant evening!