hello, Chrystian

my apologies if you were trying to enter the chat earlier

my reminder system broke down :-(

hello, Vinit!

Hi Mark

No worries!

Vinit: thanks for pointing out my chat room problem!

no problem, I tried 15 minutes ago and just left the window open

Chrystian: you arrived first -- do you have a question?

You're very welcome. Glad it wasn't something more.

yes

there is nothing for that sensor

most of the sensors cannot be filtered for

that is unfortunate, is there a way to limit my app on the market? besides manually selecting wich device to make the app available for?

not that I can think of

I do not want devices without that sensor to download the app, oh well, I guess I have to make it very clear on the description

the expectation, I suppose, is that few apps *only* work on devices with a humidity sensor

yes

file a feature request on http://b.android.com and pray to the deity of your choice that they add it someday :-)

thank you

ideally, there would be <uses-feature> elements for all of the sensors

Vinit: do you have a question?

I came out to check what the chat is about. I do have one, actually. How did you get so involved with StackOverflow as a contributor?

:: shrug ::

StackOverflow hadn't been around all that long, and somewhere along the line I stumbled upon the fact that people were asking questions there

I find SO to be preferable to a Google Group for this sort of support

so I started helping out and publicizing it

Very cool. Thank you.

plus, for a while, Google was directing people to use it, when they discontinued the old android-beginners group

Whoo hoo!! :)

hello, Ollie Townsend III!

How are you guys?

sorry about the chat hiccup

turns out that one of my calendar events didn't have a reminder on it...

Bah, it happens. I just thought it was me since I hadn't been around in a bit

I'm enjoying the chat, Ollie. Hope you're well.

Ollie: it's your turn -- do you have a question?

It's more with the new Android studio

If I recall you are touching on that in the next book update right?

not precisely

Version 5.1 will have a bit of coverage of IntelliJ IDEA

Version 5.3 should have similar coverage of Android Studio

Ok cool

sometime in 2014, I'll be "mainstreaming" coverage, putting Android Studio on par with Eclipse in the book

(and, oh, what sheer joy all *that* work's gonna be...)

Ok so basically I should stick to Eclipse for a bit longer lol

well, that depends upon your experience level

I definitely steer newcomers to Android away from Studio while it is in pre-release super-alpha early access preview

(or whatever they're calling it)

Android's tough enough without having to deal with IDE bugs and holes

but, if you have a year or so of Android experience, you'll probably handle those issues better

and if you want to start playing with Studio, that's perfectly reasonable

personally, I'm not planning on touching it until, say, October

I sort of do want to start playing with it, but I just keep thinking if I get stuck somewhere I wont have you to run to like I normally do lol

StackOverflow has some people helping on it, and adt-dev is serving well as a Google Group for Studio bugs

(or suspected bugs)

I am working on a couple new apps and finally decided to start actively using Fragments and am wishing I started that earlier

at least fragments have been around for 2.5 years

and while not everyone has used them, lots have, and they're fairly stable

I should probably get to my main questions before Vinit yells at me to shut up. :)

actually, let me give Vinit a turn

It's cool, Ollie. I'm learning.

Vinit: do you have another question?

I do, actually.

go right ahead

I know this is covered in the book but I still don't get what the difference between Fragments and Activities are. :-/

activities are your coarse unit of user interface

roughly analogous to a window in a desktop app, or a page in a Web app

Roger that

more importantly, like a Web page, they can be internally or externally addressable

if you have an activity with an <intent-filter>, by default other apps, like the home screen, can start up that activity

fragments are chunks of UI

an activity can elect to use fragments as a means of organizing its UI

OK. I see.

in particular, fragments are great for UI reuse: master-detail pattern between phones and tablets, multiple pages in a ViewPager, etc.

but fragments themselves cannot exist outside of an activity

and fragments are not individually addressable

(at least not externally, and not even internally by the same means that we address activities)

Cool. Thank you, Mark.

part of the confusion is that fragments did not exist in Android 1.0

any time you bolt something of that magnitude onto an existing architecture, things get weird

hello, EGHDK!

Hello

sorry if you tried entering the chat at 10am and failed -- my chat calendar entry didn't have a reminder attached, and I plum forgot

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

Just about yesterday with the "encapsulation" thing.

So when I created a method in my activity so my fragment could access it

I had to do getActivity().setAlive(true);

But I had to cast it. Which I don't understand why

if I may ask, what other programming languages do you have experience in? so I can draw an analogy

None really. Some Obj-C but even less than Java

hmmmm... ok

Java is a strongly-typed programming language

by that, we mean that all variables are of some specific type

similarly, all parameters to methods, return values from methods, etc. are of some specific type

I guess I don't get why I had to cast it, because in the fragment I'm doing getActivity() a bunch of times, and Eclipse doesn't complain.

that's because of inheritance

But his one time I'm doing getActivity() it complains

getActivity() returns a value of type Activity

you can successfully call any methods on that return value that are implemented on Activity

or things that Activity inherits from, like Context

however, the return type is Activity, not EGHDKActivity

and therefore the compiler doesn't think that you can call setAlive(true), because Activity does not have such a method

Oh. So basically all of those things are defined already in a parent somewhere. Gotcha.

however, that's merely an impact of the *return type*, not the underlying object

the object is an EGHDKActivity

casting it allows you to tell the compiler "yo, I gots an EGHDKActivity here, yo"

and so long as you are correct, you will be able to call setAlive(true)

Alright, that makes more sense.

if you are incorrect, and getActivity() is returning something else, you will crash at runtime with a ClassCastException

I realize that diving into Android development is cool and all, but you really should try to carve out some time to go back and learn a bit more about Java itself

Awesome. Alright. Thanks. I'm reading through your blog post about what java fundamentals to know before going into android. Sadly, I don't know most.

you are going to run into brick walls, magic recipes, and the like that's gonna frustrate you

Yeah, I mean I took a class once in high school.

But none of that System.out.println stuff really stuck with me.

And we never did anything that actually really explained cool stuff like inheritance and such

EGHDK, don't feel bad. I learned most of what I know from here.

Yeah, I wish there was a commonsware Java book. I'd pay good money for that =)

there are tons of Java books

Exactly!

Don't know which one to pick up!

I learned Java back when dinosaurs roamed the Earth, and so I haven't used anything modern

I know that _Head First Java_ gets rave reviews

Yeah, I heard that too. Might be worth picking up.

anyway...

Ollie: do you have another question?

Actually I did get that book

Good book.

Intents. (Hopefully that is what I should be looking at using) I want to be able to lets say, receive a message via NFC, QR code, or GCM and have it do something in my app. If the person doesn't have the app I would like them to be directed to the market to download it. Would be an intent or some other type of setup?

well, the GCM option isn't really practical, as you cannot blindly send a message to some device that doesn't have your app on it

NFC on Android supports the Android Application Record (AAR, not to be confused with the AARs associated with the new build system)

you can basically attach a record to the NFC message saying "hey, this message is for this app -- use it, or direct the user to the Play Store for it if it does not exist"

however, it only works with the Play Store (not Amazon AppStore for Android or your own servers)

for QR codes, your best bet is to have one of your activities offer an <intent-filter> that matches an HTTP URL that you control

on devices where your app is not installed, the QR code would lead to your Web site, and you can steer them to download the app

on devices where your app *is* installed, the user will have a choice of running your app or visiting the URL in a browser

I am looking at doing a sort of scavenger hunt type of thing where a person scans/taps and it registers that they found the spot in the app.

and you want them to be able to get the app when they encounter the first scavenger hunt item?

So if a stranger that isn't playing scans/taps I want to offer them the option of downloading. But that part is simple enough. The part I need help with is the "ok you hit this NFC sticker... do this" in the app

Would it be intents or something else?

my understanding is that if you set up the NFC entry on the sticker with an AAR record, it will lead them to the Play Store to install the app

I haven't tried this, as I'm not going to upload some test app to the Play Store for the purposes of experimentation

Vinit: do you have another question?

That looks exactly like the answer I wanted to hear!

Yes, I do. I'm not sure what was meant by internally addressable and externally addressable for the question I'd asked you earlier.

"addressable" means "we know how to start one"

"internally addressable" means "our own app knows how to start one"

"externally addressable" means "other apps can know how to start one"

Ah gotcha. Cool. Thanks.

EGHDK: do you have another question?

Yeah, I have my list. Let me get my next one.

Okay, what does invalidate actually do when called on a view?

at a high level, it tells Android to repaint the pixels for that view and any children (if it is a ViewGroup)

I find it weird that I can do setBackGroundResource(R.drawable.whatever) and then invalidate

you shouldn't need to invalidate()

setBackgroundResource() alone should be sufficient

manual calls to invalidate() are occasionally needed, but not too often

Okay, because there was a SO question, about changing the background, and then he calls invalidate and says that you need it.

try it without it

Okay, well then easy answer I guess. Don't use invalidate unless I need something to be redrawn.

I was really wondering because the navigation drawer tutorial that Google has uses invalidate

I'd phrase it more as "don't use invalidate() unless you try changing something, nothing happens, and adding invalidate() seems to fix the problem"

that's a bit surprising

and I don't see it

I see invalidateOptionsMenu(), which is something else

are you referring to https://developer.android.com/training/implemen... ?

Oh. Maybe that's what I saw.

invalidateOptionsMenu() says "please regenerate the action bar contents"

you'll need that particularly if you are looking to add or remove items

Oh. Okay, that makes sense.

SO basically the same thing as invalidate but for the menu items.

in the case of the DrawerLayout sample, the design guidelines say that while the drawer is open, only show action bar items of relevance to the whole activity/app

sorta

Ollie: do you have another question?

Second question that may not be needed anymore thanks to the NFC bit. Content providers. That is what I was initially looking at to setup this app, and it was way over the top of what I wanted to do I think. I should be able to manage this with just intents right?

using a ContentProvider is orthogonal to your problem

IOW, you may wish to use a ContentProvider as part of your implementation, but it's not really intrinsically tied into the solution

QR codes trigger startActivity() based upon MIME type

NFC tags trigger startActivity() based upon MIME type (and perhaps AAR)

you need to set up <intent-filter> elements on activities to react to those startActivity() requestss

er, requests

and, I'm sorry, but I'm going to need to wrap up the chat, even though we didn't quite get a full hour in due to the late start

Ok then a content provider would just be more work for no benefit

Understood

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

the next chat is tomorrow, 7:30pm Eastern

have a pleasant day!

you too

Cool. Thanks, Mark.

yep