hello, EGHDK and ming!

I have an application that has a user login. Once you login, you get a registration token to signify your session is logged on. I'm doing this in activity A. I have a setting in the app that lets the user select when it will lock them back out. From 1 minute to 1 day. So if the setting is set to 1 minute, and the user leaves, and then comes back within 50 seconds, the user is not prompted for a password. But if the user leaves and comes back after 70 seconds they are prompted with a password. The problem is that an activity can be killed and I'd like to save the session in something a little more longer lasting. I realize that the process can be killed whenever by the OS, but I was thinking maybe just saving the session in the application class would do the trick.

hi

EGHDK, you narrowly got in first according to my chat log, so you get first shot

(ming: I'll be with you in a bit)

"but I was thinking maybe just saving the session in the application class would do the trick" -- no, because that goes away when your process does

if you want something persistent, save it in a persistent store: a file, SharedPreferences, or a database

I'm not looking for persistance. I'm looking for the best option while the process is alive and well.

So I thought I could save the session in a service, but... that kind of doesn't make sense to me.

then what specifically do you mean by "an activity can be killed"?

do you mean being destroyed via the BACK button?

Well, an activity would be killed faster than a service?

if memory was needed

activities are not "killed" if memory was needed

processes are killed if memory was needed

No I don't mean destroyed via the back button.

Hmm,,, so lets say I had activity A B and C. And I traversed through A and B to get to C. A and B wouldn't get killed by anything?

not unless you call finish() on them

Really?

I thought once you call onStop on an activity its eligible to be killed...

that's not surprising you think that, as I thought that too for a while

read http://commonsware.com/blog/2011/10/03/activiti...

while I take ming's first question, and I'll be back with you in a bit

ming: do you have a question?

my question is about expandablelistview

i have a long list of expandable items(parents) and each parent has 7~8 children items

I find it very slow to load, so I am wondering what is the best pattern here

did you use Traceview to determine exactly where your problem is?

data is pulled from server if cannot be found in database

no I haven't yet since I do not know how to use it

there's a chapter on Traceview in the book

I'd start there

and see what Traceview tells you

ok ill look into that

ming I recently tried traceview and it helped me find my bottleneck. It's a little intimidating, but helpful.

yes, Traceview isn't the most user-friendly tool out there

but it's really helpful for problems like this

EGHDK: your turn -- do you have another question

?

Mark M, I usually just put logs everywhere also, and watch log cat, and that usually gives me an idea of whats the bottleneck.

oh ya that was a really good and easy way

that can help, but it may not be specific enough

Mark... not really another question. Just back to the first... so activities for the most part wont be killed off. It's usually either the whole process... or nothing.

right

So what if I enter a single activity app. then press back, which calls finish on the activity. Is the application class dead? Like... what if I stored the session object in there?

"Is the application class dead?" -- not yet, as the process is not yet terminated

process termination does not occur *directly* due to BACK or HOME

moving a process to the background by BACK, HOME, or other means signals that the process *can* be killed at any point

when it *will* be killed is indeterminate

ming: do you have another question?

So I created a MySerivce extends service which has a thread and a Thread.sleep() and it just does this in a while (true) loop. I know this is probably bad, but looking in my app manager, my service is still alive and been alive for just over 4 hours now. This is leading me to thinking that I should have a service that just exists, so that the app class doesn't die so that the session is still seen as active.

that's really user-hostile

I am thinking the current pattern for loading the list is not optimal

EGHDK: let me take ming's next one, and I'll be back with you in a bit

Is it possible to load parents first, then when i click on a parent, load its children

No prob.

ming: I don't think ExpandableListAdapter will work all that well that way

ok i see

there may be a recipe for what you are describing

I do not use ExpandableListView much, and so I have not attempted what you are describing

ideally, it would support what you want

I apologize for not having more ExpandableListView experience to tap upon

EGHDK: from the user's perspective, the difference between your storing your information in a file and your using a Service is that you are tying up RAM that could be used better for something else

do not have a service running unless it is actively delivering value to the user

and keeping data in RAM to avoid writing it to a file is little value

not to mention that users with task managers will swat your process out of memory anyway

Okay. But lets just say I had a service... if it did absolutely nothing, that would most likely keep the application class around for a longer period of time... correct?

processes with services in it are considered higher priority than processes with just activities in it

because it is assumed that the services are actively delivering value to the user

and therefore such processes are, on average, less likely to be terminated due to low memory conditions

from the user's standpoint, that only makes sense if the service *is* actively delivering value

Okay, thats basically what I was looking for. Just couldn't put it to words. Yeah. I don't plan on doing this, but was just curious for my own personal application.

What would be the best way to keep a service alive forever? Just Thread.sleep()? or just don't do anything and never call stopSelf()?

the latter

bearing in mind that "forever" is not forever

Yeah. Got it.

hello, Susheel!

Hi Mark

Susheel: the others have had a chance with questions, so... do you have a question?

The reason I don't want to write the session to persistant storage is because I want to verify that the user has the password before I let them in.

Yes, how can I make the navigation bar(the one with the back button, home button and recent apps) dissapear?

in Android 4.2.2

you can't make it permanently disappear

and in 4.2.2 I don't think you can do anything with it other than dim it

ok

susheel https://developer.android.com/training/system-u...

I did that like last week in an app. heh. =)

yeah, I was just about to post that link

however, it's only gone until the user touches the screen

the immersive full-screen mode, which works a bit better, was only added in 4.4

EGHDK: thanks.. @Mark: Yes I tried that too...was wondering if there is a way to detect the touch and make it disappear it again really quickly before the user can sense it?

well, you detect the touch via your widgets

ok

and you can call setSystemUiVisibility() again

however, I suspect the user will perceive it

ok

ming: do you have another question?

not yet

im profiling my app

OK, if you come up with another one, let me know

EGHDK: do you have another question?

Okay two more questions on my list. If an app has activity A B and C. ANd I'm now at C because I went from A > B > C. I then press home, then I press the app icon from the launcher. I get brought back into A. But my process wasn't killed, I can see that a variable I set in the App class is still set. So now what happened to the previous A B and C?

Do they still count towards my app memory consumption?

thats

that's a fine question

and off the cuff, I forget :-(

Is there anyway to list all the active activities?

not really, but you could add some Log statements to onDestroy() and see if they get destroyed

if the effect of what you're doing is akin to FLAG_ACTIVITY_CLEAR_TOP, B and C at least should be destroyed

Also... this day goes down in history "July 15th 2014, Mark Murphy told me I had a "fine question"

the way I use that phrase, a "fine question" is usually one that I really ought to know the answer for, and don't, and I'm chagrined at that

:)

but you should be able to see if those activities get destroyed

if they are not, they should still be floating around your process

and you could bring them back to the foreground with FLAG_ACTIVITY_REORDER_TO_FRONT, if you wanted

Susheel: do you have another question?

Yeah I'm going to log. Theres no easy way to see what activities are active right? I remember seeing an app on the play store that was supposed to help you understand tasks and activies and their flags by showing you an up to date view of where in the task stack you are.

"Theres no easy way to see what activities are active right?" -- not that I'm aware of

Yes.

Susheel: go ahead

My android device does not have an accelerometer. Is there anyway I can flip the screen layout if the device is turned upside down?

it doesn't have an accelerometer? really?

It's not a phone. It's a custom built Single Board Computer

ah, OK

I don't know how you would know the device is turned upside down

ok

flipping the screen layout also is not something you can do on your own, unless you are drawing it all yourself

(though you *might* be able to use rotation properties to fake it)

can we not just rotate the layout by 180 degrees?

cool

I can wait for my turn if anybody else has a question

EGHDK: you're up next -- do you have another question?

Any input for this question Mark? http://stackoverflow.com/questions/24745246/and...

with respect to 1), I don't know the rules there

with respect to 2), what do you mean by "force the launcher activity"?

App icon has the intent category of "launcher"

but sometimes it doesn't give me the launcher.

launcher activity*

but that doesn't really explain what "force the launcher activity" means

So I need a way to test that if I'm at activity C, what happens to my app if I am put back into A.

ok

So I want to force open my launcher activity (A) somehow, but the app icon doesn't do it (always).

I can think of a couple of options

option #1 would be to write a second tiny app that just launches A in your first app

option #2 would be to use adb shell am start

am start?

am is the "activity manager"

it's a command-line tool, in the shell of your device or emulator

I think I might do option 1. but that means I need to export my activity A... correct?

your launcher activity is already exported

because of its intent filter... rught?

any activity with an <intent-filter> is exported by default

Got it. Okay. So I call that activity directly... or the application?

find your app in the list of apps, and tap on it

option #3 would be to run my Launchalot app from the book

there is no application

Okay thanks.

you either call startActivity() or use am start to start an activity

Susheel: your turn -- do you have another question?

Yes

Yeah, I didn't know I could make an explicit startActivity call to an outside activity.

Susheel: sorry, but I have no idea

But did I ask my question in a way you understood it?

I have never tried mixing onTouchEvent() with other higher-order UI events like a long click

ok

in fact, I rarely use onTouchEvent()

Thing is I am implementing an integer incrementer when a button is pressed and held

off the cuff, I would suggest doing *everything* from onTouchEvent() and get rid of the long-click listener

but that's just a gut instinct

ok

how would you go about implementing an integer incrementer as long as a button is held?

if I may ask

Susheel: start incrementing on MOTION_DOWN, stop incrementing on MOTION_UP

Susheel on touch down take a timestamp, ontouchup take a time stamp?

cool thanks

but, again, I haven't fussed with onTouchEvent() since I worked on drag-and-drop code for the old Maps V1 stuff a few years ago

EGHDK: Thanks

cool beans. Thanks for your help today :)

Subtract them, and you'll get lets say 3 seconds, and you can count that as the value that its been held down for. I actually did something like that recently as well.

ming: while the bar chart is sometimes informative, I'd focus more on the tree of calls in the bottom half of the Traceview window, to see what methods are consuming the most time or are being called way too many times

EGHDK: I am going to try that now

the method takes the most time is doing network request

OK, that's not surprising

is that being called on a background thread?

i guess theres no way I can improve on that

yes

you might be able to get some improvement, but that usually depends as much on the server as on your code in the app

i suppose, I am using robospice, im not completely sure but I would assume

I have never used Robospice, so I do not know all of its details

you should be able to tell from Traceview if the network calls are on the background thread, though

oh yes, it is called in the background thread

when you say that "the current pattern for loading the list is not optimal", what are your exact symptoms?

is the UI frozen?

are you waiting too long to be able to populate the ExpandableListView?

something else?

the second

OK, so you kick off the thread to build up the data for the ExpandableListAdapter, and that is taking too long?

yes

what is the nature of the network calls? is it a single call to download the whole tree of data, or is it several separate calls?

it is getting all data in one call

then there probably is not much you can do about that

then put those data into arraylist of models

is there a way you can do the call at some other time, and cache the results, so you have them when the UI is needed?

yes that will be a great idea

OK, if anyone has any remaining questions, ask away

but users' expectation is "i want to see this data now so i click the button"

Two more things. 1. Reading my java book. It talkas about synchrnoized. It says that this means something along the lines of "one atomic process". And it keeps saying atomic... I've never heard of this in programming contaxt. I think atomic as in bomb. Is this atomic thing a java thing or what?

ming: then they will need to expect to wait a bit -- show a ProgressBar or otherwise let them know you are working on it

atomic comes from "atom", which is believed cannot be separated further

EGHDK: in this sense, "atomic" means "only modified by one thing at once", more or less

OK, that's a wrap for today's chat

the transcript will be posted to http://commonsware.com/office-hours/ shortly

the next chat is next Tuesday at 7:30pm US Eastern Time

have a pleasant day!

thank you so much!