hello, EGHDK

how can I help you today?

I have a problem when testing my application when I come back from doing a whole bunch of things in other apps.

So let's say my app has activities A B and C, and I'm at C. I leave the application, and I do some web browsing and I start up like 5 different intense games, and I go back to my application, and I see it has been killed on lower end devices.

that's typical

Yeah, so I've seen that multiple times on SO.

The thing is, I'm creating a session variable that is present only once in the entire application, and it get's instatiated when I enter the application on activity A.

that's not a good plan

So when I come back into my app on some lower end devices, the variable is null.

that's why that's not a good plan

Yeah, well I'm kind of stuck.

Because there are a bunch of different paths I can go about making this work.

But I wanted to see what would be suggested by you?

Because I saw some things on SO, that were selected as the answer, but I don't believe it's the right solution.

generally speaking, don't initialize static data members in a magic activity, but rather lazy-instantiate them on first use

if you absolutely need the user to wind up at a magic activity (e.g., it's a login activity), you'll need to mess around with some task settings

Okay, that makes sense. But could you elaborate on "task settings"?

I wish I could, as I've never had to do this

one option is android:excludeFromRecents="true" on your Activity A

that would block it from ever appearing in the recent-tasks list

and hence the user can't return to it that way

another might be android:finishOnTaskLaunch="true" on all activities other than A

or, have smarts in your other activities that if you are not logged in, call startActivity() to redirect the user to A

I'd probably go that route, as it also lets you handle session timeouts (e.g., the static data member is still there, but the user hasn't authenticated in X time, and therefore we want them to reauthenticate)

Yeah, that's what I'm doing now, but it happens too darn fast on some devices.

I was hoping there would be a way to always start the "launcher" activity if my app has been killed.

I'm thinking there is, but I forget the mechanics

sigh

I made a mistake of testing the chat room from the same browser as my own account

and so now Campfire's a bit confused

Hahah

"Test User" == "Mark Murphy"

in case you see references to "Test User"

Yep, I figured that.

What if I just try to keep the application alive? Or just keep the session instance alive?

With a service or something?

please don't

hello, Michelle!

Hi!

Michelle: if you see "Test User", that's actually Mark Murphy

slight Campfire hiccup today

Gotcha. Thanks.

Michelle: since EGHDK has had a chance at a question already -- do you have a question?

I do...I almost hate to ask, though. Any plans to include Android Studio in an upcoming version of the book? If not, any recommendations for info on transitioning from Eclipse?

I blogged about "Android Studio... and the Book" some time ago

upshot, there will be coverage, but no time real soon

Hey Michelle, found this on reddit.com/r/androiddev

I would not recommend transitioning from Eclipse until 2014

Android Studio is in an "early-access preview" (or however they phrase it) now

well, to complete the work -- Android Studio isn't done

and, unless you have sufficient experience, it will be frustrating to try to determine what is an IDE bug, what is an IDE incomplete feature, and what is your not understanding something in Android

Early-access. I suppose I'm enough of a newb not to want to get involved in something that might add to my potential for confusion.

bingo

Thanks for the advice.

hello, Peri!

hi

Peri: if you see posts from "Test User", that's really Mark Murphy

Thanks for getting me in. I'll look into the issues later.

Peri: do you have a question?

My question today is with the SearchView.

I spent a lot of hours yesterday trying to get it work the way I expected.

Specifically, I have it displaying as an expandable menu item in the options menu at the top of the screen.

That works, but the default behavior is to allow it to expand only within the available space.

I want it to expand across all the other menu icons.

then I think you'll have to hide all the other menu icons yourself

or use an action mode

I finally got it to work by first making the other icons invisible, but what a hack solution!

I don't consider that to be a hack solution, personally, as I don't think the user-expected behavior is for other stuff to vanish just by pressing a search icon

If they press the search icon... how do they use the other icons if they pressed search by accident?

BACK should revert the SearchView to the iconified state

Well, the solution and what the user expects are two different things. Regardless, without hiding or overlaying the other icons, the search box is only about 6 chars wide.

you must be using it on a phone in portrait mode

Yes, back clears the search box.

you might wish to consider using it as the navigation view in that case, and hide your icon/title

Yes. I tried it on a tablet and the width isn't an issue there.

What is a navigation view?

there are three navigation modes: list, tabs, and custom

setCustomView() on ActionBar puts you in custom mode

the navigation area of an action bar is to the right of the title and to the left of the action items (in standard LTR mode)

Right. So, if you setCustomView, then what ever view you put in takes over the whole action bar?

no, it takes over the whole navigation area

So in my case, where I have just a menu bar, it would take over the menu bar?

depending upon where you are seeing the SearchView stop going leftwards, it may give you more room

well, by definition, you have other stuff in the action bar, as otherwise you wouldn't be having to hide it

er, hide them

So is your final, i.e. best, recommendation to stick with the hiding technique?

if you want more room, you need to hide something

Ok. Thanks

I'd personally hide the icon and title first, which may require setCustomView() to have it be useful

EGHDK: do you have another question?

Just what you think is the best way to handle my app closing when the process is terminated. Should I definitely stay away from the service idea?

yes, since it won't work

I gave you three suggestions in our previous discussion in the chat

android:persistent? in manifest?

that wasn't one of the three, and I'm not aware that it's supported

Or maybe "android:clearTaskOnLaunch"

I guess I'll play around with it.

I have one more question. So you can go around to the others first. Thanks.

android:clearTaskOnLaunch="true" on activity A is an option, though I think it will always force the user back to A, which may or may not be desireable

Michelle: do you have another question?

Yes.

Do you have any plans to visit Philly in the near future, to do a talk at Android Alliance or elsewhere? I was pretty bummed not to be able to make it last September.

the Android Alliance and I chatted a couple of months ago about my coming down later this year

the ball's in their court to suggest some dates

I'll ping into them about it

"may or may not be desireable" Yeah... I guess it's not desirable because it will go there every time. Not just when the process is terminated.

That would be great.

they had settled upon my ViewPager talk from AnDevCon Boston this year, though that's subject to change

Peri: do you have another question?

EGHDK: do you have another question?

I've been looking on stack overflow to see if anyone has had a similar request. I have a notification, but I can only figure out how to launch a specific activity. How do I go about just "opening" up the app. Basically mimicing the home screen icon?

no clue, sorry

usually, from a Notification, you have a specific place in your app that you need to take the user

Hmm..no crazy master "intent" to just start up the app?

no

I guess that's fair. hahaha

we're running low on time -- if anyone has a question, chime in

I'm good.

Got one more.

I had a problem that when I was in a fragment, I needed to access and change a variable in the activity that called the fragment.

I thought it wasn't possible. Because the fragment shouldn't really interact too much with a specific activity because I guess that defeats the purpose.

But on stack overflow someone mentioned to do this

yuck

And it works, but I have no idea why

well, it's just a Java object

so long as the data member isn't private, it will work

but please use encapsulation

...

and, ideally, use something like the contract pattern, if there's a chance that more than one activity will host the fragment

As much as I know about ANdroid, I'm still terrible with the basics of Java.

encapsulation, roughly translated, means "use a method"

write a method on your activity

call that method from the fragment

Oh!

That's all encapsulation means?

it's the best three-word answer I can think of

there's more to it in overall OO design

but for what we're discussing here, it'll do

Gotcha. but in this case. I'll just drop it into a method in my activity.

Awesome.

I still don't understand why the code I pasted works. But I guess that'll have to do

why wouldn't it work?

I feel like I haven't seen dot natation used that way.

To target an objects variable.

that's because usually people encapsulate such access

But I guess because I haven't done it, doesn't mean it can't be done.

Gotcha. It does make sense.

Alright. I will see you at your next chat.

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

the transcript will be posted at http://commonsware.com/office-hours/ soonish

Thanks for your time.

the next chat is tomorrow, 10am Eastern

have a pleasant day!