hello, Jeffrey!

how can I help you today?

well, indicating a selection in a nav drawer is no different than indicating a selection in any other ListView

I'd use the activated state, not a selector

this is built into ListView

do you have any example in your book so that I can read it ?

though you can change the color by setting your own StateListDrawable

Hi all

of the activated state? it's in the chapter on the nav drawer

Hi My way

(BTW, hello, MyWay -- I will be with you shortly!)

Jeffrey: I use the activated state a few other places

in terms of maintaining that across configuration changes, that too is no different than just about anything else: use the saved instance state Bundle

so, in onSaveInstanceState(), make a note of what the activated row is (if any)

and in onRestoreInstanceState(), mark it as activated after setting up your ListAdapter for your fresh activity instance with its fresh nav drawer

let me take a question from MyWay, and I will be back with you in a bit

MyWay: your turn! do you have a question?

ok

(Always about the IRC client!), even if I'm checking if the client is connected, it can happen that between a user send a message and when it's sended the client is not connected anymore, in which case I'm getting an exception (RuntimeException: IO exception when sending line to server). My question is about usability... what do you think I should do, Mark?

well, off the cuff, that particular exception shouldn't be that much different than if the connection is dropped between messages, right?

you might do something in the UI to reflect the fact that the sent message may or may not have made it

yes, but this message is lost and the user does not know if it's sent or not

icon, background color, something like that as an indicator on that particular message, perhaps

I don't know enough about your UI to offer much concrete advice

should I place an icon to re-send it?

well, they can't re-send it until they are connected again

yes, exactly

and depending on the cause of the disconnect, that might be a while

so it's better to say: ehy, your message has been lost...

so IMHO the "message may not have made it" indicator needs to be there, without necessarily it being implied that they can somehow re-send it right away

yes, thank you

well, I'd use weasel words and go with "may"

yes, better

and... you'd use a snackbar for it, or?

I don't know the on-the-wire IRC protocol, so I don't know if you can determine even after reconnecting if the message made it

snackbar is not a bad idea

at least at the point of reconnect

so you can have a "RESEND" action on there

ok, thank you

how you indicate that the connection was lost overall would be however you doing that anywhere else

and an icon or something on the actual message(s) that didn't make it would be good, so when the snackbar appears, they know what they are resending

but, again, GUI design on the fly in a chat room setting like this is very off the cuff

eheh, true

so, imagine a grain of salt, about a foot on a side, and take that grain of salt with any recommendations :-)

^^

let me switch back to Jeffrey, and I'll return to you in a bit

Jeffrey: your turn! do you have another question?

Thanks Mark. I have no other questions today.

OK -- if you come up with one while you're still here, let me know, so I can swing back to you

MyWay: over to you!

eheh, same, no questions anymore :P

OK, well, if either of you come up with one, chime in!

anyway good idea to add a saturday day

yeah, it's one of those "why didn't I think of that years ago?" sorts of things...

ahah

ah, do you think on version 6.9 there will be something on the account manager? :P

no, there won't

oh :(

that's a "no time real soon" topic

on IRC clients that I remember of, I've always seen plain text, but I don't like it at all

even if it's not that sensible data, it's always an account

now, it's possible that some of my concerns with AccountManager -- namely, the awful permissions -- are better in Android 6.0 as part of the permission overhaul

but I'll focus first on other secure storage (e.g., KeyStore), that's more flexible

and get to AccountManager sometime after that

ah

nice

2016, perhaps, though had you asked me about AccountManager coverage in year X, my answer would be "X+1, perhaps", for the past few years

eheh

there's just *so* much to cover in Android...

yes, true

ah, about ArrayPagerAdapter, last time I've overriden add() to cache the position of the descriptor

now, for some reason, I've received an exception from the playstore saying that I was outofbounds

but... a new descriptor can be added only by add(), right?

so I thought the exception was raised by the add of my arraylist or something

there's also insert()

plus remove() and move() will impact positions

but if I'm not using it (even if I should override them all for future reasons) they're not called, right?

they shouldn't be

I don't believe that I use them for configuration changes and such

thanks again

happy to help!

Hi guys, I have to leave the room. Happy Saturday!

you too, thanks

bye Mark, have a good Saturday!

you too!

Thank you.

Hello!

hello, EGHDK!

how can I help you today?

Two threading/memory leak questions from me today. First, I want to make a network request without using an asynctask or a service. I want to start it from an activity, lets say downloading a file/image that I want to display. I don't want to create a service because I only want it for that single activity. The thing is, I don't want to fight the activity lifecycle too much. aka, on rotation I still want it to download. I know you can use a gui-less fragment, but someone on irc said that you can just create a thread in another class to do this for you.

I'd just use an image loading library

there's only a million of 'em

Yes, but if I wanted to do it myself. If I wasn't talking about images per se.

Would a thread be fine?

sure

Wouldn't a thread hold a reference to the class/activity that started them?

cause a mem leak?

just don't do that

create a regular Java class that extends thread, in its own Java file

or, use a static class, if you want to keep the code in the activity

only regular inner classes have the reference to the outer class and trigger a leak

static inner classes do not.

Gotcha.

now, because the thread won't have a reference to the activity, you'll need to use an event bus or something to let the activity know that the work is completed

correct

Okay. So why do you recommend creating a regular java class that extends thread. That won't cause a leak?

static class ~= regular Java class

it's just a bit of "syntactic sugar"

they are basically equivalent

yeah, I understood that also.

But lets say I did want to go the route of a new java class.

Can an object just live without an activity, if the activity told it to start up and run?

well, sure

the risk in general is garbage collection

hmm... without causing a mem leak?

but threads are effectively global in scope

well, the thread itself is a "memory leak"

hmm... Interesting.

anything that the thread holds on to cannot be garbage-collected while the thread is running

that's where the inner class problem gets you, as the thread has an implicit reference to the outer class

you don't have an implicit reference to anything from a static class or a regular Java class

So if I just created a thread inside of the activity on an onClick of a button, that could be a leak to the activity... but If I create a new class, I can have the onClick create and start the thread, but it wouldn't be attached to my activity? (unless I explicitly pass one in or something)

correct

no different than if you create an ArrayList, or a Restaurant

they too do not intrinsically know anything about an activity

Gotcha. But if I created an ArrayList onCreate, rotated the phone, I wouldn't have one ArrayList...?

Or should I say... the same ArrayList

no

at least, not if your activity is going through the normal destroy-and-recreate cycle

or your fragment is going through the normal destroy-and-recreate cycle, if your onCreate() is in a fragment

You lost me at "no different than if you create an ArrayList, or a Restaurant". Wouldn't they have to be statics to stay around in memory

correct

which is why they *won't* stay around in memory

"stay around in memory" == "memory leak"

Gotcha. So thread is inherently a memory leak... basically.

correct

technically, a thread is a garbage-collection root

So I just have to make sure that it finishes up in an activity (or stop it, or cancel it in onDestroy)?

or let it run to completion, assuming it will complete in a reasonable time

particularly if the work is still needed

Gotcha. Okay. I think that makes sense.

So in an activity, creating a long running asynctask, long running thread, are high risks for mem leaks.

Is that a fair statement?

um

Because of rotation and such

from that standpoint, yes

Last thing for thiss "first" question. Are Listeners and recievers a possible source of mem leaks? Is that a fair statement?

In onDestroy or onStop I should try to unregister, or stop listening?

a BroadcastReceiver registered in the manifest is not itself leaked

gotcha.

a BroadcastReceiver registered via registerReceiver() may get unregistered automatically when the component that registered it is destroyed

but it's good form to unregister it yourself

I guess, I just want to make sure If I implement any callbacks, that they aren't leaked.

and I can't rule out a leak there, if your BroadcastReceiver is an inner class

whether a listener will be a leak depends on what it is attached to

so, an OnClickListener on a Button will not be a leak

Like... onClicksListeners could be a leak no? Why don't they cause leaks...?

Read my mind.

because the Button will be eligible for garbage collection as soon as the Activity is

and the OnClickListener will then be eligible for garbage collection

and the whole thing goes down the drain

Does onDestroy do any kind of unregistering for my views in the super method?

not AFAIK, because it is not needed

I thought the point was that it won't be eligible for GC because it still has a listener.

Hm. Interesting. I'll try to look into that.

your activity, button, listener on the button, and such form an "object graph"

they reference each other

once nothing *outside* the graph has a reference to anything that is part of the graph, the whole graph can be garbage-collected

so, once the activity is destroyed, assuming you didn't screw up and hold a reference to the activity from something else (e.g., a thread), the activity and its widgets and their listeners can all get garbage-collected

now, listeners that are registered on system-level things become more of a problem

Okay, cool. I think I get it. Thanks. "Second" question. I have a service called ApiCalls extends IntentService. I am using retrofit (not sure if your familiar with it). Anyway, I like how intentservice gives me a sort of queue. If I call the synchronous network call in retrofit, the call completes, then the service is destroyed... if I do the async network call, then the service onDestory is called before the network request finishes. Did I just create a mem leak with an asynccall in an IntentService?

I don't really know

doing something asynchronous from within an IntentService is a serious code smell, so I don't do it

Would it make sense to only call synchronous methods in an IntentService?

yes

you are already on a background thread, anyway

you don't need another background thread

Okay. That makes sense to me. I kind of just wanted another opinion.

Okay, so the next question is subjective I guess, but again just want to run it by you. I have an intent service that takes all network calls. The network call receives data and does the proper modification in the database. Adds, modifies, deletes stuff. The database then (via eventbus) lets whoever wants to know (actvitiy most likely) that the data has changed, and it can choose to update its view if it wants. I think it's a pretty clean app architecture. But I'm not that familiar yet with architecture. Does that sound reasonable to you?

off the cuff, I like it

Hooray. I mostly came up with it myself. Then started reading about it, and other people seem to do that. But I was pretty proud of myself. It leaves my code with up to date data, don't have to worry about activity lifecycle too much, and I'm not doing any kind of network callbacks in my activities.

right

Which also means no database logic stuff in my activities.

Makes everything pretty clean.

and that's a wrap for today's chat

next one is Tuesday, also at 4pm US Eastern

But I'm trying to see if theres any flaw in it. From a more advanced persons point of view.

Okay Cool. Thanks for doing a Saturday chat

I don't know if you do those often, but it worked for me. Thanks!

as I told others earlier, it's one of those things that I'm embarrassed it took me this long to add

there will be one roughly every other week

Is there a donate button?

on your site somewhere?

the Warescription is it

sorry. "warecription"

your Warescription appears to be good until early January

anyway, have a pleasant weekend!

Okay. thanks see ya mark