hello, EGHDK!

how can I help you today?

Hey Mark, so I have a problem with one of my existing apps. My app basically has two activities. Activity A (main launcher activity) which is a login activity. Then if you log in you get taken to activivty B which is your inbox and activity A is finished(). The problem I'm seeing (and can't come up with concrete results) is that once I'm logged in, I can hit home and then hit multi tasking and open the app, and I get back to the inbox. Sometimes it seems that when I hit the home key and then open the app from the drawer or from a home screen, the app starts from the Login activity again.

it depends on whether your process is running and how you get back to the app

and, to some extent, how the user left the app

tapping the launcher icon should always take you back to the launcher activity

But I'm not waiting at all. I hit home, then multitask, then back in the app. If I hit home and then directly hit the app icon, it starts from activity A.

So I guess it's an architectual problem.

if "the app icon" is the launcher icon, then it should return you to Activity A

Maybe I should have the inbox be the main launcher activity?

not necessarily

though that is one possibility

more generally, you need to take into account that the user could return to any point in your app

right now, you have 2 activities

you could have 20

you could have 200, though we'd look at you funny

given the recent-tasks list, the user could come back to any of those

and you may need them to log in again, particularly if your process had been terminated in the meantime

so you need to decide how you are going to handle the more general case

and how your launcher activity behaves should fall out of that

for example, perhaps "login" isn't an activity, but a fragment that can be shown in any of your activities (e.g., a DialogFragment)

and you pop it up if you don't have a valid session (e.g., new process, old session is too old)

Makes sense. Well, I never want the user to go to the login activity once they have logged in.

That makes sense.

Okay. I think I will make the main launcher activity the inbox. And if the session has expired it will prompt for a password again.

I have a flag on my application in my manifest, and I thought that maybe it was causing the issue. I had never noticed it before. But the flag is single instance.

that's probably not what you want

But I don't know why it's there. The flag is only valid for activities. So my question is why does android allow it to be there.

since attributes can be added in various versions of Android, the tools are fairly lenient about what they allow

gotcha

I saw this somewhere and thought maybe it was the issue, but I couldn't find any documentation on it. "That means you are using some CLEAR_TOP or finish flag in an intent or in the manifest. Or possibly it has been > 30 minutes since the app was last launched, in which case the system will restart it automatically."

Written by some diane hackborn

Ms. Hackborn is one of the core Android engineers

you'll see her in the Android Fireside Chat tomorrow at Google I|O, most likely

Can I find that in the docs somewhere?

find what?

That if you wait 30 + minutes since an app was last launched it will restart it automatically.

since I am not aware that this is how it works, I can't point you to documentation on it

Okay. I found her say that here: https://groups.google.com/forum/#!topic/android...

Next question...

that is from 2009

once you start getting that old, bear in mind that Android may have changed since then, in relevant ways

Hah. I guess you have a point... But thats why I was wondering if any dev docs had it. I'd really like to learn more about what happens when an app icon is hit, app icon is hit from the drawer, or app is launched from multi task. Thats why I ask.

and may $DEITY have mercy on your soul

eventually, I will add a chapter on this

I dread writing it

Hahah.

Is there any way for one app to have two active task stacks?

um, that depends on your definition of "app" and "have"

an app's activities can be in more than one task

I guess its not important.

Okay next question. I have an activity in my app that accepts images from the gallery. I want to accept images from applications by using an intent filter. So that after you take a picture you can press share and share it with my app.

Are there any security risks involved in this?

well, the images might be NSFW

beyond that, it depends on what you're trying to do with the image

Lets say I want to only take images, but somewhere somehow could put something malicious in it? idk I'm just trying to think of potential risks.

somebody could give you a bogus image

but, again, whether or not that is a "security risk" depends on what you are doing with the image

an activity that responds to ACTION_SEND by doing nothing is not at risk

Yeah makes sense.

Okay next question. Remember last week I asked you why making a progress dialog then calling show, then putting a thread.sleep, waits for the sleep time, then shows the progress dialog, when in my head it should do everything in the order in which it is called. Well you said that the dialog.show() is a scheduled method. Then I asked if there is any way of knowing that a method doesn't happen and you said no.

Is there really no way to tell that a method is scheduled?

Because I think startActivity and finish seem like they are scheduled also.

they are

But I'm not sure if theres a sure fire way to test it.

put a SystemClock.sleep(5000) immediately after one

and, when your app freezes, and the work has not been done, you know that it only put the request on the work queue for the main application thread

that's not a great test, for a variety of reasons, but it gets the point across

Got it.

Any difference between SystemClock.sleep and thread.sleep?

Thread.sleep() throws an InterruptedException

SystemClock.sleep() does not

hence, it's less aggravating as a developer to use SystemClock.sleep()

Interesting. I'm almost at the point of threading in my java book, so things like this are getting really interesting.

rolling back to your earlier question, in general, you have no way of knowing in most programming languages, for any method/function/whatever, whether the work implied by that method/function/whatever happens immediately or not

unless it is documented

and in Android, such behavior is infrequently documented

From the docs: "Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called an intent." Does that sentence basically mean that they are put on the queue?

it's more that their respective means of invocation -- such as startActivity() -- are asynchronous

when you call startActivity(), you get control back before the activity has been started

one could argue that the method name should have been startActivitySometimeSoonKThxBye()

but that's a little long, even for Java

and it's missing the obligatory Plz

Haha. I'm starting to read that java is slow. I really need to understand the difference between java and other programming languages. But i'll get to that soon enough.

My book makes a lot of assumptions about the reader knowing some C.

Okay, so next question. I had a problem recently where I was concatenating a string and it was dropping a character for some reason (I don't have the program handy), but basically I solved it by using String.format vs just using +. Is there any reason for this? I know its tough without an example, but now I'm overthinking whether or not I should just use string.format everywhere instead of just concatenation.

no, there is no reason for that

Hmm... so I'm fine using concatenation?

you may want to use a StringBuilder if you're doing lots of it

String.format() is a very slow way of doing string concatenation

but + works just fine

Okay.

SO this might not be the right forum for this question, but it has to do with me not fully understanding java compiled code vs something like objective c compiled code. I read a quote saying this "Swift. Because even the world's best object-oriented portable assembly language is not the right tool for some jobs." talking about Obj C. So the "best" is subjective, but does this mean that objective C, along with C gets compiled down to assembly language? Is that why its so fast compared to Java (apparently)?

I have never written in Objective-C

my guess is that it compiles to machine code at build time, as do C/C++

historically, Java has been an interpreted language, using "just-in-time compilation" (a.k.a., JIT) to convert key segments of code into machine code at runtime

machine code = assembly? So! Isn't java not using JIT anymore in ART?

Isn't it using Ahead of Time?

machine code != assembly, though there is usually a 1:1 mapping between them

the ART runtime will apply JIT-ish techniques to compile your entire app to machine code at install time

Isn't Android* not using JIT anymore.

at the moment, the ART runtime is used by ~0% of Android users

That to me sound like native code then.

it is; the question is merely when that native/machine code is generated

for Objective-C/C/C++, it is generated on the developer's PC

(where by "PC" I include OS X boxen)

for code written in Java for Android, with ART, the machine code is generated on the device at install time

Yeah. So that to me sounds awesome. It seems like you will be running 100% compiled code at runtime, and won't have to wait while the app is running.

well, it doesn't solve all "have to wait while the app is running" issues

things that are CPU bound will improve

things that are I/O bound will not

I/O so stuff like multi touch and peripherals? or i/o like file io?

yes to all

and network I/O

and Bluetooth I/O

etc.

multitouch is less of an issue, in practical terms

So if the app did only CPU stuff (like algorithms or something... can't really think of cpu intensive tasks), in my head this means to me that Java is now as fast as C... but I'm guessing that's sadly not the case?

JIT compilation has generally been pretty good, though better on servers (with lots more RAM) than on phones

a lot of "algorithms or something" would have been converted to machine code via the JIT compiler in most cases

the ahead-of-time (AOT) compilation offered by ART ensures that *all* of it is machine code

and it eliminates the overhead of actually doing the JIT compilation work

so the effects will be visible, but modest, for CPU-bound code

so, for example, your game AI logic will run a bit more efficiently

in fact, efficiency, more than raw speed, is the rationale AFAIK

pre-compiled machine code uses fewer CPU instructions, which means less battery consumption

so, while the user might get a bit of a speed boost, they will also see better battery life

So wait. because I thought I followed you up until you said "the ahead-of-time (AOT) compilation offered by ART ensures that *all* of it is machine code" But didn't you say some stuff will still need JIT like i/o?

no

with ART, all of the code you write in Java will be converted to machine code ahead of time

that does not magically make the Internet faster

so, while the AI routines of your game may be more efficient, your thread waiting on the game server is still waiting on the game server

and all the compilers in the world won't change that

Hmm... alright. So 100% of your code will be compiled at install with ART?

yes

bearing in mind that ART is an underdocumented moving target

there's an I|O presentation on it tomorrow or Thursday; watch the YouTube video or livestream

Okay, so I mistook what you said about i/o. I thought you meant i/o still means it will need JIT. you meant that i/o is inherintly slow because it relys on other stuff. file io depends on harddrive/memory card. network i/o depends on internet connection and so on...?

correct

and the "other stuff" is usually slow

GOT IT. Thanks mark.

Okay, so my last question. Is that I have an adapter with about 2k items.

I am trying to filter it asynchronously, but every time I do myFilter.getFilter.filter(sequence) it hangs the UI.

So I put it in an async task, then I get a crash with some looper/handler/something or other complaints.

.filter(sequence) in documentation says its async.

JK: the chat is nearly over

Hello everyone

JK: if you have an insanely quick question, go ahead

EGHDK: I have not tried using Filter on a large data set

oh goodness, I from Singapore so the time wasn't good

it is 8.30am and I just arrive in office

JK: sorry, my chat hours are not ideal for Singapore

I understand. Just have a quick question..

So I thought .getFilter was the culprit. But I put that in an async, but still no luck. Get the same looper crash complaint. It runs fine, but UI hangs. Any quick debug tips that you'd do?

referring to your blog http://commonsware.com/blog/2010/09/29/another-...

about bindservice and rotation. i was wondering whether is it possible to have the bindservice from Activity A to Activity B

EGHDK: I don't have any quick suggestions, other than to use Traceview and determine where your problem really lies

JK: no, sorry, a service binding is unique to an activity

Got it. Will look into that. Thanks. Till next meeting. Have a happy I/O tomorrow!

but getApplicationContext().bindservice bind to the application context isn't it?

not to the activity so pardon me as I am newbie

JK: yes, but your ServiceConnection is usually tied to the activity

isn't it posssible to pass the bindservice by bundle..

I rather doubt it

and if you are "newbie", I would not recommend bound services

oh ok. if that is the case, thanks for the information

OK, that is a wrap for today's chat

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

thank you and have a good evening

bye

the next chat is Friday at 10am US Eastern Time

have a pleasant day!