6 ms·

If I wanted to do android development again, I have no idea which skillset to optimize for React Native? Kotlin? An old version of Java that just got lambdas

If I wanted to do android development again, I have no idea which skillset to optimize for React Native? Kotlin? An old version of Java that just got lambdas? Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) Are there adequate networking, database ORM, and image loading libraries for all frameworks? Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect

WrtCdEvrydy 5y ago
React Native or Flutter depending on your desired target.
hardwaresofton 5y ago
None of those! The real answer is Nativescript -- https://nativescript.org https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productive and you can bring along frameworks that do their best to move the work to compile time (like Svelte). I think the best options form a spectrum like this: (PWA)-------(NativeScript/React Native)------(Flutter)------(Kotlin/Alternative iOS environments)--------(Objective-C/Swifth/Java "fully native") If you choose essentially anything on the right side of flutter, performance will be relatively good out of the gate, and anything to the left (including flutter) and you have to be a little careful. I think Flutter is actually the worst of both worlds because I'm heavily biased against Dart after using it, but it is obviously backed by a behemoth, and the render-every-pixel model makes it insanely portable. If you want to write-once-run-everywhere (generally a bad idea, but if it works for you who cares), then flutter is the best by a longshot.
- vmception 5y ago
  NativeScript is obviously the wrong answer I want to pass interviews and do android development for employers Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on
  - hardwaresofton 5y ago
    > I want to pass interviews and do android development for employers Definitely learn plain old Android-style Java, with the usual tools (android studio, etc) then. Most shops are going to be that, and if you want to pick up Kotlin for the shops that are a step ahead then do that. > Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on React Native in this scenario, unless the company already has at least one (and if it's one they have to be VERY competent) mobile engineers on both major platforms. Fully native is the best results (there's essentially zero limitation) but is the most specialized work. PWA is the easiest, but paradoxically needs a tiny bit of specialization to get native enough that the business isn't embarrassed. Also, with PWA there's lots of hard limits on what the app can do (notifications are a particular bugbear).
- whoisjuan 5y ago
  I believe what you say about NativeScript but there’s not enough momentum in that solution. Learning NativeScript will give you access to a way smaller pool of projects or companies you can work for. I think most developers would prioritize employability + traction/community/documention. There’s not even a comparison there. React Native is the superior solution.
  - hardwaresofton 5y ago
    Yeah -- I do agree with you, React Native is going to see the majority of the love. I would like to point out that NativeScript works -- people mostly don't make buzz about it but it's out there powering apps that are delivering value, I've used it myself for a client and it was fantastic. React Native is the superior solution only if you prioritize employability/traction/community (I disagree on documentation, NativeScript's documentation is excellent), but if you need to get an application out but are turned off by the React crazy-land and bad performance of React in a mobile context, give NativeScript a try, it's the better platform in a technical sense -- it has things React Native doesn't.
- mekkkkkk 5y ago
  What made you dislike Dart? I find it a highly inoffensive language.
  - hardwaresofton 5y ago
    In no particular order: - The type system was essentially like java but perhaps even worse -- in a world with Rust, Haskell, Julia, Kotlin, Scala, and even Golang this seemed egregious. - No algebraic data types (sum/union), - class-based inheritance - nullable values - using exceptions instead of errors-as-values approach. I know they worked hard on the language (rewrites are hard, there are some good talks on there about it, link @ end), but it's like they ignored all the progress in PL over the last like decade+. Anyway, continuing on: - JSON serialization/deserialization[1] was like the worst parts of Go and the worst parts of Java (again this has to - SQLite driver[0] couldn't be used off device. I found this out while trying to write tests that ran off-device. Now there's sqlite3[1] so maybe it's no longer an issue - Dart2 was a played down rewrite of Dart1, with JS interop removed. Typescript is a better language than Dart. - BloC is overcomplicated and was rolled out poorly at the time (this has more to do with Flutter than Dart). The state management patterns felt like unbaked react (flux pattern) v1. All this said, Dart will probably be around for a very long time. Fuschia makes a LOT of sense for Google to continue pursuing, which uses Flutter. Dart could be worse, and I think it's good enough for a bunch of usecases. If it were me, I wouldn't even choose it over Nativescript. The Boring Flutter Development Show[3] was/is fantastic, I watched it religiously when I was learning and trying out Flutter -- having a big backer like google means there are always going to be dedicated resources and smart people behind Flutter which honestly probably matters more in the long run than Dart being a shit language. As Golang has shown us, you can just iterate to having a good language. Feels like Dart2 has it's base to build from now, and I don't like the places it's started, but it will probably continue to succeed. At the very least you won't see bad PR about it, because most people who are willing to tweet about it are invested in it's success or want jobs at Google someday, and there is dedicated money for "dev rel". Seeing Sony embrace flutter for embedded things is pretty big as well[4]. Sony has a surprisingly strong track record of making technologically competent products: - PS Vita (generally regarded as ahead of it's time) - Sony SmartWatch 1 & 2 (I owned both, they were ahead of their time, and were very good quality, easily hackable) - Sony XPeria phones & tablets (embraced open source and easy bootloader unlock, I own a tablet that I'm extremely happy with) [EDIT] - Separate some points about the language, also add a link to the strange loop talk on the rewrite[5] [0]: https://pub.dev/packages/sqflite https://pub.dev/packages/sqflite [1]: https://pub.dev/packages/json_serializable https://pub.dev/packages/json_serializable [2]: https://pub.dev/packages/sqlite3 https://pub.dev/packages/sqlite3 [3]: https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8roU3ahJVrSgAnPjzkpGmL9Czl https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8ro... [4]: https://github.com/sony/flutter-embedded-linux https://github.com/sony/flutter-embedded-linux [5]: https://www.youtube.com/watch?v=WjdrUphF5l4 https://www.youtube.com/watch?v=WjdrUphF5l4
cercatrova 5y ago
Are you optimizing for jobs/interviewing or for learning? If the former, just do native in Kotlin, if the latter, I like Flutter personally.
throw14082020 5y ago
Most teams don't hire a "mobile developer", they hire an Android developer, and/or iOS developer, and/or React Native developer, and/or Flutter Developer. So unfortunately it requires some commitment, don't do all of them at once! - React Native: Easiest to learn, good build tools/ developer experience, good amount of jobs already. Unfortunately, React Native is naturally intertwined with JS/ react, so you'll face issues with the complex world of javascript. I won't say its slow, but it certainly doesn't work for all types of apps. Also, avoid Expo completely. - Flutter: Easy to learn, amazing build tools/ devex, very few jobs (though predictably growing). If you become a flutter developer, you can be confident the company that hired you has thought about the tech stack a little more. React Native is the defacto for quick and dirty apps (MVP), and Flutter is for more of a company thats investing in its technology, I would say. - Android: Okay to learn, very good build tools/ devex, more jobs - iOS: hardest to learn, okay build tools/ devex, fewer jobs Difficulty is measured by how long it would take you to implement a feature you don't know, or just my rough feeling of building apps in all platforms, some of them professionally. Im very unusual to know all 4, and I have not met anyone else like me in my jobs. I would pick Flutter, because you're not optimising for today, and Flutter will be there in 5 years, regardless of how big https://killedbygoogle.com/ https://killedbygoogle.com/ gets E.g. The tech lead for Flutter worked on HTML, CSS, WebSockets.
- geonic 5y ago
  Could elaborate on why to avoid expo? I found it super easy to use when I dipped my toes into RN development. Also, what alternative are you suggesting?
  - rhodysurf 5y ago
    I’ll give two reasons. First, code bloat, expo bundles allllll their default libraries along with your app when packaged for release. Second, is flexibility. The most powerful part of react native is that it displays native views and with expo you are only given the native functionality they bundle for you, you cannot create your own. The alternative is to just not use expo and add libraries as you need them. Then you can do things like add widgets and watchOS functionality to your app on iOS using native code. Or create your own custom native views and plugins that bind to the native sdks, giving you an edge over other bland RN apps. I love RN but only when used correctly.
occz 5y ago
>If I wanted to do android development again, I have no idea which skillset to optimize for I prefer native, but I'm pretty biased, to be fair. In native-land we're doing more or less all of our development in Kotlin these days. It's a really nice language. XML-based Views are still where it's at, but Google have been developing a new view toolkit called Jetpack Compose which is very likely where we are going next. It's based on the reactive view-paradigm popularized by React, but I think it's getting a lot of benefits from moving second and having been able to learn from what React has done. Also, it's not JavaScript, which is a big plus. >Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) We're doing MVVM these days. Or whatever you would like to call the following description: >There's an object called the ViewModel which survives activity recreation, from which in your view-layer you subscribe to some state. The ViewModel also facilitates access to the Model-part of your application with state and network access and whatever >Are there adequate networking, database ORM, and image loading libraries for all frameworks? I'd say so, yes. The Jetpack-family of libraries by Google are all pretty good. For networking, you can use Retrofit by Square For database ORM you can use Room by Google. There's also SqlDelight by Square if you like a lighter approach to database interaction. For image loading the most recent contender is Coil, but Glide also works pretty well. >Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect I can't promise you that the entire android development scene has aligned on anything entirely yet. This may very well still be the case.

WrtCdEvrydy 5y ago

React Native or Flutter depending on your desired target.

hardwaresofton 5y ago

None of those! The real answer is Nativescript -- https://nativescript.org https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productive and you can bring along frameworks that do their best to move the work to compile time (like Svelte). I think the best options form a spectrum like this: (PWA)-------(NativeScript/React Native)------(Flutter)------(Kotlin/Alternative iOS environments)--------(Objective-C/Swifth/Java "fully native") If you choose essentially anything on the right side of flutter, performance will be relatively good out of the gate, and anything to the left (including flutter) and you have to be a little careful. I think Flutter is actually the worst of both worlds because I'm heavily biased against Dart after using it, but it is obviously backed by a behemoth, and the render-every-pixel model makes it insanely portable. If you want to write-once-run-everywhere (generally a bad idea, but if it works for you who cares), then flutter is the best by a longshot.

vmception 5y ago
NativeScript is obviously the wrong answer I want to pass interviews and do android development for employers Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on
- hardwaresofton 5y ago
  > I want to pass interviews and do android development for employers Definitely learn plain old Android-style Java, with the usual tools (android studio, etc) then. Most shops are going to be that, and if you want to pick up Kotlin for the shops that are a step ahead then do that. > Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on React Native in this scenario, unless the company already has at least one (and if it's one they have to be VERY competent) mobile engineers on both major platforms. Fully native is the best results (there's essentially zero limitation) but is the most specialized work. PWA is the easiest, but paradoxically needs a tiny bit of specialization to get native enough that the business isn't embarrassed. Also, with PWA there's lots of hard limits on what the app can do (notifications are a particular bugbear).
whoisjuan 5y ago
I believe what you say about NativeScript but there’s not enough momentum in that solution. Learning NativeScript will give you access to a way smaller pool of projects or companies you can work for. I think most developers would prioritize employability + traction/community/documention. There’s not even a comparison there. React Native is the superior solution.
- hardwaresofton 5y ago
  Yeah -- I do agree with you, React Native is going to see the majority of the love. I would like to point out that NativeScript works -- people mostly don't make buzz about it but it's out there powering apps that are delivering value, I've used it myself for a client and it was fantastic. React Native is the superior solution only if you prioritize employability/traction/community (I disagree on documentation, NativeScript's documentation is excellent), but if you need to get an application out but are turned off by the React crazy-land and bad performance of React in a mobile context, give NativeScript a try, it's the better platform in a technical sense -- it has things React Native doesn't.
mekkkkkk 5y ago
What made you dislike Dart? I find it a highly inoffensive language.
- hardwaresofton 5y ago
  In no particular order: - The type system was essentially like java but perhaps even worse -- in a world with Rust, Haskell, Julia, Kotlin, Scala, and even Golang this seemed egregious. - No algebraic data types (sum/union), - class-based inheritance - nullable values - using exceptions instead of errors-as-values approach. I know they worked hard on the language (rewrites are hard, there are some good talks on there about it, link @ end), but it's like they ignored all the progress in PL over the last like decade+. Anyway, continuing on: - JSON serialization/deserialization[1] was like the worst parts of Go and the worst parts of Java (again this has to - SQLite driver[0] couldn't be used off device. I found this out while trying to write tests that ran off-device. Now there's sqlite3[1] so maybe it's no longer an issue - Dart2 was a played down rewrite of Dart1, with JS interop removed. Typescript is a better language than Dart. - BloC is overcomplicated and was rolled out poorly at the time (this has more to do with Flutter than Dart). The state management patterns felt like unbaked react (flux pattern) v1. All this said, Dart will probably be around for a very long time. Fuschia makes a LOT of sense for Google to continue pursuing, which uses Flutter. Dart could be worse, and I think it's good enough for a bunch of usecases. If it were me, I wouldn't even choose it over Nativescript. The Boring Flutter Development Show[3] was/is fantastic, I watched it religiously when I was learning and trying out Flutter -- having a big backer like google means there are always going to be dedicated resources and smart people behind Flutter which honestly probably matters more in the long run than Dart being a shit language. As Golang has shown us, you can just iterate to having a good language. Feels like Dart2 has it's base to build from now, and I don't like the places it's started, but it will probably continue to succeed. At the very least you won't see bad PR about it, because most people who are willing to tweet about it are invested in it's success or want jobs at Google someday, and there is dedicated money for "dev rel". Seeing Sony embrace flutter for embedded things is pretty big as well[4]. Sony has a surprisingly strong track record of making technologically competent products: - PS Vita (generally regarded as ahead of it's time) - Sony SmartWatch 1 & 2 (I owned both, they were ahead of their time, and were very good quality, easily hackable) - Sony XPeria phones & tablets (embraced open source and easy bootloader unlock, I own a tablet that I'm extremely happy with) [EDIT] - Separate some points about the language, also add a link to the strange loop talk on the rewrite[5] [0]: https://pub.dev/packages/sqflite https://pub.dev/packages/sqflite [1]: https://pub.dev/packages/json_serializable https://pub.dev/packages/json_serializable [2]: https://pub.dev/packages/sqlite3 https://pub.dev/packages/sqlite3 [3]: https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8roU3ahJVrSgAnPjzkpGmL9Czl https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8ro... [4]: https://github.com/sony/flutter-embedded-linux https://github.com/sony/flutter-embedded-linux [5]: https://www.youtube.com/watch?v=WjdrUphF5l4 https://www.youtube.com/watch?v=WjdrUphF5l4

cercatrova 5y ago

Are you optimizing for jobs/interviewing or for learning? If the former, just do native in Kotlin, if the latter, I like Flutter personally.

throw14082020 5y ago

Most teams don't hire a "mobile developer", they hire an Android developer, and/or iOS developer, and/or React Native developer, and/or Flutter Developer. So unfortunately it requires some commitment, don't do all of them at once! - React Native: Easiest to learn, good build tools/ developer experience, good amount of jobs already. Unfortunately, React Native is naturally intertwined with JS/ react, so you'll face issues with the complex world of javascript. I won't say its slow, but it certainly doesn't work for all types of apps. Also, avoid Expo completely. - Flutter: Easy to learn, amazing build tools/ devex, very few jobs (though predictably growing). If you become a flutter developer, you can be confident the company that hired you has thought about the tech stack a little more. React Native is the defacto for quick and dirty apps (MVP), and Flutter is for more of a company thats investing in its technology, I would say. - Android: Okay to learn, very good build tools/ devex, more jobs - iOS: hardest to learn, okay build tools/ devex, fewer jobs Difficulty is measured by how long it would take you to implement a feature you don't know, or just my rough feeling of building apps in all platforms, some of them professionally. Im very unusual to know all 4, and I have not met anyone else like me in my jobs. I would pick Flutter, because you're not optimising for today, and Flutter will be there in 5 years, regardless of how big https://killedbygoogle.com/ https://killedbygoogle.com/ gets E.g. The tech lead for Flutter worked on HTML, CSS, WebSockets.

geonic 5y ago
Could elaborate on why to avoid expo? I found it super easy to use when I dipped my toes into RN development. Also, what alternative are you suggesting?
- rhodysurf 5y ago
  I’ll give two reasons. First, code bloat, expo bundles allllll their default libraries along with your app when packaged for release. Second, is flexibility. The most powerful part of react native is that it displays native views and with expo you are only given the native functionality they bundle for you, you cannot create your own. The alternative is to just not use expo and add libraries as you need them. Then you can do things like add widgets and watchOS functionality to your app on iOS using native code. Or create your own custom native views and plugins that bind to the native sdks, giving you an edge over other bland RN apps. I love RN but only when used correctly.

occz 5y ago

>If I wanted to do android development again, I have no idea which skillset to optimize for I prefer native, but I'm pretty biased, to be fair. In native-land we're doing more or less all of our development in Kotlin these days. It's a really nice language. XML-based Views are still where it's at, but Google have been developing a new view toolkit called Jetpack Compose which is very likely where we are going next. It's based on the reactive view-paradigm popularized by React, but I think it's getting a lot of benefits from moving second and having been able to learn from what React has done. Also, it's not JavaScript, which is a big plus. >Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) We're doing MVVM these days. Or whatever you would like to call the following description: >There's an object called the ViewModel which survives activity recreation, from which in your view-layer you subscribe to some state. The ViewModel also facilitates access to the Model-part of your application with state and network access and whatever >Are there adequate networking, database ORM, and image loading libraries for all frameworks? I'd say so, yes. The Jetpack-family of libraries by Google are all pretty good. For networking, you can use Retrofit by Square For database ORM you can use Room by Google. There's also SqlDelight by Square if you like a lighter approach to database interaction. For image loading the most recent contender is Coil, but Glide also works pretty well. >Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect I can't promise you that the entire android development scene has aligned on anything entirely yet. This may very well still be the case.