I don't see ePub or kindle versions, only PDF.

Are those coming or discontinued? They were a part of the MEAP, and are very handy...

Maybe I'll learn to read by then. smilie

Can these people be blocked or what? The last week's posts are all spam. :-/
I don't see any examples there that use native libraries - is there a known good way to do that?
Thanks Benjamin, this turned out to be a bigger problem because of the state of a few things:
- dex (a packaging tool for android)
- gradle-android-plugin
- Android Studio

I'll share the story here in case someone comes after me on this path. smilie

I have a vendor-provided API for video DRM that includes debug and release jars and so files for armeabi and x86 processors.

The dex tool doesn't appear to correctly bundle "*.so" files, it only seems to want to work with "*.jar" files. So including the "*.so" file as a "compile" dependency appears to be a fruitless effort - I tried several things, but no luck. It's possible that there is a trick to make it work other than the following, but I couldn't find it.

As a workaround, you can bundle your SO files into a jar file with a structure like this:

- /lib/armeabi/libWVphoneAPI.so
- /lib/x86/libWVphoneAPI.so

So that eliminates the need to add the correct lib for the CPU type - no need for product types "x86" and "arm". A single APK will contain both.

Next, I had to find a way to do Debug and Release versions of those (and the associated jar files).

The gradle-android-plugin allows you to do this:

dependencies {
 compile 'com.android.support:support-v4:18+'
 releaseCompile '...'
 debugCompile '...'

Since I had debug and release flavors of the vendor files, I could do that, and on the command-line, it worked perfectly.

When I imported the project into Android Studio however, all manner of things went crazy.

First, the dependencies weren't found - it couldn't comprehend the releaseCompile and debugCompile settings - so it complained that the Java API from the vendor jar file was undefined.

Correcting that by adding the dependency in Android Studio also changed my build.gradle file, but it only added the jar file with the Java code, and discarded the jar file with the SO files. I assume that is because there's no Java code in them, so it assumed they were unneeded.

I may try unzipping the jar files with the Java API and repackaging it with the added so files (in /lib/armeabi/libBlah.so and /lib/x86/libBlah.so) to get to a single jar file that contains both the Java code and native code in one file. I think that might solve the problem and make it work with both AS and command line nicely.
I think you're probably right - it's unfortunate that the docs for android are still so sketchy. Hopefully the rest of the book will make gradle clear enough that people can figure it out.

Looking forward to trying it more.

Thanks for the reference!
Wow, perfect timing! I'm migrating a project this week! smilie I'll share this info with my team.

OK, that seems to work pretty well, thank you!

I would like to take my particular scenario a step further.

I have native code provided by a vendor, it comes in 4 versions:
- armeabi/debug
- armeabi/release
- x86/debug
- x86/release

So I'm thinking I want "build" and "release" build types and "armeabi" and "x86" product flavors.

Now, I'd like to include only the correct combination in the builds.

Is that possible? I can't seem to find a way to do that...
Excellent, I'll try that...
This needs some clarification:

"Every Android project ships with Gradle as the default build system."

Looking at the android SDK, this isn't the case:

larry-mbp:samples lmeadors$ pwd
larry-mbp:samples lmeadors$ find . -iname "*.gradle"
larry-mbp:samples lmeadors$

What Android projects are you talking about here?

I'd LOVE to see some Android projects that use gradle in the book or sample code. An appendix on this would be REALLY valuable - all the samples I've see in the wild are miserable...
This chapter seems like a good start, and maybe the topic's too big to fit in a chapter, but it would be awesome to see it extended to show more how to react to events that are not necessarily user triggered.

As an example, instead of a splash screen where be shutdown the app if offline, an activity that was aware of the network status and reacted to it might be more useful.

IMO, the real benefit of the MVP pattern isn't really obvious in the example in the book because it's such a trivial use case.
Would it be useful to inject the presenter into the view using the intent?

That way, you could mock it in your instrumentation tests.

Wow, it's been a couple of months, and you may have gotten this answered already, but just in case you haven't...

The DAO is deprecated, but not going away - it will continue to be available on the site for the foreseeable future.

That said, while there are 2 chapters in the book on the DAO *pattern*, only one of them talks specifically about the iBATIS DAO - the rest is just about how to apply the pattern, and there is even a very *brief* intro to using Spring for your DAO (which is the recommended way to go now) as well as a discussion on how to 'roll your own' DAO layer.