3 ms·

My hunch is that Google is trying to migrate away from Android. Flutter is both the abstraction layer to do that and the new SDK for the new platform. If that'

by plq 6y ago

My hunch is that Google is trying to migrate away from Android. Flutter is both the abstraction layer to do that and the new SDK for the new platform. If that's the case, it's higly unlikely.

dakna 6y ago
I think Google realized they needed a compelling cross-plattform solution because React Native started to gain so much traction. In terms of migrating away from Android, I think they will use the newer AndroidX packages as the future abstraction layer, which would enable them to replace the underlying runtime with something more native for each platform. It would be a compilation target for Kotlin as well as Dart. All while not deprecating the massive amount of production code out there. But, this is also just a guess.
- izacus 6y ago
  That's a really wierd take if you actually look at what AndroidX is - it's a set of utility libraries to complement Android so it being some kind of abstraction layer is rather nonsensical. It's like saying boost is an abstraction layer for Linux and it allows its replacement. It's an orthogonal thing that doesn't stand alone.
  - dakna 6y ago
    Yes, it's a set of libraries under one package name. With Google's massive investment in refactoring it has a pretty big surface already, from persistence to UI and almost everything in between. https://developer.android.com/reference/androidx/packages https://developer.android.com/reference/androidx/packages It's current implementation uses classes that are part of the Android layer, mostly the old support library plus some new abstractions like LiveData and Room and Navigation. I see no reason why you could not use the public interface of that library as a compatibility layer for application level code and let it run on a different platform. Not today, but given the fact that you can't just kill the worlds most used operating system, you either use virtualization like Apple now does again for ARM (and before when replacing Motorola with Intel) or you change the underlying dependencies of the libraries used and compile again.
    - pjmlp 6y ago
      That is more a defense move given that Kotlin cannot rely on Java FFI going forward than anything else.
pjmlp 6y ago
Except that Android team hasn't got the memo, hence Jetpack Composer, and increased adoption of Kotlin multiplatform as a defensive reaction against Flutter hype.

by plq 6y ago

My hunch is that Google is trying to migrate away from Android. Flutter is both the abstraction layer to do that and the new SDK for the new platform. If that's the case, it's higly unlikely.

dakna 6y ago

I think Google realized they needed a compelling cross-plattform solution because React Native started to gain so much traction. In terms of migrating away from Android, I think they will use the newer AndroidX packages as the future abstraction layer, which would enable them to replace the underlying runtime with something more native for each platform. It would be a compilation target for Kotlin as well as Dart. All while not deprecating the massive amount of production code out there. But, this is also just a guess.

izacus 6y ago
That's a really wierd take if you actually look at what AndroidX is - it's a set of utility libraries to complement Android so it being some kind of abstraction layer is rather nonsensical. It's like saying boost is an abstraction layer for Linux and it allows its replacement. It's an orthogonal thing that doesn't stand alone.
- dakna 6y ago
  Yes, it's a set of libraries under one package name. With Google's massive investment in refactoring it has a pretty big surface already, from persistence to UI and almost everything in between. https://developer.android.com/reference/androidx/packages https://developer.android.com/reference/androidx/packages It's current implementation uses classes that are part of the Android layer, mostly the old support library plus some new abstractions like LiveData and Room and Navigation. I see no reason why you could not use the public interface of that library as a compatibility layer for application level code and let it run on a different platform. Not today, but given the fact that you can't just kill the worlds most used operating system, you either use virtualization like Apple now does again for ARM (and before when replacing Motorola with Intel) or you change the underlying dependencies of the libraries used and compile again.
  - pjmlp 6y ago
    That is more a defense move given that Kotlin cannot rely on Java FFI going forward than anything else.

pjmlp 6y ago

Except that Android team hasn't got the memo, hence Jetpack Composer, and increased adoption of Kotlin multiplatform as a defensive reaction against Flutter hype.