hello, EGHDK

how can I help you today?

Two "kinda" big issues I've been having that I would like your input on.

will it be OK if I "kinda" try to answer them? :-)

Hahaha =)

First, so with all of this material design and such theres a big push on imagery. A lot of google apps now how one large image towards the top portion of the screen and then a listView below that.

My question is more on the imageview section of it. How do they decide how tall the image is going to be (is there a guideline I haven't found yet?) and how to include that image if I wanted to include it in my app.

well, I don't use many of the apps you're describing

the height of the image is probably determined in part by graphic design and part by the aspect ratio of the image in question

I do not know what you mean by "how to include that image if I wanted to include it in my app"

Google Play music and stuff has a lot of images at the top third usually of the layout.

I'll take your word for that

Okay I'll go on to the "include that image" part of the question.

So I do have an app that is doing it right now. The app uses all images that are bundled with the apk.

But I have one image in multiple densities... but it seems like a waste

So I have a picture of mountains, but I have it saved in like 5 different dpis

Okay so I found an example. material design contact book

So I want to implement something like that... and I know if I was going to a server to retrieve that image, I would measure the room and request the server to give me back something in that size. But for my app, I want to bundle my image that is being used as the header image.

So in your opinion would it be better to include one high res picture of my mountain landscape to use as the header and scale it appropriately and treat it as an image from online (measure the required size and then resize my highres image to that size?)

I don't really know what constitutes "better"

I know I'm kind of rambling at this point, but I just don't know what the best way to include high resolution images in my app.

shipping artwork in multiple densities is designed to give quality output on that range of densities

using a single density, regardless of its source, runs the risk of looking poor in various situations, as that image is scaled up and down

Yeah but lets say I set the hieght to be 200 dp, I still don't know the width of the image should be... so I still don't know what resolution to ship anyway.

Lets say I have a button that is 48 x 48dp then I KNOW exactly what resolutions to ship.

for each dpi bucket

you have a photo of a mountain landscape

it was taken at a particular resolution

but for a "header" image or whatever you want to call it, it's tough to decide what resolutions to ship in a particular dpi bucket

it is the same process

back to your photo

somebody owned a camera

they took a picture of some mountains

somewhere, you got that picture

it has a resolution

now, at this point, you have two options:

1. allow Android to do all of the rescaling, taking into account both density and the size of the image that you will wind up needing

2. you provide different scaled images for different densities, and Android only scales to take into account screen size

Android's algorithms for scaling are optimized for things like CPU usage, more so than quality

versus desktop graphics tools, which tend to be optimized for quality

either 1 or 2 is a valid approach

but you will need to do your own testing to see which one gives you results that you like

as only you know what you like

Gotcha. I guess I'll try both and see what works for me.

but in terms of scaled images for different densities, you apply the same algorithms for a 349 x 304 image as you would a 48 x 48 image

Okay, I guess I will just try it myself.

"Hero images" http://www.google.com/design/spec/style/imagery...

That seems to be what I'm referring to.

They make those apps look so nice, but I'm just afraid trying to include images in my apps will be the end of me.

more generally, "hero elements", as they might not always be an image

Yeah, I feel like I'm going to encounter more and more images though. But okay so that solves my first issue.

Second issue is that I have a project that is using GCM.

It's in Android studio, so I have two different build flavors. Production and beta.

I set the applicationId in the build.gradle file to two separate package names. com.myapp.prod and com.myapp.beta

Now at the top of the manifest there is a declaration for the package name

I only have one manifest in my src/main

any time I try to change the package name my app complains because it messes with importing R.java.whatever

But for GCM permissions I have to use the proper package name so I'm just kind of lost on how I should do it so that I don't have to change it manually each time.

probably via manifest placeholders

I think I may have even used GCM as an example in my manifest merger chapter

Aha. Didn't know about that.

for your permission-related manifest bits, you'd use something like android:name="${applicationId}.C2D_MESSAGE"

which would pull in your applicationId from Gradle

So what do I do for manifest tag package name?

Because whenever I touch that, my java files complained.

then leave it alone

if you are overriding the applicationId role of the package name in Gradle, then the package name is just for code generation

R and BuildConfig

Hmmm... makes sense I guess.

II liked how in eclipse I could make a member variable or a method private from public and I could see all of the affected java files live in the project directory. It doesn't work like that in Android Studio. Any idea why and if there is a way to make it behave like eclipse in that regard?

no clue

sorry

but I'd check the refactoring context menu and see if there is some sort of "change visibility" option that may give you what you want

Okay. That just about does it for the two issues I ran into today.

Any other big updates you have left for your book? I'd like to read it once through fully but now that it seems you big pivot is complete I'll start. Any other big changes planned?

that depends on your definition of "big"

Android 5.0 coverage will stream in over the next few updates

that won't affect the core chapters too terribly much

Besides what you usually post as a "changelog" is there any deadsimple way to read what exactly was changed between two versions? Almost like a git diff?

the table of contents shows sections with changes in bold-italic

the prose itself has changebars on the right to show the specific paragraphs/bullets that changed

Okay I'll look into that. I just want to make sure I don't miss anything.

Some random questions I'll shoot off since no one else is here. Everything done in widgets ends up being rendered in OpenGL?

not really

it is rendered by the GPU

but not using OpenGL

Can using any Orm db library perform queries faster than just plain sql that I can do myself? Kind of tempted to go toward Orm but I'm fine using raw sql statements

by definition, no, as it is doing the same SQL you could do by hand

so, the optimal hand-rolled SQL is as fast as the ORM, without the ORM overhead

however, not all developers are skilled at creating optimal hand-rolled SQL

Okay. I think that is all for me for right now. Thanks mark. see ya sometime in november!

have a pleasant day!