hello, Paul!

how can I help you today?

Greetings. Nice to chat with you again.

Let''s talk about the ConstraintLayout artifact.

And how to obtain it as a Gradle dependency.

Even more generally, do you have any insight into why Google just doesn't put all of their dependencies up on Bintray or Maven Central rather than in the SDK?

licensing, as I understand it

while everything(?) in the Android Repository is open source, they still force you to agree to non-Apache license terms to use it

Ah, that make some sense but is not very satisfying.

I can't defend the indefensible :-)

I'm going to read your link ....

I scanned the issues but they appear to be a little different than mine. My experience is that it appears that new versions of the library get released without me being informed by Android Studio. Also I see what looks like bugs related to using library modules with conflicting versions in the build.gradle files, fwiw.

Was that clear to you?

well, since neither Android Studio 2.2 nor ConstraintLayout are in release form, I'm not shocked that you're having a problem here

file an issue, if you can reproduce it, or see if one is already filed

Good point.

Do you document using ConstraintLayout yet in your book?

not yet, as it is not in release form yet

sometime this fall, I will be covering it

it depends a bit on the timing of when they ship those things

on the whole, outside of new platform releases (e.g., N Developer Preview), I try to minimize how much I cover of pre-release stuff

Probably a very wise approach.

I have little enough hair to waste it, pulling it out to deal with pre-release stuff :-)

:-)

What is your current thinking on the topic of Firebase and your book?

I will not be covering it

pretty much the only services that I cover are ones where self-hosting is an option (e.g., ACRA)

for example, I'm working on an OpenStreetMap chapter now, as a counterpart to the Maps V2 chapter

about the only thing that I might cover that's a bit Firebase-y is their job-dispatcher library: https://github.com/firebase/firebase-jobdispatc...

and that's only after I create some plugins to provide non-Firebase options

On another different, but Android topic, I recently decided that my app was getting too big from a structural perspective. strings.xml was out of control. I concluded that moving some key Activity classes would be better served as separate library modules (like for sign in and an intro screen). Have you wrestled with how to keep an app structured so that it is reasonably easy to maintain?

"strings.xml was out of control" -- note that filenames in res/values-*/ are irrelevant, so you can split your strings and other values resources into whatever files you want

strings.xml is a convention, but you could have strings1.xml and strings2.xml

or whatever sort of organizational structure for them that you want

Is that your solution to encapsulating funciionality?

no, I am just mentioning it with respect to that portion of your question

(pardon my typos)

the only reason I split things into separate modules is for clear technical reasons: the module started somewhere else, the module is reusable, the module is a different app, the module is maintained by somebody else, etc.

however, I have not worked on million-line Android projects, either

personally, I haven't had a problem with maintenance due strictly to size, so I do not have specific advice with respect to your concerns

Paul: let me take a question from Ivano, and I will return to you shortly

Ivano: your turn! do you have a question?

My current gig started out from scratch. A rare experience based on my career. The previous gig was a half-million line library (Brightcove's native video SDK).

Hi Mark and Paul, I am mostly in peeking mode. the question wanted to ask you regarding shadow$ klass found a solution in SO http://stackoverflow.com/questions/26933888/wha..., for the rest Mark, not questions at all because the RXJava thing is really big and have to catch up with. I guess...

Strange that you should mention RXJava. I'm wrestling with this mightily. My gut feel is that it is an emperor with no clothes, but I could easily be wrong. Mark, do you have an opinion on RXJava?

Paul: I think there's a strong element of "it's what the cool kids are using"

Amen to that.

Paul Reilly: is something powerful will make retire async task

I was planning on covering it late this year or early next, now that we have Java 8 lambda support

junit easier, less verbosity, amazing synergy between functional and OOP , complex multithreading made easy, are K reasons to think over a revolution

I've been a functional skeptic for over 20 years, maybe 30 now. :-) Best I can say for it is that it just doesn't want to die. :-)

and now all these dependency injections. It looks like Android in 1 year will be completely another language to me. Restrofit2+RX Java is becoming a standard IMO

Paul--> :)

If Oracle keeps being a pain in Google's butt, in another year we could be using Swift, although Go would be my preference.

Paul: that's not an issue; otherwise, Google would not have switched to OpenJDK

Bottom line, it will be fun to watch and see how this all plays out.

IMHO, Google and Oracle have "buried the hatchet" for the future, and the current legal stuff is mostly for the past and for establishing legal precedent

if SWIFT will be standard ios developers will have huge advantage on us

at the 2016 I|O conference's Android fireside chat, neither Google nor the audience had much interest in Swift

Kotlin had greater audience interest

god bless intelliJ

What are your takes on Kotlin?

it's not horrible, but IMHO it's also a case of "all the cool kids are using it"

long-term, most likely it will go the route of Scala, Clojure, and other attempts to replace Java on the JVM

yes please!

Woe is me, never having been a cool kid. :-)

what I see as a game changer is firebase instead, it looks big G is investing a lot

I like Firebase but I think it will suffer from a scaling problem. If Firebase gets you pretty far and then you can smoothly roll over to AWS, GCP or your own back end service, then it is OK. Beware the panacea.

too much at stake to not make scalable.. the future of digital marketing could lie there

God willing, that I discover Firebase does have a scaling problem. :-)

I attend GCP meet-ups in Cambridge that are run by a GCP product manager. He hardly knows what Firebase is. I found that very strange.

i guess corporations will prefer ad hoc system for security reasons

This is a Google Cloud Platform product manager. I would think Firebase and GCP would be parts of a Google corporate strategy. Then again, it would not be the first time the left hand did not know what the right hand was doing.

and Google has lots of hands

well as we are asking mark opinions

I would like to know from you and Mark about VR.I mean it will be undisputably the next big thing. Will be learning native C/C++ essential for android developers?

"I mean it will be undisputably the next big thing" -- oh, that's very much in dispute, at least for some values of "next big thing"

in certain areas (games, perhaps education), it may become big

OK thanks

"Will be learning native C/C++ essential for android developers?" -- only until some frameworks are created that allow for VR development in other languages

(true I was too much dogmatic)

yes like I am waiting brillo since almost 2 years

for example, I think Unity 3D allows development in stuff other than C/C++ (C#, JavaScript listed on their site)

The whole notion of wearing a device only works for me in the realm of playing games, maybe education. That said, I have seen some very impressive demos of Project Tango that require no contraptions.

that's a wrap for today's chat

the transcript will go up on https://commonsware.com/office-hours/ shortly

Enjoyed it.

the next chat is Thursday at 7:30pm US Eastern

have a pleasant day/evening/other time unit!