10 ms·

I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolu

by McDev 7y ago

I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly. Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this. Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs. Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier. I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually. [0]. https://developer.android.com/topic/performance/graphics/load-bitmap https://developer.android.com/topic/performance/graphics/loa... [1]. https://developer.android.com/training/camerax https://developer.android.com/training/camerax [2]. https://square.github.io/retrofit/ https://square.github.io/retrofit/ [3]. https://github.com/android/architecture-samples https://github.com/android/architecture-samples

applecrazy 7y ago
Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.
- mdocherty 7y ago
  I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.
  - freehunter 7y ago
    On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.
    - SquishyPanda23 7y ago
      This is a nit, but there's a pretty big difference between refactoring and rearchitecting. If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten. Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity. I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
      - freehunter 7y ago
        You're right, I didn't use the correct terminology and I appreciate the correction. On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front. Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite. [1] https://facebook.github.io/react-native/showcase https://facebook.github.io/react-native/showcase
- pjmlp 7y ago
  I bet that Chrome and Android team would have more political muscle than the Flutter team. PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.
- jmull 7y ago
  Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.
  - preommr 7y ago
    > For one thing, it’s tied to a custom language. Are you talking about Dart? If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is. It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
    - fctorial 7y ago
      I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself. I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
    - literallycancer 7y ago
      Well they did add the compiler half way through. You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm? What's the point of dealing with a half baked ecosystem when there are much better languages available?
  - Qasaur 7y ago
    I disagree strongly with this. I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar. It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix. Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.
- billfruit 7y ago
  Perhaps Xamarin is a good choice as well for who want to transition from development of desktop apps. Also support for F# on Xamarin is also a plus.
  - graydsl 7y ago
    I was waiting for someone to mention Xamarin. :D I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency). Problems we had: * Deploying to devices was painfully slow compared to native stack. * We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio. * Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment. When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure. Did it get any better?
    - pjmlp 7y ago
      Visual Studio for Mac has suffered quite a refactoring after the acquisition, as many of the MonoDevelop internals have been refactored into common libraries shared between Visual Studio and Visual Studio for Mac, one of the reasons why the new plugin infrastructure is based on .NET instead of COM. There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/ https://visualstudio.microsoft.com/vs/mac/event/
- elevenoh 7y ago
  How is flutter's open source widget community?
rofrol 7y ago
>Even Google's own Pixel devices do not support this. The image quality from CameraX API is not ass good as the stock camera. And there is no support for Night Sight. I do not get this. From the comment 2 months ago https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4kMbdzuR4AaABAg https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4k...

by McDev 7y ago

applecrazy 7y ago

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

mdocherty 7y ago
I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.
- freehunter 7y ago
  On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.
  - SquishyPanda23 7y ago
    This is a nit, but there's a pretty big difference between refactoring and rearchitecting. If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten. Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity. I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
    - freehunter 7y ago
      You're right, I didn't use the correct terminology and I appreciate the correction. On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front. Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite. [1] https://facebook.github.io/react-native/showcase https://facebook.github.io/react-native/showcase
pjmlp 7y ago
I bet that Chrome and Android team would have more political muscle than the Flutter team. PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.
jmull 7y ago
Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.
- preommr 7y ago
  > For one thing, it’s tied to a custom language. Are you talking about Dart? If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is. It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
  - fctorial 7y ago
    I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself. I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
  - literallycancer 7y ago
    Well they did add the compiler half way through. You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm? What's the point of dealing with a half baked ecosystem when there are much better languages available?
- Qasaur 7y ago
  I disagree strongly with this. I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar. It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix. Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.
billfruit 7y ago
Perhaps Xamarin is a good choice as well for who want to transition from development of desktop apps. Also support for F# on Xamarin is also a plus.
- graydsl 7y ago
  I was waiting for someone to mention Xamarin. :D I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency). Problems we had: * Deploying to devices was painfully slow compared to native stack. * We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio. * Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment. When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure. Did it get any better?
  - pjmlp 7y ago
    Visual Studio for Mac has suffered quite a refactoring after the acquisition, as many of the MonoDevelop internals have been refactored into common libraries shared between Visual Studio and Visual Studio for Mac, one of the reasons why the new plugin infrastructure is based on .NET instead of COM. There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/ https://visualstudio.microsoft.com/vs/mac/event/
elevenoh 7y ago
How is flutter's open source widget community?

rofrol 7y ago

>Even Google's own Pixel devices do not support this. The image quality from CameraX API is not ass good as the stock camera. And there is no support for Night Sight. I do not get this. From the comment 2 months ago https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4kMbdzuR4AaABAg https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4k...