hi :)

sorry about that -- accidentally clicked "Sign out"...

how can I help you today?

Firstly I've tried EventBus, like you told me, Mark. It's very good, I've removed a lot of code and decoupled components.

Gabriele: glad to hear it worked for you

Now I'm watching at the GUI of my IRC client, I thought to do it like this: http://postimg.org/image/6oqh40a31/

EGHDK: hi, I'll be with you shortly!

Should I use the viewpager or something like this, to implement it?

that is a distinct possibility

I thought one fragment visible by default, the channel messages and then, by swiping to open the nicklist/channels

and maybe tapping the queries?

or you have a better idea/solution? :P

I am not sure what "tapping the queries" means

in general, do not overload swipe gestures

tapping on the private message, sorry

so, if you want to use swiping to move to different active chat channels/private message spaces, do not also use swiping to move to the nicklist

if you want swiping to handle the nicklist and channel list, then just use tabs for moving to the different active chat channels/private message spaces

this seems reasonable, yes

I let you help EGHDK, then I have another question, thank you for now :)

OK

EGHDK: your turn! do you have a question?

in my reading I've found a java tool called findbugs for Java. Is this something that's recommended for android? If not are there any other similar tools for Android?

I have no idea if FindBugs is usable on Android-centric Java code

the Android SDK has Lint, and that is integrated into Eclipse and Android Studio

So finabugs is sort of like a lint?

they are both static code analyzers

beyond that, since I have never used FindBugs, I cannot tell you much about it

But from your experience findbugs is presumably something not really necessary for Android development.

Okay got it. Thanks

it is definitely not really necessary

Gabriele: back to you -- you said that you had another question?

Last time we talked about adding a Service, so I started reading again your book and find that there are two ways to communicate with them, startService() and binding. I've understand that one is for half-duplex communication and the other full-duplex, but I'm not able to choose which one is better for me (I think there are other things to consider). Can you help me understanding how to choose? What are the important differences I should consider?

"I've understand that one is for half-duplex communication and the other full-duplex" -- not really

both are intrinsically half-duplex, in that they give the client a way to tell the service what to do

binding, particularly for local services, makes it straightforward to implement a callback or listener pattern for sending data from the service to something else

however, an event bus or other techniques can fill that role with the command pattern

I'm a big fan of loosely-coupled architectures, and so I tend to go with the command pattern and an event bus

so I can use eventbus for the service, also?

sure

I'm liking it a lot, too

you can't start a service with an event, but given that the service is running, it can post events, or it can listen for events

the tutorials in the book now use an event bus to have the DownloadCheckService tell the rest of the app that a book update was downloaded and unpacked

I will search it and have a look, thank you, this seems a good solution

now, just because I lean towards the command pattern and an event bus does not mean that binding is evil

particularly with retained fragments, it's easier to manage the state complexity than it used to be

but I can't name any scenario off the top of my head where *I* would use binding over the command pattern

let me take another question from EGHDK, and I'll be back with you in a bit

yes, I've understand what you mean :)

sure

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

With Eclipse I'm trying to build an app using command line. SInce Acelipse/ADT using ANT as the build system why do I need to install Ant to use cmd line to build an apk?

Eclipse is not using Ant as the build system

...?

this page has me confused then: http://developer.android.com/sdk/installing/stu...

that table is wrong

=(

I think they wanted to draw the contrast between Ant and Gradle, and so they shoe-horned it in there

at a high level, Android Studio and Gradle fill the same role that Eclipse and Ant do

however, while Android Studio actually uses Gradle for builds, Eclipse does not use Ant for builds

Got it.

So what does Eclipse actually use? Is there any way to use the build system eclipse uses in the cmd line? So that I don't have to install something else?

Eclipse uses Eclipse :-)

IDEs traditionally have their own build systems, rather than delegating to third-party code

Figures. So no cmd line option right?

correct

IDE's have their own build system. So Android Studio is the odd one out in this case?

that's complicated

Android Studio is based off of the IntelliJ IDEA IDE

IDEA has its own build system

however, more so than many IDEs, it treats its own build system as just one possible build system implementation

hence, IDEA can integrate with Gradle, Maven, and maybe Ant (I forget on that one)

Android Studio by default uses Gradle

Got it.

my understanding is that there are recipes for using Maven's build system instead of Gradle with Android Studio, though they aren't officially supported

Eclipse has been moving in a direction to try to be more flexible about delegating to other build systems

so there are Maven and Gradle plugins for Eclipse

but there are limitations

which is one of the reasons Xav hemmed and hawed at Google I/O when asked about Gradle for Android support for Eclipse/ADT

let me take another question from Gabriele, and I'll be back with you in a bit

Gabriele: do you have another question?

Today, using EventBus, I've encountered only a "problem" (maybe my error): I've read about the convention of the suffix MainThread and so on, but to try it, I was using onEvent; I got a message saying it couldn't find any onEvent or something like this, but changing it to onEventMainThread worked. I know it's a bit generic, but maybe you know the reason of this behavior that I cannot understand.

onEvent() definitely works -- one of my samples uses it

in fact, you *need* to use it if you want to use the ordered-delivery feature

on some class it was working, but on one it said it couldn't find any onevent, or something like this

off the top of my head, I do not know what might have caused that

eheh, thank you, I was just curios, if I find it I will search on google, or report you some more detailed info :)

OK

hello, Julius!

hey Mark, wow it's a long time since I've been here! :)

Julius: the others have had a couple of questions already, so... do you have a question?

(hi all)

hi :)

oh just wanted to pop in to say, hey and wondering if there's any chance you might look into the mergeadapter Josh made to work with erm RecylerView… I know you don't have a tardis and have a busy schedule :)

more to the point, I haven't looked at RecyclerView and probably won't get a chance until whatever-L-turns-into ships "for realz"

cool, yeah we're a bit concerned about changes too

hence, I wouldn't really grok a RecyclerView-flavored MergeAdapter

ok thanks, good to know

in my case, since you can't readily use it on pre-L environments, I didn't want to cover it in my book just yet

hope all is going well and thanks for the great docs. Still finding pieces in your books for things that come up like printing and so on

glad you like it!

it's a life saver

and good fun to read (I like the gags)

hmmm... Pep-O-Mint flavor? :-)

:)

fruity

that'd be the BlackBerry chapter, then

and before this all turns into a comedy routine...

heh well we have one of our apps on Blackberry

EGHDK: your turn! do you have another question?

I'd say that's about 80% sarcasm

(ok will leave you all thanks and have a great day; Friday already!)

-_-

autoboxing does create objects, as that's kinda the point, converting primitives (e.g., int) into object equivalents (e.g., Integer)

and, particularly at the micro-benchmark level, using autoboxing in loops can create a lot of unnecessary objects

Okay. Yeah I mean I figured. Just wanted to run it by somebody quickly.

the tone is what makes it sarcastic -- the underlying point has merit

Gabriele: back to you! do you have another question?

A last question about fragments: which is the relation between setContentView and adding a fragment with FragmentManager? I can't understand why it should be a child to being added (or something like this)

sorry, but I do not understand your question

to add a fragment dinamically, I can use fragmentmanager and add it, but it should be a "child" of what I passed to setcontentview, right?

the ID passed into the add() or replace() methods represents the container that should hold the widgets managed by the fragment

all widgets have a parent container

without a container, Android does not know where to put the widgets, how to size them, etc.

whether you use an existing container (android.R.id.content) or one of your own is up to you

uhm, so Android get my parent from what I've passed to setcontentview, but not necessarily?

again, it is up to you

some of my examples, where I am using just one fragment, I load into android.R.id.content -- the FrameLayout normally used as the container that holds onto whatever is inflated based on a setContentView() call

but, in the EU4You examples, where I am specifically demonstrating large-screen approaches, I am loading fragments into FrameLayouts inside of a horizontal LinearLayout

where the containers are set up via a call to setContentView()

why did you choose this approach, with larger screen size?

the EU4You samples are demonstrating the master/detail pattern

which implies that, on a landscape tablet, you have two fragments (master, detail) side by side

yes

a LinearLayout is an easy way to accomplish that

ah

and since Android needs to know about this LinearLayout, somewhere along the line, setContentView() is involved

to flip it around, pretty much the only time you *don't* use setContentView() is if you are loading a single fragment into android.R.id.content

yes, now it's clear to me :)

ok Mark, thank you as always! :)

you are very welcome

EGHDK: back to you! do you have another question?

(bye all, have a good evening (think to you it's evening!))

So I'm coming across a lot of mutable, immutable in my books especially in effective java. But no one has actually explained it. Like this sentence confused me "An object can always be reused if it is immutable" I thought if a object WAS mutable (mutate-able?)it can be reused, because it can change?

I do not know what that sentence means that you quoted

mutable = contents can be changed

immutable = contents cannot be changed

Okay. That's what I thought.

But does that mean that the object change change state or you can't change a variable to point to another object?

sorry, I am having difficulty parsing that sentence

Hmm.. Okay.

Basically. The example I'm given to not ever ever do is: String s = new String("hello world");

it's probably pointless

let's change the code up a bit:

String s1 = "hello world";

String s2 = new String(s1);

at this point, both variables point to different objects representing the same characters

and *possibly* the same char[] that holds the characters

(that's an implementation detail of String that I do not recall off the top of my head)

but since you cannot change the char[] array inside of a String directly, that is why they say that String is immutable

if you have another question, go right ahead

Yeah sorry network issues. Am I still live?

yes, you're here now

Okay yeah. Last question. Especially since we talked about this before.

"If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When the activity is opened again (after being finished or killed), it must be created all over."

The system will never kill an activity though right? It will only kill the process or nothing?

that depends on your definition of "the system" and "kill"

finish() destroys an activity

the default behavior of BACK calls finish()

Yeah.

hence, to some extent, "the system" (which is where the BACK press comes from after the user) will "kill" the activity in this case

So the activity is "killed" essentially and it's taken out of the stack.

right

but, in terms of freeing up system RAM, "the system" terminates processes

But can I be in Activity A then go to Activity B and then Activity A will be killed?

not normally

startActivity() does not trigger finish() on the activity calling startActivity()

you can, yourself, call finish() after calling startActivity(), in which case A will be destroyed

So lets say I set a member variable in activity A when I go back to activity A by calling finish on B that variable should still be set?

in simple cases, yes

So what would a not simple case be?

user is in A

user taps something to go to B

user presses HOME

hours pass

the process is terminated

user returns to the app via the recent-tasks list

this returns the user to B

the user presses BACK

this returns the user to A... but it is a different instance of A than before, because it is a different process than before

Gotcha.

*if* you used onSavedInstanceState() to hold onto this data, then you're fine

if you didn't, you lose it

What if I go to B. Use a ton of ram

then go back to A

your app cannot readily "use a ton of ram"

Where does onSavedInstanceState do though?

Eh. Out of time

and that's covered in the book -- see the chapter on resource sets and configuration changes

Thanks. I'll catch up next time. Because the whole bundle thing in oncreate still confuses me.

because, as you noted, we're out of time

Even from the reading.

bundle thing as in bundle parameter

understood

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

Thanks. Good night

have a pleasant day!