SO WHAT APP IS THIS ? ▸ “realworld.io" - a project by thinkster (github.com/gothinkster) ▸ A simplified clone of Medium ▸ Standardised API ▸ We can make backend or frontend using any technology as per the API
MY EXPERIENCES WITH THE PLATFORMS FOR CONTEXT - PRIOR EXPERIENCE ▸ Native Android developer since 2011, using Kotlin for > 2 years, multiple popular libraries written ▸ NativeScript - 8-10 months, Vue.js - almost 2 years, author of popular vue libraries ▸ Flutter - Explored once 6 months back, but this is my first app in Flutter
MY EXPERIENCES WITH THE PLATFORMS WHAT THIS IS NOT . . . ▸ Promotion of any platform. I have tried to be unbiased. ▸ Bashing any platform. Objective facts and numbers here. None of the platforms are ‘bad’. ▸ A definitive guide to choose. Here lay a few benchmarks. Might help in your choice. Your decision, still, should be driven by use case.
GETTING STARTED ▸ Android Studio installation takes care of all required dependencies ▸ Create new project in GUI ▸ Created project works out of the box ▸ Most problems in starting a project have multiple StackOverflow answers 13
GETTING STARTED ▸ Installing Flutter SDK has command-line steps ▸ flutter doctor command to check installation success (not 100% reliable) ▸ GUI-based steps to create project in Android Studio ▸ Created project works out of the box 14
GETTING STARTED ▸ Installing nativescript-cli has command-line steps ▸ tns doctor command to check installation success (not 100% reliable) ▸ CLI-based step to init starter template. Multiple starter templates - can be confusing ▸ Created project may not work out of the box. Circuitous dependency resolution in starter template too 15
LANGUAGES MORE SIMILAR THAN YOU THINK ▸ Differences in implementations, practices, common patterns, internal mechanisms ▸ On the surface, modern multi-platform languages have very similar syntax and features
DESIGN PATTERNS KOTLIN (NATIVE ANDROID) ▸ All 3 - MVP, MVC and MVVM well defined and documented ▸ MVC: Conventional (and easy to get started) ▸ Modern Android Architecture Components - focus on MVVM ▸ ReactiveX available via RxJava, RxAndroid and RxKotlin 28
DESIGN PATTERNS NATIVESCRIPT (WITH ANGULAR OR VUE) ▸ Angular - Component based (sort of MVC) but can by Reactive is using RxJS ▸ Vue - MVVM, can be Reactive if using vuex- rxjs ▸ Flux-like state management via vuex available in Vue 29
DESIGN PATTERNS FLUTTER ▸ No officially documented/endorsed design pattern ▸ Unofficial MVC and MVVM-like examples available ▸ Business Logic Component (BLoC) pattern getting popular 30
BREAKPOINT DEBUGGING Yes - fully integrated with Android Studio No - very limited support, socket connection breaks Yes - via Android studio but not 100% reliable
TESTING FRAMEWORKS Well Supported - JUnit for unit test and Espresso for UI test ??? - Can use Vue/ Angular usual mechanisms, but not well documented Well Supported - Separate unit and UI test methods not needed
DATA (DE)SERIALIZATION AT RUNTIME Yes - Gson, Jackson, FasterXML. Also data class generators available Yes - Not needed for JSON , XML libraries exist No - Not possible without reflection. Need data classes pre- generated.
2-WAY DATA BINDING Kind of - Using LiveData and DataBinding Yes - Vue supports proper 2-way binds with v-model No - Not in usual sense. There is widget-binding
FULLY FEATURED ORM Yes - multiple solutions for SQLite and also Realm for object-storage Yes - TypeORM for SQLite No - sqflite is kind of ORM but lot of hand- written SQL needed. Not possible because no runtime reflection
INTEGRATING WITH NATIVE WIDGETS Ofcourse Yes - Might need Kotlin/ Swift knowledge to glue together No - Preliminary support recently dropped, doesn’t work reliably yet Needed to embed Google Maps or WebViews
MAINTAINABILITY / UPGRADABILITY Easy (mostly), IDE suggests too except the recent androidx drama 7th circle of Dante’s hell - Not making it up - recreating the project and copying over sources is easier. Very Easy ! - Had surprisingly close to zero issues for such a nascent platform How much of a pain is it to upgrade libraries/runtimes
CONCLUSION ▸ If you need lots of background services, GPS/geofences, Bluetooth, hardware, telemetry access, you have to go native. ▸ If app size, CPU/RAM usage, energy efficiency are critical, close-to-metal is easier to optimise. ▸ Time/money/energy investment is high. Larger team needed. 57
DESIGN PATTERNS 58 ▸ If you/your team already is knee-deep in frontend frameworks, Nativescript or React Native makes sense. ▸ Time/energy saved in being able to share code across mobile and web is immense. ▸ App size, performance takes a hit. Cannot really avoid understanding native SDKs. Debugging, maintaining might be nightmare for newcomers to mobile.
CONCLUSION 59 ▸ UI/Animation heavy apps should try it out. High fidelity reproduction, pixel-perfect matching across platforms. ▸ Good for CRUD frontends, freelance/small projects. Ridiculously low time taken to build, even for newcomers. ▸ Buttery smooth UI comes at the cost of CPU, RAM and energy usage. Lower end devices can choke. ▸ Integrating with native is still dodgy, nascent ecosystem = less support.
championswimmer
sbtechnight
kthrtty
masashi_sutou
kentosuzuki
oracle4engineer
bun913
harukasakihara
sue445
flant
thoeni
bryan
jmmastey
bcantrill
bkeepers
schacon
shlominoach
paulrobertlloyd
jennybc
jonyablonski
orderedlist