More Related Content
What's hot
What's hot (20)
Similar to Doppl Code Sharing
Similar to Doppl Code Sharing (20)
Recently uploaded
Recently uploaded (20)
Doppl Code Sharing
- 3. copying iOS apps since 2010!
- 4. Cross Platform = 🚮
- 8. Our Position
- 9. Mobile 1st means Mobile Leads
- 10. Mobile 1st means Mobile Leads
- 11. There will be multiple solutions
- 12. Pick something
- 13. I Can’t See The Future
- 14. It’ll Be OK
- 15. Zooming in…
- 17. J2objc
- 20. JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito J2ObjC
- 21. JRE (lang, io, util, etc) Android (Log, ?) Gradle Plugin Library Format JUnit Mockito J2ObjC Doppl JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito
- 22. JRE (lang, io, util, etc) Android (Log, ?) Android (Context, SQLiteDatabase, Threading, Shared Preferences) JUnit Mockito J2ObjC Doppl JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito Gradle Plugin Library Format
- 23. JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito J2ObjC Doppl JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito Android (Context, SQLiteDatabase, Threading, Shared Preferences) Gradle Plugin Library Format Testing Support
- 24. JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito J2ObjC Doppl JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito Android (Context, SQLiteDatabase, Threading, Shared Preferences) Gradle Plugin Library Format Retrofit RxJava RxAndroid Gson Dagger SQLDelight Room DB Android Architecture etc… Testing Support
- 25. JRE (lang, io, util, etc) Android (Log, ?) Android (Context, SQLiteDatabase, Threading, Shared Preferences) Gradle Plugin Library Format Retrofit RxJava RxAndroid Gson Dagger SQLDelight Room DB Android Architecture etc… Testing Support Xcode Support JUnit Mockito J2ObjC Doppl JRE (lang, io, util, etc) Android (Log, ?) JUnit Mockito
- 30. Android and iOS Same methods, different names
- 32. Fractivities Architecture Components Looper, Handler, Message Queue Retrofit SQLite (Room, etc) java.io.File Android Android Native Stuff Easy To Share
- 33. Fractivities Architecture Components Looper, Handler, Message Queue Retrofit SQLite (Room, etc) java.io.File Android ViewControllers Architecture Components Looper, Handler, Message Queue Retrofit SQLite (Room, etc) java.io.File iOS Android Native Stuff Easy To Share iOS Native Stuff
- 34. Not Sharing UI
- 35. Great in some domains, but…
- 36. Don’t Stare
- 38. One UI by design
- 39. Why Doppl? Points of Interest
- 40. Smooth Interop
- 42. MVVM on iOS
- 48. Main
- 49. Main Test
- 56. Do UI Shit
- 61. Do UI Shit
- 70. Kotlin
- 71. C/C++
- 72. Assembly
- 75. Native Tools are Best
- 76. Platform Tax
- 77. November
- 80. November December January February
- 81. November December January February March?
- 82. Which takes longer to build?
- 83. The first platform takes much longer to build
- 84. Platform tax is on everything
- 85. Doppl has no tax Iterate product on android Share logic and architecture to iOS
- 88. Star folders are awesome, right? Sure!
- 89. Cooperative Sharing No Big Decisions
- 91. 2 Native == No Risk
- 93. OK, but should Android devs care?
- 94. Your Team
- 95. Community Level
- 96. Kotlin
- 97. JVM JS Kotlin
- 100. NativeKotlin
- 101. Kotlin Kotlin Lib Kotlin Lib Kotlin Lib Objc Lib UIKit (Objc) Foundation (Objc)
- 102. Kotlin Kotlin Lib Kotlin Lib Kotlin Lib Objc Lib Swift (or whatever)
- 103. Kotlin Kotlin Lib Kotlin Lib Kotlin Lib Objc Lib Swift (or whatever) Callbacks
- 104. Kotlin libraries need to be native friendly
- 105. When?
- 110. JotlinAPK Swift iOS App Kotlin Java/Doppl Android iOS
- 111. JotlinAPK Swift iOS App Kotlin Java/Doppl Android iOS Java/JNI/C++/Rust Objc/C++/Rust
- 113. Check out Rust
- 114. Mark Murphy Fixing the docs
- 115. http://doppl.co
Editor's Notes
- Hello! ⅓ Doppl Some ecosystem and advocacy
- Building mobile, 2 incompatible ideas 1. Programming is basically the reduction of repetitive work 2. We’re repeating a lot of work Not unqiue to mobile Mobile scale is unique Games is close, but games has 1 UI, which I’ll talk about later
- I am Kevin Galligan. Android since 2008. Started touchlab in 2010. Just Android till the last year or so. Most of our work is “copy iPhone app”. Understand the mechanics and math of copying code.
- Hitting this right at the start. Cross platform tools suck. We all kind of hate them. At the same time, I think most of us have been expecting the situation to change at some point. I think that’s kind of now, or really starting before now. Background environment is changing, and better tools emerging. Part of this talk is reframing your thinking.
- We’ve heard “cross platform is coming!” for years. After a while it’s easy to believe that’s not true. There’s a lot of shit out there. Change will be gradual, so it’ll be really easy to not notice. It won’t be like Flash, where the market just decides its over.
- Mobile is mature. There are 2 platforms, and the web. 2+1. That’s it. Years of stability. Developers have time to iterate We have very forgiving devices Millions of apps. Billions of hours of dev time. Things will change.
- Most of the solutions are coming from the web. That should be obvious. Many more web devs. They’ve had a decade to work on this. React Native, and anything Javascript, is web Guess what? It’ll probably mostly be web, because it’s mostly web devs, however
- This is a summary of our position on the topic
- Name of talk I’m giving at a Swift conference. We’ve been working on architecture and frameworks for years for mobile. I don’t think the “solution” should automatically come from the web. Everything doesn’t need to be Javascript. Not saying web dev sucks. There are amazing and interesting things happening on the web. There’s also a largely different set of assumptions and restrictions. It’s possible I’m wrong and mobile turns into one big web things, but…
- If your team is mostly web devs with React experience, React Native. Of course. Discussion turns into “what about this”, or “why not that?” “What’s wrong with React Native?” “I don’t think you understand React’s model”, “Why do you hate Javascript?” Since this is a Googley crowd, “oh, you should use Flutter” “Everything will be Flutter soon”. “Oh, what you’re building is like Flutter, but Flutter has…” There will be multiple solutions. They’re all going to exist. Some will be more popular than others, but there won’t be a singular “thing”. It’s also important to discuss the context of what you’re building, like is this an app for you child’s soccer team or a bank, but I digress. Regardless of what solutions...
- Having lots of big org talks. Conversation isn’t “should we look at things”. It’s “what are the options?” Lots of places picking something. Swift talk is about this. Lots of web solutions. We’re (touchlab) working on an Android thing, as is Kotlin Native. Nobody’s working on the Swift thing, and it needs to come from the community. To be clear. Part of this talk is the same message. If you like this kind of thing, you should play with it and tell people about it. Pitch in if you’ve got time.
- I won’t predict the future. What the hell do I know? Will tell you what we’ve built, what else is happening, and see how it goes.
- Also, we should take this lightly. Whatever stuff comes out, it’ll probably be pretty good. You’re smart, and can learn new tech if you need to. It is fun to try to tackle big problems and bring new ideas to the table.
- Going from 10,000ft to 10ft view
- Android-centric Code Sharing It’s a very Android-leaning, code-sharing solution. We don’t really say “cross platform”. It’s a ruined term, and not really accurate anyway.
- The core tech is J2objc. Converts Java to Objective C Made by Google
- Sheets, Inbox, for example
- Very stable 2.0.4 Very hard to use Just “logic”
- Java Runtime, a very little bit of Android, some other libraries (JUnit, Mockito)
- Gradle Plugin/Library Format. Build system familiar to Android developers. Dependency configs.
- • Sqlite • shared preferences • Context • Threading (messagequeue, looper, handler) • Other stuff • What makes sense in iOS context and is often used by libraries/apps
- • Instrumentation Junit runner • Helper classes
- • RxJava 2 • Retrofit 2 • Gson • Dagger • Room DB • Android Architecture • (some others)
- • Cocoapod definitions that automate Xcode integration. • Share code, call from Swift. No bullshit. Why all this stuff?
- Cross platform discussion tends to be sharing “business logic” vs “everything” We’re talking about 3 things: biz logic, ui, and architecture
- This blog post came out a few weeks ago. I agree with a lot of their points, but they go way too far on some things.
- Lots of the same stuff with different method names.
- Lots of the same stuff with different method names.
- Very similar • Threading • Sqlite • local files • Unix-y • Networking • Gps • Etc Below the UI they are extremely similar. Same Methods Different names Sugar water in a can
- How many libraries deal with architecture? Blog posts on MVP vs MVVM, clean architecture, yada yada? Testable architecture is a big deal. We talk about architecture all the time, and Android and iOS are very similar below UI, so I think there’s value in reusing it.
- Doppl does work and the process is pretty smooth. Performance is pretty great.
- Leverage the hard stuff. This actually works, and isn’t terrible. That’s why I’m here. MVVM works fine on iOS. VIPER would be fine on Android. They’re not platform specific ideas.
- Shared UI has generally not gone well.
- It does work well in certain places. Apps where you don’t have much choice.
- Aside: React Native is *not* shared UI. I think that’s a broad misconception. There are libraries attempting to work on it, but ultimately, you do a lot of platform specific coding.
- We wouldn’t be here if shared UI was good, because…
- Games! Mentioned earlier. Games generally need 1 UI. Pretty rare that you code a game twice. Most code shared. It’s tempting to think that if we could just make a single UI for apps, that we could solve the problem (*cough* Flutter), but the market has resisted this. UI and platform interaction is a tough thing to solve. Code and architecture can be shred.
- Going on a quick Doppl tour. Some points of interest.
- Calling shared code from Swift, and back. Just another library. No weird barriers. Same runtime and memory universe. If you need to talk to native code, just make an abstract class or interface. Done.
- There is no “cross platform” on the Android side. Big impact on development efficiency and risk Those 2 things are THE BIG THINGS. You need some rules. UI and “logic” kept separate. Make testable. Keep in mind dependencies. You can’t just run doppl on a mature codebase, but still.
- Walk through a feature of the Droidcon app. Reactive architecture shared. RXJava 2, Retrofit 2, Arch components, Room.
- When you click on a speaker in the Droidcon app, you will open the UserDetail screen. To model the data, we have a ViewModel
- In our ViewModel, we subscribe to a Flowable that gives us updates on UserAccount data.
- We manage the data in FindUserInteractor…
- The interactor kicks of a remote data load, but ultimately returns a Flowable query from sqlite. Our initial data load should have the user info available locally, and should always return data. If the remote update changes anything, the local save will push an update to the UI through the Flowable.
- Back in ViewModel, the move from background thread to main thread is handled with an injected FlowableTransformer
- Main does processing on the io thread, and returns on mainThread
- Test on trampoline. How you do this is up to you, but the point is this is standard RxJava stuff. If you’re lost, find a talk on threading, RxJava, and testing.
- The UI is native. As mentioned, native interaction is through a Java interface (or abstract class).
- We wire up the Host interface in the ‘wire’ method. This method is called from Kotlin/Java, or Swift/Objective-C. BTW: We use the Host interface rather than returning some kind of reactive artifact directly because Swift kind of prefers concrete classes to generics. Life isn’t always perfect.
- Kotlin UI!
- Wire, passing in this (we implement the ViewModel Host)
- On error we show a toast and exit
- When user info found or updated, data gets passed in here.
- On the Swift side
- Pass self in to wire (we’re implementing the Host)
- On error we’re not doing anything useful because it’s a sample app
- When user found/updated, we get that here
- Do iOS UI shit
- I’m not going to get too into how this all works, but essentially there are a bunch of parallel dependencies that run on the iOS side. That’s what the “doppl” comes from.
- Retrofit. Mostly the same, except the actual network communication happens with URLSession.
- RxJava. Pretty much stock, although cleaning up memory cycles. Also found some unsafe field access in RxJava itself.
- Dagger. The annotation processor runs as usual. We translate the generated Java. The Dagger version is getting old. Will update soon, although they moved the build to Basil, so either need to do some surgery or start thinking about Basil.
- Doppl config. We config some prefixes, which shortens the file names. We also tell the gradle plugin what to translate.
- Sharing is easy, and performs well. That was Sqlite, with Room, pushing a reactive architecture all the way up to the UI. If you’re not seeing the value here, grab me after class.
- Talk about how this impacts on the business side
- This is hard to measure, but intuitive concept For a given feature set, say v1 of an app, the relative time it would take using different frameworks to build. As in, if you wrote a string parser in Kotlin, vs C, vs assembly code
- There is, btw, assembly code in the AOSP jni stuff. Nasty.
- Tweet of the year Anyway, I have math/charts, but we’re limited on time, and I don’t think you’ll need them. It’s all kind of theoretical anyway.
- This is the baseline assumption. For general app development, Android Studio and Xcode are your best options, by a reasonable distance. Not just a little bit. For an iPad only app, if I built it in React Native, I’d be wasting my time. I think some React Native fans wouldn’t agree with this, but I think it’s safe to assume that almost everybody would. It is not a quantum reality that “Native tools are best”. Google and Apple spend lots of time/money on this. Nobody in this room pays for their IDE anymore (Intellij, ironically, maybe). Painfully aware of this with Doppl. The reasons are simple less efficient development. Library support and maturity, relatively obscure build and runtime issues, missing features, Stack Overflow traffic, etc. Can’t just look at how long it took to build a sample. Think about when you run into that weird bug that takes several days, or the missing feature that you need to hand roll.
- Extra time on a different platform due to inefficiencies. Numbers are vague and nobody would ever agree I just say 25%+, generally more like a 1/3+ React Native, Xamarin, whatever. That’s a minimum, and 1 platform.
- Had a hard time expressing it visually that would translate viscerally. Imagine a feature with a 3 month build time, for first platform.
- This is the platform tax.
- iOS? Android? Trick question. First platform. Architectural churn/discovery. Server API. That’s just technical. Iterating on product. Agile exists because we don’t know what we want. It’s “waste”, but valuable waste. You learn lessons. New product? At least half of your time. Startup? Forget it. Majority of time is on failed ideas.
- Everything costs more. That includes the “waste”. That’s what’s missing in “cross platform” discussions. Could argue that “2 apps” isn’t really as expensive as you think. It *might* be smart, but doesn’t sound smart. Also, there are other measures and other value involved (bugs, etc)
- Iterate in Android. Share logic and architecture to iOS. Share what you want. Optional. Doppl isn’t painless, but the point is you can do the most intensive work with no extra cost.
- Our marketing team pointed this out last week. What differentiates mobile (or anything)? Design? Sort of. Technical implementation? Mostly not super complex. It’s how much iteration and testing of product/market fit. Make that as fast and as cheap as possible.
- The other big concern is risk.
- Management Has Scary Decisions, about things they often don’t really understand. Risk has many dimensions. • Technical risk. • Development efficiency risk. • Security risk. • Hiring/training. • Platform risk/Licensing risk React Native is apparently still using the “bad” license even after React.js changed to MIT. Who knew? Risk is a Big Deal!
- Result of smooth interop. Sharing is optional. Don’t want shared code touching the network? Wrap in interface. 2 weeks out from release and the shared code has an issue, just code around it. Don’t share that bit. Simple. Incrementally scoop out and share on existing code bases. Platform fidelity tests No capital B big decisions
- Android is the riskier platform. The only real option where one side is 100%. You have no extra runtime bloat • Instant apps, etc. • International apps (where the growth is)
- No additional risk. You won’t be able to do something in React Native that you can’t do with 2 native apps We’re starting from that and increasing efficiency. Not the other way. No capital B Big decsions.
- Our goal is to maintain the lowest risk, while adding greater efficiency All that to get to this. High efficiency of development with minimal risk. That’s the ultimate takeaway. That’s why we built things this way, and are advocating for some other stuff out there. Google puts J2objc in major apps. According to the Ray Ryan talk, Square has some mixed in there. It’s not sexy to talk about Java and Objective-C, but they are powering major, major apps.
- No super important if not talking cross platform Keep an ear to the ground. Sometimes this will seem like its out of left field, but the web team has been pushing React for a while.
- Same message to Swift folks. This is happening Dig in and try stuff. Advocate. Doppl libs need publishing Kotlin Native will need compatible libs
- Just came from Kotlinconf. Kotlin Native is happening. It’s very early, but it’s coming. If light on time, just skip to Swift/Kotlin slides.
- This has been working for a while now
- The native builds should allow you to also share with iOS
- Web assembly does technically work. Not sure if this is really going to be a thing, but really hopeful. Web assembly roadmap has threads and other stuff. Super cool. We’ll see.
- Let’s talk a bit about Native
- Right now you point it at Objective-C and you can write stuff in Kotlin. “Works” but not pretty
- Needs to be this. Cooperative sharing. Smooth interop.
- And of course being able to call back into native stuff.
- The next big step will be writing necessary libraries that function without a JVM. That’s DB, ViewModel, Reactive stuff. If you’ve been looking for good open source stuff to work on, this is it. Has to be smooth. Lose efficiency if you spend a lot of time sorting out cross platform issues.
- There are still some fundamental things in Native that need to get sorted. Threads, memory, etc. Then there will be that phase where we’re running into bugs and whatnot. I’d guess 1 year minimum, up to 2. To be super functional. You’ll be able to start playing with this very soon. The native team is very approachable. Start bugging them for what you want.
- Kotlinconf app is available and you can build, but you’ll need to have a solid understanding of Xcode and Kotlin Native. Not easy. App doesn’t share a whole lot of code because there aren’t many libraries. Like I’m pretty sure they use core data and write Objective-C helper stuff to handle data. Meh.
- How does Doppl live in this world?
- Kotlin native doesn’t have the JRE.
- J2objc is a JRE on iOS. This is what our sample Droidcon app is. It’ll need a little smoothing, but works. We were trying to beat the Kotlin Native team to release the first Kotlin Native app, but they beat us. Was running Room, RxJava 2, Retrofit 2, etc.
- Eventually, depending on what you’re trying to do, architecture can look like this. The point is these technologies are philosophically similar, and I think pretty compatible.
- Eventually, depending on what you’re trying to do, architecture can look like this. The point is these technologies are philosophically similar, and I think pretty compatible.
- As Kotlin Native becomes more stable, we’ll need the libraries you use every day. Also need some of the stuff in Doppl, like the database wrappers, etc. You *can* use J2objc stuff, but Kotlin specific libraries should be created.
- Ran out of slide time, but Rust is really cool. Share code, thread and memory safety. No runtime bloat. It’s pretty sweet. There is some risk there, like recruiting good developers with Rust experience is probably tricky, but still. It’s nice. But you’re a lot more likely to do Kotlin.
- I didn’t go too technical because you wouldn’t remember it. We have Mark Murphy doing a much better job than me on the docs. Come check out the sample.
- Sample and docs on website. Please come try and give feedback. Maybe even try to build something with it.
- If you’re actually looking to get some corporate help, that’s what our business is morphing into. Platform convergence experts. This doesn’t mean we’re trying to sell you Doppl. Different solutions for different folks. Please reach out.
- If you don’t remember the URLS, just remember the about screen in the app, or follow my twitter account. Sending out slides and a previously recorded version of this talk right now.