There are a few important points related to that project. It’s constructed with a reactive architecture using RxJava 2 and Android Architecture components, running on iOS. Yesterday, we updated the Android Architecture components to RC1, which was recently released.
The Xcode side of Doppl’s build system has been greatly simplified. Your code and dependencies are all wrapped in an Xcode Framework that Swift can call. No bridging header or manual management.
Obviously, the Android community has been talking quite a bit about Kotlin. I won’t get into that. It’s cool, but let’s call it well handled by others. I’m going to talk about what’s showing up in the Kotlin/Native samples folder!
My particular career focus has shifted dramatically in the past 1–2 years and is pretty much on code sharing and how we’ll be pushing pixels for the next decade (ish). I don’t know exactly how things will shake out, but we’re talking to a lot of people who are trying different ways to not build the same thing over and over again.
We have built Doppl. It’s a mobile code sharing tool. It is interesting now because it’s available now, and will fit well into a lot of contexts. It’ll be a bit, but you will be able to code Android, JS, iOS, and apparently sooner than I thought, webassembly, with Kotlin code. If we had a current “focus”, those two would be it.
We’ll save the “yeah, but what about ____?!” discussions for later. Assume there will be multiple “things”, and not everybody is going to agree with you. That’s how people work.
I’m speaking at a Swift conference in November, and my talk is basically saying the web and Android communities are working on their answer for other screens. The Swift community should do the same.
This sample is not what I’d call “practical”. You can’t use this today. However, it’s the first Webassembly thing I’ve ever built (I just built the sample, and did a little Kotlin tweaking to make sure it actually worked).
It takes a while to load. Like I said. Not practical today, but assuming you’re on Chrome, this works (haven’t tried other browsers).
Kotlin Native can “mount” Objective-C headers for interop. The sample compiles and runs on iOS, which is cool, but hopefully, for you can build a separate library that can be referenced from Swift, etc. I keep advocating this because I think it’ll be very important for adoption.
This is all very neat stuff! It’ll be a while before the tooling allows you to be productive, but it’s coming.
We’re going through and updating Doppl libs and sample apps. J2ojbc updated to 2.0.4, which caused some minor incompatibilities with existing Objective-C code. That required a redeploy of a number of libraries.
Future versions will package the java directly in the dependencies rather than the translated code, but for the next few months, we’ll be working with 2.0.4 and locking down the libraries and versions.
I updated a bunch of the architecture code to actually use reactive features of Room DB. The tests aren’t updated yet, though. Just fyi.
Droidcon app update coming soon. Before end of week (ish).
We’ve had a lot of feedback on the technical preview. Next up on the todo list:
Finishing RxJava 2. It works, but needs some tweaks.
A little more work on Retrofit 2. Some error states don’t do the same thing as they do on Android.
After that, Xcode help. It’s difficult to manage for Android devs.
Gradle plugin needs some fixes. It does not do well with project dependencies. Also needs to handle Android library projects better. Can only deal with plain Java and Android Application modules. Compile failures can be difficult to find root cause.
In the middle, whenever Architecture Components get to v1 we’ll need to create an “official” version.
In the longer term, evaluating Kotlin as a potential alternate platform. They’ve been making a lot of progress, and many folks are working on Kotlin-only libraries, so should be viable in 1–2 years.
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.
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.
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.
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.
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.
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.
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 Dopplto 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.
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.
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.