Communication Breakdown

Communication Breakdown

(Crosspost from

There’s a really great blog post about code sharing from the Slack engineering team. If you’re into this kind of thing, you should totally check it out. I really like the focus on the why’s of decisions. About language, what is/isn’t shared, etc.

There’s really a lot of good info to unpack here, but I want to comment on one part specifically. I’ll confess, I had originally skimmed the post and wrote my post as a “yeah, but”. Before hitting “Publish” I went back and read it fully, and am now changing this to a “right on!” with a bit of “yeah, and” thrown in. The Slack team encountered and addressed the issue I was going to discuss. This issue extends beyond just “shared code” and comes up in many areas of large product development.

It’s the built-in, one-way conversation of delivering a packaged bunch of code that the downstream team can’t edit.

In my experience, having specialized teams and parts of code is good, but having siloed teams and code is bad. Or at least it’ll make some things more difficult. Specialized means, in this case, the shared code developers do the majority of shared coding, and they “own” the shared code, but other developers can debug, edit, and commit code back. Siloed means they can’t. It means code is developed, verified, tested and delivered and can only be run.

LibSlack started as siloed, but became specialized.

The difference is subtle, but critical. It means your upstream team needs to be a lot more correct, or you’ll impact downstream. And just to be clear, since your upstream team is not omniscient, they won’t be always “correct”. Mobile developers should have a visceral sense of this already. It’s the server api team vs the client dev team. Not being able to run the server locally and step into/edit the server code creates a significant bottleneck for development. The api team will often not give you every piece of data you need, or create a multi-step operation that will present transactional issues in a mobile context with questionable connections.

That same type of situation will present itself if you’re siloing your shared code, for the same reasons.

Sometimes you need that separation. As systems are serving large existing customer bases, you have many devs, etc. However, if you have that separation, the upstream team needs to be a lot more correct all the time, and when they’re not, the downstream team generally needs to wait weeks.

Code is a form of communication.

Even if the downstream team can only push PR’s, and they’re always rejected as a matter of doing business, editing code and submitting PR’s is a method of communication. Rather than a meeting or a google doc (or a Slack message 😜) explaining what you’re thinking, a code diff can often say what you’re thinking in a much more clear fashion.

That, of course, impacts more than just your repo design and development process.

Choice of shared language will be impacted by the desire to let other devs edit the shared code, as well as training and recruiting.

We’ve generally avoided C++ as a shared code recommendation because C++ is a pretty scary language for lots of people (myself included). On some level C++ feels like, “Hey kid! Here’s your memory. Don’t hurt yourself…”. The other shared code extreme is Javascript. While I wouldn’t exactly call the structure of Javascript “safe” in a lot of ways, you can’t mess up threads, and pointers aren’t a thing.

If there’s an overarching message about what the shared code landscape will look like in the near future, it’s that there isn’t a best choice for everybody, and a lot of options in between the extremes are coming along.

Not that Slack shouldn’t use C++! Sounds like they’re doing an amazing job solving the problem.

Wonder how Rust would’ve worked out, though…

Well, the interop works but could use something like Djinni. Have to look into that Djinni situation. Interop is hard. That’s another overarching message. Lots of messages.

Code Sharing Research

Code Sharing Research

(Crosspost from

I never finish blog posts because I treat every one like it’s some grand research paper that should also touch you on an emotional level. I have again been told to just ship the little thought every day. Here’s today.

I’ve been pairing down the things I think will be important in the future for app development, which includes web. It’ll be kind of a 2+1 situation (2 mobile + 1 web), although I guess if reasonable, should do “native” desktop.

Most of the stuff gaining eyeballs is coming from the web world. The web world has been predicting native’s demise since native became a thing. So was I, till Facebook threw in the towel. I now think not having a mono-platform can be a good thing, and we should focus on being able to reasonably share code between them, and not get locked into English just because all the tourists are Americans.

Yes, that’s a shitty jab at Javascript.

Rather than getting into the identity politics of platform, I’ll just say I think there’s room for options. There’s no “best” way to do it.

I *do* think the trend of coming *from* web to mobile is not always great. I think the tech should push the other way. Mobile to web. “Offline first” works perfectly fine if you’re never offline. The other way around, not so much.

We’re separating the areas where one might share code into 3 tiers. UI, “biz logic”, and architecture. The last 2 often get lumped together, or solutions I see tend to be at extremes. Just biz logic, or EVERYTHING. This is interesting to me. For mobile specifically, architecture is a hard problem, and under the UI, iOS and Android are basically the same. Sharing architecture and biz logic gets you a lot of mileage for free.

Anyway, will expand on all that (in a different post). What I’m looking at now.



If you know me, then you know this. I’ve been doing this for a while. It’s Doppl. Just go read that. The sample needs an update, which I’ll hopefully get to today, but its *really* nice out. Anyway. There are a lot of meaningful benefits to be found there, but I also see this as more of a bridge solution while other situations improve. Not that it should go away eventually, if it’s useful, but there are things coming that are a little more purpose-built for sharing.



Swift is a good language. You *can* compile it to Android, although somebody needs to write an interop layer. I can see how this would work. It may exist, but if I go google this now I won’t finish the blog post. If it does exist, its certainly not popular.

Swift has a large community and set of libraries. Swift is also becoming a great back end language. However, until web assembly becomes a serious thing, I don’t see much client web coming (swift for JS?). Essentially on the UI, its just Apple hardware. That makes obvious sense, but the community should be cooking up other stuff. I’ll be speaking at a Swift conference about that.



I first heard about Kotlin back in 2011, and we started using it in 2014. It’s great. However, nobody else was using it much, and I got very into Doppl, so I wound up in the reverse commute situation where everybody else got into Kotlin right when I was getting out of it.

I had avoided the concept of Kotlin as a shared language mostly because I was a fanperson deep down, and assumed I’d over-love too many of its plusses and ignore too many of its cons. However, if you’re a Java-ish shop, and that’s most of the world (kind of), this could be an amazing solution.

Java server code and Android code are a done deal. Not much to say there.

The JS code is, I’m told, really solid.

Kotlin native is going to take some time to finish, but Jetbrains is very serious about it, and the demos so far are pretty compelling. I hope they allow you to build a library that you can call from Swift/Objc rather than a full executable. That would be dog cookies.


Kotlin shared libraries on iOS would be the cookies. I’m the dog.



Sometimes you finally look at a thing that people are talking about and realize you don’t listen to people enough. I don’t know how easy actual coding would be on Rust, but I intend to find out. Just reading the basics of threading and safety is really exciting. I don’t 100% understand it, but I do understand the problems in other language contexts well enough to get the hint that they’re onto something.

I ran through a demo that compiles down to iOS and Android. I wouldn’t call it simple to do, and the interop code was certainly verbose, but both of those things can be solved with tooling and training. The lack of a runtime bloat was amazing. The library was super, super small on iOS. That was the big surprise. Also, since it makes libraries, you can share code relatively seamlessly (minus boilerplate, as mentioned).

Intellij has a decent plugin. Just make sure you’re on the newest Intellij (spent a while figuring out my mac doc was pointing at a very old version, but I digress).

I doubt the architecture side would be easy to share now. iOS/Android have very robust libraries dealing with mobile architecture. I assume if your language isn’t doing a lot of mobile, it probably doesn’t have a lot of mobile architecture libraries. However, that’s what coders do. Build things.

Obviously the web with Rust is problematic right now, but apparently, Rust is also one of the few languages that can output web assembly right now. I saw a post on that. I still don’t really believe it, but that’s what I read. Will need to verify. In any case, if not right now, very soon. It’ll be a while before there are threads and other things is wasm, but they’re apparently on the roadmap. It’s possible that wasm will just kind of fizzle out, but if it doesn’t, a whole lot of things might be changing in the (relatively) near future.

Anyway, Rust seems cool.



It’s hard to gauge how likely folks are to adopt a new language and/or platform. In the iOS and Android worlds, the community seems very receptive to Swift and Kotlin, respectively, but especially in the case of the latter, there is a disconnect between the “community”, which is for me the folks that actually bother to go to conferences, who are very much a self-selecting group that is excited about new things, and the bulk of the developer ecosystem. I don’t think there’s going to be a quick, wholesale move to Kotlin from Java, even though you can pretty much say Kotlin is better (drama!).

Similarly, we’re having lots of conversations with larger companies looking to consolidate their platform efforts. Although there may be better options, it’s a real struggle to push their existing teams to anything other than a web-like solution.

So, maybe Rust winds up being awesome, but a lot of orgs will wind up with React Native because the career engineers don’t really want to change everything, and maybe that’s not a problem. Depends on the situation.

One of the benefits of the Doppl stack, and soon Kotlin as well, is the possibility of having an existing Java server team also start working on the client architecture, to better design APIs. There are *a lot* of large orgs with large teams of career Java people. We’re experimenting with a split whereby those engineers kind of own the architecture from the cloud through the client, and other folks are focused on delivering UI on top of that to the various platforms. See how that goes.



Right now this is a “don’t even go there” topic for me. Trying to have a unified UI on multiple platforms has never really gone well. There’s enough to work on below the UI, so I haven’t been thinking about this too much.

However, I *do* think what Facebook is doing in this area probably makes sense. Not the detailed libraries, but just the general “flexbox everywhere!” approach. Even if you’re largely replicating your UI code, having the same mental model for it will make things easier, rather than having several totally different ways of laying out your screen.

No real insights here. See how it goes.


In Summary

Nothing. Just need to wrap up the post and ship so I don’t overthink it. Its really nice out and we’re taking Binky for a lunch.


Binky is a dog, named after a horse

Droidcon App!

Droidcon App!

Happy birthday!

(Crosspost from

We’re gearing up to have our 4th year of Droidcon NYC! The talk selection committee just started voting, and we have an excellent lineup. Should be a great event.

Because we’re a mobile dev shop, and mostly an Android shop, we’ve launched an Android app for the Android conference each year. Last year we used Doppl to create an iOS version of the app as well (Apple is pretty serious about not having Android in the app store, though).

It’s his birthday, btw.

The current version of the Droidcon app started back in 2014. We used some early Kotlin, way way before that was a “thing”. However, in 2017, it’s some pretty old looking Kotlin. We also used some libraries and architectures that aren’t exactly current “best practice” by Android standards.

There were also zero tests. So, you know.

We want to have a nice, public example of a well designed Android app, the very modern architecture of which can then be used directly in iOS. We also want to train some more of our team on Doppl, and figured we’d do it publicly.

Keep an eye on the Droidcon example app. We’ll be modifying a few things over the next few weeks.



Back in 2009 or so, I was the person who did the Android port of ORMLite. In 2015 I wrote an annotation processing update of that. We used it internally, but there were too many DB libraries already, so it’s kind of abandoned. We’re moving the DB to Room (or maybe SQL Delight. See how it goes).



I wrote a threading task queue a couple years ago. It was designed to be simple, and also implement a persisted queue for offline support. Everybody has kind of moved away from the “event bus” model over the past few years, so the non-persisted tasks will be implemented in RxJava 2. The persisted stuff will be backed by the Android Priority Job queue. Fun fact, Yigit did that and the Room DB stuff. Thanks, Yigit!



The current app uses Retrofit v1. Doppl doesn’t have Retrofit v2 yet because we need Okhttp to support ssl, or we need a different call client. We’re going to move the Droidcon app to Retrofit v2 to sort of force the issue and prioritize sorting out the Retrofit v2 situation.


General Architecture

We’ll be moving to the new architecture components, but probably using Rx instead of LiveData. I’m not sure right now how much of that will make sense in an iOS context. Obviously, we’ll need some implementation of the lifecycle stuff, but it won’t mean as much. That’s all still TBD. The general idea of Doppl is to move as much code as possible into the shared space, though, so hopefully, the architecture code makes sense.



This year’s app will be simpler than previous years. We’re removing the “login” requirement. It doesn’t make all that much sense. The only feature loss to the user will be a lack of sharing RSVP’s between devices, which seems ridiculously unnecessary. This will simplify the code considerably, but should still deliver similar functionality and UX.

Thanks to Peter Chislett.

Doppl Technical Preview

Doppl Technical Preview

(Crosspost from

We’ve been working with J2objc for over a year, and on the components that would ultimately become “Doppl” for much of that time. Until late last year, this was mostly an internal tool, but after some successes we decided this should be a “thing”.

Our “release” has been perpetually “soon”, and if I got to put everything I wanted in there, we could figure on 2019 or so. However, we want some feedback and maybe some library help, so it’s time to put it out there. The “technical preview”. The “Alpha”.

To be clear, the Gradle plugin, and to a lesser degree our extended Android library, is at an early stage. The underlying tech, J2objc, and much of the implemented libraries, are mature and functional. We actively produce production code for clients with the tools, as do others. You can build apps with this.

We have an extremely rough roadmap for the next few months. This is subject to change as feedback comes in. In summary form:

  • RxJava 2
  • Retrofit 2
  • Xcode framework packaging (Carthage, etc)
  • Okhttp
  • Full mockito support


These are non-trivial tasks, or we probably would’ve pushed on this release and done them. RxJava 2 is in process, though, and there’s traction on some of the other ones. Anyway ….

Check out the website. Join the Slack group, mailing list, follow the twitter, or just keep an eye on the Medium publication.

And, sure, hiring. Mostly looking for a mid/senior Android dev who wants to work with custom hardware, but also people who like the Doppl thing.

Then, of course, I should mention Droidcon NYC. CFP ends Sunday, July 9th at 11:59 pm. For the procrastinators.

Work at Touchlab

(Crosspost from

Hello! We’re hiring great Android folks, here’s our website. But so is everybody.

I wanted to put in a personal note about what’s going on here and why you’d want to come join the team.

We’re releasing the Doppl thing (below), but from day 1 Touchlab has been very Android-focused, and that isn’t changing anytime soon. If your goals include working on the bleeding edge of the Android ecosystem and teaching/learning/defining best practices, we need to chat.



Doppl is an Android-centric code sharing platform. Like an actually-native React Native. Read about it here, here, and here. We’re locking down our first big clients now and opening up the source in a couple weeks. We’re also going to need to refresh the Droidcon NYC app to use RX, Room db, and other things. So there’s that.



We’ve been doing Kotlin for a few years. We’ve only been putting Kotlin into the client projects for the past year or so, but now that Kotlin is “official” it’s an easier sell. Doppl is Java, so it’s not like we’re all Kotlin, but it’s happening.



If you want to work on custom AOSP-related hardware, we’re doing some of that too. Highly visible stuff. In fact, that’s our most immediate send-your-resume-yesterday need. It’s really fun stuff, and if this is the kind of thing you’d like to work on, please reach out immediately.



If you’ve never heard of us, we run the big NY Android meetup, as well as Droidcon NYC. Networking is good for you. Also, consider submitting a talk.



We have a VR room with a Vive, which has nothing to do with what we’re working on. Yet, anyway. We do group outings, offer outstanding benefits, and have surprise cookies and scotch. You can maybe bring your dog to work. It’s a tech company.



We’re a consulting company, but we’re a really, really interesting one. Reach out.

Android’s Room Db on iOS

Android’s Room Db on iOS

(Crosspost from

I’m stuck in NYC because of prior commitments, watching all the fun at I/O. That’s OK. Some interesting stuff came out yesterday.

TL;DR One of the reasons we’re pushing Doppl is because you can include popular libraries easily. It took about 90 minutes to get Room running on iOS. Clone this and try it out.

The “traditional” Android docs from Google were promoting tools and concepts that pretty much nobody was using anymore. ContentProvider (for same process data), AsyncTask, Loader, etc. The new architecture stuff looks like a good step forward that incorporates much of what the community has been promoting for the last few years.

I’ve done a lot of Android DB work over the years. See blog post from talk for more info. As we just released a blog post about Doppl and Android architecture on iOS, I figured I’d see if we could try Android’s new Room db framework on iOS. That should be pretty simple. The lifecycle stuff will take some more surgery, as parts of that framework incorporate Fragment and Activity, and I assume portions of that won’t make sense in an iOS context, but I think that’ll work out as well.

I don’t think the source for the new architecture stuff is available yet, but it is if you know where to look. Sorry in advance (but the pom says apache, so…).

I think I’ll do a longer blog post later about Room compared to other db libs, but the short version is it’s an interesting addition.

Converting to iOS was pretty straightforward. Converting the sample app to Room probably took a little longer, but was simpler because there are docs 😉 Do not try to use this for anything other than running the sample. I found the source, but not the tests, so I wouldn’t call this production ready.

Also, yes, I know the sample app does I/O work in the main thread, but it’s a sample app. I like that Room forces you to declare that in the builder.

Clone the sample app and look for “TheRoom” branch.

As always, hiring.