hello, Jeffrey!

how can I help you today?

Hi Mark

I upload a picture

um, that's probably not going to be the fragment's job

off the cuff, I would have your ViewHolder deal with the changes

is this for all the rows in the RecyclerView? meaning if there are 10 rows visible, all 10 are flipping at once?

yes

I want to re layout 10 rows for every 30 seconds

use postDelayed() to get control every 30 seconds while you are in the foreground, probably at the fragment level

have the fragment iterate over the ViewHolders and tell each to flip(), where you implement flip() to do your layout change

at least, that's the approach I would start with

ok thanks

I have another idea but I do not know how to do it

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

Jeffrey: you would do the same thing that I just described, except flip() would change the visibility of widgets

though your approach is going to be more expensive in terms of heap space (twice the number of widgets)

and you'll need to remember to update the soon-to-be-visible widgets to have the same contents as the soon-to-be-gone widgets when you flip

let me take a question from EGHDK, and I will be back with you shortly

hey mark, ill just post my question(s) and you can get to them when you get to them. i'm working a lot on rotation and making sure that the state of my activity is there on config change. few questions about it. 1. If my process is killed will I get a bundle back? I'm asking because i set the dev option for process to none, and I save stuff onSaveInstanceState but I'm not getting anything back when I open it back up. 2. I thought if I had 20 activities in my app stack, 1 through 19 could get destroyed, if I'm looking at 20, I know you responded to a SO question about this. and apparently android won't kill an activity it will kill a process, but I've noticed that thats not true. some low end phones are killing activities in my task stack, and now i have to recreate them properly. http://stackoverflow.com/questions/7536988/andr...

EGHDK: your turn! do you have a question?

ok thanks

Hi EGHDK

"1. If my process is killed will I get a bundle back?" -- um, that depends on circumstances (e.g., is your task still considered outstanding)

"and apparently android won't kill an activity it will kill a process, but I've noticed that thats not true" -- yes, it is

outstanding?

active, whatever

I don't know the precise adjective

Okay, well, lets go with first question.

roughly speaking, it's about 30 minutes from when the user was last in the task

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

sounds good

I turn the dev option to have no processes running, so in my activity I saveinstancestate() and I go home, I open the app again, and no bundle =(

EGHDK: beats me. I focus on the real world, more so than semi-random developer option settings.

I have never used that particular option and I have no idea what its effects are with respect to tasks

if you want to terminate your process, do so from your IDE

Okay, so let me get this straight though, if I was telling someone about processes in android, a process can die, and if you go back into your app, you "should" get a bundle back?

if you go fairly quickly back into your app, your activity that is on top of the back stack of the task should get its saved instance state Bundle

where by "fairly quickly", I mean within 30 minutes or so

Mark, Okay I'll try the option from the ide... I better get my bundle back!

let me take questions from the others, and I'll be back with you shortly

Bryan: your turn! do you have a question?

I have an app that starts a persistent notification

and yes, I'm trying fairly quickly because I'm trying to test if my Boolean progressDialogShouldAppear in my bundle.

and that can stay open even if the user "closes" the app through the recent tasks

I am trying to implement a "close all services and processes and everything having to do with this app" button

but due to some stray something or other, even after I kill it all after toggling airplane mode it pops up the notfication

so my question is: is there a way to hunt down what exactly is starting my application again?

under what circumstances do you show the notification?

I have a class that extends Application that has all the services and listeners coming off of it

it shows on app startup

what does "app startup" mean, exactly?

well, originally it was when the user starts the app or boot_completed got fired

but it seems to have a mind of its own now

and starts "on it's own"

I have traced it back to the extedended Application starting back up

but I don't know how to trace backwards from that to see what is causing it to open

ok, so your Application is causing the Notification to appear

(in this test case, after toggling airplane mode)

yes

I can stop that on the "down" from Application, but I want to know what is causing the Application to start back up

with respect to your "close all services..." button, how *exactly* are you doing that?

sure, one sec

(in terms of the work being done, not putting the action on the Notification, that is)

right, I stop some listeners, close the notification and then do "stopSelf()" on my 2 running services and then do a finishAndRemoveTask() on my only activity

hmmmm...

there might be a stray listener/receiver that I haven't stoppped

that gets an event that gets fired on toggle airplane mode

there's no great way from Application onCreate() to determine why Application onCreate() is being called

ok

other than to examine LogCat at that point in time and see if you see anything interesting

makes sense, I was hoping for something automagical

my gut reaction was that Android was restarting your service, but stopSelf() should be preventing that

but looks like I will have to do some work

does a receiver start a new instance of Application if there isn't one?

receiver/listener/etc

yes

well, not listeners, insofar as the process must already exist by that point

Application, and any ContentProviders, are created first thing when your process starts up

so if the Application closes how does a listener or service even exist?

Bryan, any app components would need your app class to start. So by your App class starting, it means some other component was told to start

the Application never "closes" -- it lives until the process terminates

if the process is gone, all your Java objects are gone

that is what happens

according to the App->running in settings

there is nothing there for my app

I wouldn't trust that

but then, poof, it starts, shows the persistant notification and then goes away again

DDMS shows the same

that's better

or rather, doesn't show my app

besides, if onCreate() is what is triggering the notification, you know that you are getting your new process

ok, that lets me know where I need to go next

Thanks!!

that will be caused by something starting your activity, starting or binding to a service, or sending a broadcast to a manifest-registered receiver

hopefully, there's a reasonably finite list of those things :-)

if not, see if they'll lay in a Red Bull pipeline right to your desk

let me take questions from the others, and I'll be back with you in a bit

Jeffrey: your turn! do you have another question?

thanks, have a good one

ok thanks

How to use postDelayed() -- Handler? use a Handler in the ViewHolder to implement postDelayed() ?

postDelayed() is also implemented on View

so, you could call it on the RecyclerView

I wouldn't bother creating a Handler just to use postDelayed()

ok, How to make frament iterate over the ViewHolders and tell each to flip() ?

count from 0 to size-1, and call findViewHolderForLayoutPosition() for each

checking for null responses, meaning there is no ViewHolder for that position at the moment

do you have any example in your book that I can get an example?

of postDelayed(), yes

of iterating over the ViewHolders, no

ok thanks a lot.

let me take questions from the others, and I'll be back with you shortly

EGHDK: your turn! do you have another question?

Back to my ques number 2. I thought if I had 20 activities in my app stack, 1 through 19 could get destroyed, if I'm looking at 20, I know you responded to a SO question about this. and apparently android won't kill an activity it will kill a process, but I've noticed that thats not true. some low end phones are killing activities in my task stack, and now i have to recreate them properly.

you are welcome to publish a sample app that demonstrates your behavior

my guess is that you are misinterpreting some symptoms

I guess... maybe, but at the same time... everything in the docs makes it look like it is possible.

you already linked to the Android engineer who disputes the docs

and the docs have many bugs

I just think hackbod is wrong in her answer. maybe not wrong, but just... idk. Why would the docs be wrong for so long.

I guess, but ugh. its fruterating.

welcome to my world

So if I was telling someone about activites, would it be proper to say "if your process is open none of your activities will be destroyed by the system"?

they'll be destroyed if something destroys them (i.e., calls finish())

they won't be destroyed due to low memory conditions, for the simple reason that it won't really help

why wont it really help?

makes sense to me that it could help

it will free up *heap space*

"low memory conditions" refers to *system RAM*

and while it is possible that freeing up heap space might return some memory pages to the OS, it's rather unlikely on Android 4.4 and below, due to the nature of Dalvik's garbage collection implementation

gotcha. so basically when your app starts, it takes from the system ram a certain amount, whether you like it or not?

it grabs incrementally, starting with a chunk and allocating more system RAM as needed

however, it does so in "pages" (8K or thereabouts)

and it can only release a page back to the OS if the page is completely empty

garbage collection *can* cause a page to become empty, but for many pages, there's still some live objects floating around that are using those pages

and so even if the page is 99% empty, the page cannot be released back to the OS

got it

now, things are a bit better with ART on Android 5.0+, at least if your app spends some time in the background

in that it's a bit more likely that pages can be freed and returned to the OS

but that's not going to change Android's approach to dealing with activities, which is they're alive until somebody finish()-es them

okay. so I'm going to go back to my app and see why the heck I'm getting an issue, but I still think it's happening because the activity doesn't look the same when I come back to it of when I left it. and the only way to duplicate this behavior is by using the dev option of "Do not keep activities".

just as services are running until somebody calls stopService(), stopSelf(), unbindService(), etc.

Mark, a service can be stopped by the system and restarted if sticky.. right?

no

if the process is terminated (despite the service), the sticky behavior means Android will start a fresh process and start up the service again sometime soonish

but Android won't stop services on its own (short of terminating the whole process), just as it won't destroy activities on its own (short of terminating the whole process)

okay, that was a little bit of a tanget, but good to know. but back to the activities, why does the activity limit dev option even exist then if that's basically guaranteed not to happen?

mostly, its there to force developers to test configuration changes

basically, it destroys the activity when you leave it, and re-creates it if you return to it (e.g., pressed BACK on the activity that you started from it)

this destroy-and-recreate is also the behavior on a configuration change

having the "do not keep activities" checkbox checked basically means you're testing your saved instance state logic all the time

just by navigating forwards and backwards within your app

rather than having to remember to rotate the screen or something

yeah, so I guess if my configuration change works fine then I shouldn't have to worry about why my activity "seemingly" gets killed in this scenario.

so Ive got some things to test. ON to some other random questions I have marked down. 1. unused resources like images, I know theres a flag to enable in build.gradle but it requires proguard... do you know of another way to do this? enabling proguard is causing me issues.

to do what?

sorry, flag to enable to remove unused resources

I think a manual Lint run (Analyze > Analyze Code in Android Studio) will report unused resources

but you'll have to clean them up manually

okay, worth a try. Wondeirng if maybe theres just a way to turn on proguard without it really running on any of my fiels.

in that case, it won't know what resources are unused

yeah, I guess that makes sense

Any experience with checkstyle and how to enable it and such?

haven't used it, though I know there's a Gradle plugin for it

I have a progressdialog showing, and I save instanceState basically saying Boolean shouldShowProgress and on rotation I just create a new progress dialog. It works and all... but I get a window leaked. ideas?

use a DialogFragment

and get rid of the boolean

DialogFragment will automatically redisplay the dialog after a configuration change, if the dialog was displayed at the time of the configuration change

Okay, so if I ever need to show a popup window ish thing in my app I should be using a dialogfragment?

if you ever need to show a Dialog in your app, you should be using a DialogFragment

there are lots of other "popup window ish things" that are not subclasses of Dialog (e.g., PopupWindow)

I'm guessing in most cases I'll just want to use a DialogFragment. I guess I'll never use a PopupWindow because I've never even heard of it before. lol

So a lot of apps lately ship with a way to change themes at runtime just about, and it changes the Actionbar and widget colors, whats the best way to do this in my app?

off the top of my head, I have no idea

actually, with appcompat-v7, you should be able to change tints on the fly

as that's what Palette does, deducing a color scheme from an image and allowing you to change your look to match

beyond that, I'd look for some libraries to see if somebody has a reusable dynamic theme engine or something

okay, does tinting basically work on every widget now on every api level 15 and up? I thought tint was only new to lollipop

appcompat-v7 provides tinting for a subset of widgets, plus its action bar backport, going back to API Level 7

I don't recall off the top of my head the exact roster of affected widgets, but it's fairly extensive in the latest appcompat-v7 releaes

er, release

note, though, that you get the whole material look, not just the tinting (e.g., action bar with no icon, all-caps button captions)

okay. that's all for today. thanks mark

yup, that's a wrap for the chat

next one is Monday at 7:30pm US Eastern

have a pleasant day!