at the rate its going there is no stopping. Kotlin is a much nice experience that Java and far more projects are starting today with Kotlin rather than java
At this point, I feel no language can compensate for the platform's out-of-date java libraries. I think Google has its priorities wrong: first should be recent java, second should be kotlin.
Look at chrome os fiasco. They had it for 6,7 years? They didn’t realized it until Microsoft did put effort to make their OS developer friendly that they should make chromeos developer friendly. Imagine how good chromeos was today if they have started to make it developer friendly in 2010 instead of 2017.
I disagree: they should just dump the whole ecosystem. Kotlin is a shabby bandaid, not because the language isn’t good (no comments there) but because the substrate is a mess of bloated, terrible, OO Java nonsense. Android development is just awful no matter the language.
I'm seriously not astrotrufing (for once!) but isn't Android itself shitty all round? Really complex OS that does a million things and all wrong. I have a phone where no fb is installed but fb services that cannot be stopped are running in the background.
Well, if your OEM installed crapware in the system/vender/OEM partition, that's not really Android's problem. All other apps/services are very removable.
It is the customer’s problem, so it is jointly a problem for Android and the OEM. Google may try to abrogate responsibility here as usual, but it doesn’t make it any less their problem.
But the pixels are (in my opinion) just such complete misses as phones. I’m not sure I’d want to use the latest Pixel if I got it for free, yet they charge an absurdly high price for it. I used to love my Nexus 4, and I liked my Nexus 5. It was absolutely amazing to have a real Google phone that I didn’t have to fight with in order to own for real at the lowest levels. But all the recent pixel phones have way too many trade-offs for me to use any of them as my daily driver. There are android phones out there which I like and would be happy to use as my daily driver, except on the software side they are way too locked down and I can’t root/flash them. I really wish phones worked the way computers do, I could just buy/build any hardware I want and run a fresh copy of Linux or windows on it under my complete control.
Why a complete mess? Sure Google is a popular target, much like apple, where a huge number of people chime in to complain. I've had every nexus and every pixel, all the way back to the HTC G1 on the first day it was for sale.
Sure choice of OS would be nice, but there's a huge number of man hours that go into making a nice touch UI. Something that experts don't tend to obsess over, unless paid.
The pixel's don't have a locked bootloader, and you could try one of the community builds, which I've done. But there's much less incentive lately. I used to root to tether, don't need to anymore.
Why is that possible on android but not iOS phones? Serious question - I assume it’s because of the way android is built but I don’t know How that works. Why is there preinstalled installed software on Android phones at all?
Edit: I’m not sure why this question is getting downvoted.
When a device manufacturer makes a phone that uses android they can do a lot of stuff with Android without any issues (beside UX), other than messing with APIs and legal things. iOS is exclusively made by Apple and nobody can release their own iOS, so they always have prevented others (even the carriers) from putting their own apps on the phone before the user gets the device.
Why would you buy an LG versus a Samsung? Too many android manufacturers to compete on just hardware alone. Even less so than Windows laptops and PCs. Customizing Android is the differentiator.
I personally hate it, but I understand why they do it. I just wish we could get a class leading vanilla Android phone. Pixel isn’t it.
Because the comparable phone to iOS phones aren't "Android phones" but "Pixel phones". Phones where the OS vendor also builds the hardware and controls everything.
It's just a different model. Single corporation stack gives you more consistency and less bloatware and OEM based stack gives you more market choice and greater accessibility.
Aping all the bad parts of the MS ecosystem while missing most of the good (I firmly believe desktop linux peaking with KDE 2 and has been consistently downhill ever sense)
Are Apps on android sufficiently consistent or don't "break randomly"? I don't think I see much of material UI outside of Google's own apps (from the times I look at my friends' phones, I use iOS).
I had an n900 and it was amazing to use. the only reason I switched to android was that nokia stopped delivering updates and bugfixes to maemo/meego and then of course there was never another good linux phone.
There have been Linux phones before, like the Nokia N900. But there hasn't been the combination of marketing push and, perhaps, polish required for them to succeed commercially against other platforms.
I guess because they are only available in a couple of countries, are expensive, and Google isn't any better than their OEMs keeping old devices updated.
Hadn't noticed the expensive side. They typically got half off within a month or two of announce. Got my Pixel 4XL 128GB for under $500 because of the Google Fi deal.
I still have a pixel 1 from 4 years ago that I think just stopped getting major upgrades. Not great, but not bad. My samsung note 4 was around a year behind on updates, and felt very slow because of all the crapware. I switched to a nexus 5, with a much lower spec and it felt MUCH better. Even simple things like hitting the home button had much less lag.
I did end up installing Cyanogen on the Note 4 which made it feel quite a bit snappier.
To paraphrase them, "it looks interesting and it is something that we are following on", which means nothing to me.
In any case Kotlin/Native doesn't bring nothing to Android itself.
ART makes use of AOT/JIT with code cache, which is much better than straight AOT on languages with reflection, dynamic dispatch and dynamic loading everywhere.
This is why they gave up on pure AOT introduced during Android 5 and 6 lifetime.
Then the NDK is tailored for writing native libraries for consumption from ART, only exposing C bindings, even though most of the code is actually C++.
Some of the newer stuff seems mostly well-designed, e.g. Room, LiveData. Lot of the older stuff is horrible. Kotlin is just slightly better than Java in my experience.
Overall I wouldn't say Android development is aweful, I think it's iOS is just marginally better. Swift is a nicer language than Kotlin but creating UI layouts sucks on iOS.
How well does it scale in complexity though? These easy declarative UIs tend to have a hard ceiling in complexity and then you're forced to rewrite everything. How does SwitftUI scale to complex and animation heavy UIs?
I haven’t gone too far down the rabbit hole yet but I find it similar to React in complexity ceiling. I’ve built some extremely complicated UIs in React. You just have to break up your views as complexity grows.
In this context of disparaging the state of Android development, I must plead: take a hard look at Flutter/Dart. There are quite a few wins with it, including a pleasant developer experience. Declarative, composable, JIT compilation in dev, AOT compilation in production. The list goes on.
+1 for Flutter. Fast iteration, few gotchyas, decent documentation, a growing community, very fine control, but forgiving to those learning the framework.
I wish they'd dump Dart and replace it with basically anything else (Typescript? Swift? Kotlin?).
I'm not going to learn a new language which isn't used anywhere else AND a new UI toolkit just because Google's internal team structure has put them in a position to keep Dart going.
Back when Dart came out, it made sense. But Typescript came along, filled basically the same niche and got significant mindshare.
And now, Swift, C# and naturally Kotlin are coming up with similar tooling, which kind invalidates the reasoning why it had to be Dart, above all languages.
Not to mention that Flutter experience isn't nothing more than cute to anyone that has experience doing UI design on Common Lisp or Smalltalk environments, which I reckon all of us are quite old for SV standards.
EDIT: Or if you really want to be amazed go play with SELF.
> And now, Swift, C# and naturally Kotlin are coming up with similar tooling...
That may be true, but right now, none of them has something as polished and usable as Flutter. And it looks like it will be many years before they do, all the while Flutter keeps getting better. So, if you have time to wait for these other platforms to catch up, go ahead while people who need to write code right now can enjoy something else.
> EDIT: Or if you really want to be amazed go play with SELF.
Oh come'on, are you really suggesting something that looks straight out of the early 90's is something that would amaze anyone today? Or there's something that actually looks and behaves modern out of the Self and Smalltalk world (certainly was not the case last time I checked, a few years back)?
Yes they have, language ecosystems with decades of battle field deployments in production, while Dart still tries to make itself relevant.
What I am suggesting is that the reasoning why Dart instead of something else is flawed and can only be naively bought by those that lack experience in UI domain.
How pretty those UIs used to look like is secondary.
Flutter is being positioned to rescue Dart, and make it meaningful beyond the AdWord team, the place where it landed when all Dart designers eventually left Google.
Where is the "Google's Commitment to Dart" blog post?
Personification of a programming language, nice. Flutter is ready to use, and is very rewarding for quickly building a specific use application; try it.
> I disagree: they should just dump the whole ecosystem. Kotlin is a shabby bandaid, not because the language isn’t good (no comments there) but because the substrate is a mess of bloated, terrible, OO Java nonsense. Android development is just awful no matter the language.
They should dump the most widespread mobile operating system ecosystem... because some people think API's are "OO nonsense"? Would you also want Microsoft to abandon whole Windows ecosystem just because WinAPI dates back to Win16?
This is insanity and completely ignores the reasons why ecosystems get popular.
The Android ecosystem got popular primarily for two reasons: the massive marketing effort by google and the plentiful dirt-cheap labor market in the kind of development paradigm Android is (awful, bloated Java where desperate $5/hr devs are plentiful).
Interesting, I find Kotlin just marginally better than Java. It doesn't have checked exceptions which is annoying. You can't use a simple return in lambda functions.
As for other languages: Python is ok for smaller stuff. I don't like Go. My favourite languages are probably Swift and Julia. And recently, I've grown to really like C++ although I used to hate it.
Agreed. I don't have any secret insider facts, but perhaps Oracle rubbed Google in a way that was not entirely pleasurable with the 10-years-and-still-going-on Java lawsuit..
Flutter has similar tradeoffs as other cross platform tech such as React Native. Its great for simple apps that don't need platform specific UI or services.
Android is going the way of Google Reader. Kotlin is just to keep developers happy in the meantime before explicit deprecation. Fuchsia + Flutter is the new platform. Android Runtime will be emulated to allow backward compatible Android apps at a performance penalty, but Fuchsia will only have first class support for native compiled languages like Dart, Go, C++, Swift, similar to iOS.
Worse of all it that they don't acknowlege how bad it is for Kotlin as well.
What good is Kotlin's FFI to Java, if everything that you have at your disposal are out-of-date java libraries?
Even the new desugaring being done in R8 and D8 can only go as far as what ART is capable of, sometimes with worse performance, because the Java libraries rely on new JVM bytecodes and intrisic APIs.
So the only long term solution, assuming they keep ignoring modern Java, is to rewrite the world in Kotlin.
Arriving there, means that they could just rename ART into KVM and be done with it.
> At this point, I feel no language can compensate for the platform's out-of-date java libraries. I think Google has its priorities wrong: first should be recent java, second should be kotlin.
Kotlin works on all Android versions. Java updates don't. That doesn't mean Google shouldn't update the JVM on Android, it does however mean that any update to Kotlin immediately translates to wins across whole ecosystem, including people supporting Androids back to versions like 4.x, while Java updates don't.
It's a significantly better tradeoff - similarly like using TypeScript and polyfills gives you more powerful language on the web without restricting you only to newest browsers.
I had it look it up: ""collaborative goal-setting tool used by teams and individuals to set challenging, ambitious goals with measurable results"" -- among other definitions and graphs.
Is this management speak about vanity metrics? What do these measurements even mean?
The use of OKRs goes back to Andy Grove at Intel and while, like any tool, they can be misused they're definitely not just for vanity metrics. Some more useful OKRs might be things like:
- Increase number of signups for our app by 10%.
- Decrease the rate of customers churning off our platform by 20%.
- Reduce the median time it takes to ship a product out of our warehouse from 3 to 2 days.
I hold no grudge against Kotlin as the language. But underlying platform ... I'd rather prefer for them to switch to some native thing. It is really depressing to compare situations when I could whip up high performance small native GUI application and that atrocious monstrosity called Android studio produces regurgitates fat resource hogs.
It seems pretty likely that Flutter become the preferred stack at some point in the future given that it's used as the primary UI toolkit for Fuschia. That is still probably a few years away though.
I’m a bit surprised Google hasn’t bought JetBrains. I bet they could get it for something like $2bn, which seems like an entirely reasonable price to pay to help improve the Android ecosystem.
On the flip side, Apple could buy JetBrains and seriously mess with Google, although that acquisition wouldn’t really make as much strategic sense.
no UI toolkit I've used has anything nearly as complicated or error prone
it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS
as a result you need to implement masses of error prone boilerplate crap for each and every activity, and nearly everyone gets it wrong in subtle ways
rotate your screen? better implement that serialisation perfectly else the user will lose state when they rotate their device
a lot of apps just disable features like rotation, because they're too time consuming to implement (and a nightmare to test)
I've never understood why rotating the app resets the state like this without writing code to handle it. I mean even a lightweight website can change its interface on rotation using only CSS without losing any state. It's been several years since I messed with Android development. I assumed it would be fixed by now.
Because the alternative is not resetting the state and having to deal with the fallout. iOS does this and it's a source of even more strange bugs and side issues (based on doing cross-platform development across several teams).
This even led to the point where a huge amount of iOS apps simply banned rotation support to not deal with it.
It's just a different tradeoff. The underlying issue is that developers don't want to deal with storing the state which causes issues on lower end devices, which start to break as users multitask. The Android tools for that also aren't all that great - although I also haven't really seen any other toolkit do it better.
I'm an iOS developer and I'm not sure what you mean. Auto Layout provides enough hooks to take care of rotation. Why would rotation be a source of strange bugs and side issues?
Because not all the state and layout is handled by AutoLayout... and it has its own set of bugs. Heck, iOS apps themselves (iMessage, Springboard) and riddled with rotational layout bugs in iOS 12 and 13.
> it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS
This is literally how iOS and other mobile toolkits work as well.
e.g. Look at this issue[1] of Fragments in the LinearLayout, every now and then with the update of the SDK; the order of fragments changes i.e. with one SDK version the fragments are displayed in the order it was added 1,2,3,4 and with an update to SDK the order is 4,1,2,3 or any other.
For issues like this, every time I updated the SDK I had to spend lot of effort in testing and mitigating issues which were unwarranted. Meanwhile, my colleagues(whom I trained) who developed the same application for iOS didn't face such issues with API/Toolchain i.e. in iOS development what doesn't work, don't work and there is no hidden surprise with each SDK/Build Tools/NDK etc. updates because they are not updated separately.
I don’t see the problem with that diagram. It’s a consequence of your activity/fragment potentially being killed at any time, something you need to be aware of on mobile devices. iOS has same diagram.
Kotlin 1.4 is touting upto 3x compiler improvements.
The question here is about the future of Flutter. Why do Flutter/Dart when Android is officially throwing its weight behind Kotlin and Compose is going to be every bit as react-y as Flutter or SwiftUI.
Same applies to why ChromeOS when Android? Politics.
Management is throwing money at them and watching who brings the best numbers back home, kind of thing.
Although like ChromeOS was forced to eventually support Android, I imagine that Flutter will eventually loose the battle.
Betting on Dart was never a clever option to start with, and now with Xamarin/WinUI, JetPack Compose and SwiftUI all demoing Flutter like experiences, it is clear that the reasoning for Dart being a special case isn't really the case.
When will we have a proper LSP implementation for Kotlin that is maintained not by a single person but a full blown team?
JetBrains is very short-sighted about this[1], putting their own IDE-s success over the success of Kotlin: not healthy for the language if you ask me.
A lot of developers using Kotlin are also gaslighting everyone who doesn't want to use IntelliJ for Kotlin as if using the editor of your choosing is some sort of madness.
Kotlin needs to be a foundation, it clearly has a big community to drive the language and its accompanying tooling and integrations. Kotlin needs to be completely decoupled from JetBrains to succeed outside the JVM/java legacy areas.
The main problem with java is oracle though which lobby patent trolls its way towards almost zero progress for java in the past 10 years. Sure they release java 13 now but compared with the feature-set of Kotlin and swift it's rather pathetic. Especially considering the planned price model of java 9+.
Truth is Kotlin and Swift are just a form of developer lock-in. A webapp written in React inside of a chromium webview is fast enough for most apps use cases. (NO REACT NATIVE PLEASE)
The fact that Javascript is improved by many parties made the tooling and the performance of Chromium very fast.
Babel+Webpack are years ahead of the build systems for both Android and iOS.
Sublime and Atom are much leaner and better for coding than Android Studio and Xcode.
If that's the case, then you don't need an app in the first place, and shouldn't develop one.
We don't need apps for every online store and every website.
But Android is slowly limiting the power of apps further and further, until there won't be any need for apps anymore.
The whole point of apps is to interact with hardware browsers don't support, to interact with files and provide high-performance functionality. To speak protocols browsers have never even considered supporting.
No, not at all. A decent user experience requires using the native toolkit and behaving like an actual app, not appearing in the browser. Everything else is garbage.
Material Design for Android is just a design guideline about how the UI widgets are shaped.
You can easily implement it in html/css/javascript for the browser. The official Material Design docs refer to 4 platforms currently: Android, iOS, Web and Flutter.
You need a native app if you need native features not offered by the browser but you can still use chromium webview for the UI. That's my use case at www.waiterio.com.
A webview with React is fast enough for the UI but my app needs to speak with hardware using USB, TCP sockets and Bluetooth sockets.
I'm fully aware of WebUSB but it doesn't work well with the hardware I use. WebUSB seems like a prototype built to work for a demo with Arduino and that's it.
> But Android is slowly limiting the power of apps further and further
I believe Android is adding more fine grained control of apps power permissions but I'm not sure about the reduction in power.
> The whole point of apps is to interact with hardware browsers don't support
I agree on this, I don't criticize apps interacting with native API/SDK. I criticize the UI systems of native apps. On paper swift/kotlin should be fast but in practice Google put so much work in optimizing Chrome and Facebook put so much work on React that Chromium+React is faster than the native UI kits.
126 comments
[ 3.7 ms ] story [ 211 ms ] threadLook at chrome os fiasco. They had it for 6,7 years? They didn’t realized it until Microsoft did put effort to make their OS developer friendly that they should make chromeos developer friendly. Imagine how good chromeos was today if they have started to make it developer friendly in 2010 instead of 2017.
I'm waiting for a Linux phone
Sure choice of OS would be nice, but there's a huge number of man hours that go into making a nice touch UI. Something that experts don't tend to obsess over, unless paid.
The pixel's don't have a locked bootloader, and you could try one of the community builds, which I've done. But there's much less incentive lately. I used to root to tether, don't need to anymore.
Edit: I’m not sure why this question is getting downvoted.
Manufactures really hate the lack of flexibility and there is a small amount of justification: new hardware often does need new controls.
And of course many people like the flexibility of Android.
I personally hate it, but I understand why they do it. I just wish we could get a class leading vanilla Android phone. Pixel isn’t it.
It's just a different model. Single corporation stack gives you more consistency and less bloatware and OEM based stack gives you more market choice and greater accessibility.
Get a device with stock Android ROM and there is no issue
Things breaking randomly?
Nothing looking consistent?
Aping all the bad parts of the MS ecosystem while missing most of the good (I firmly believe desktop linux peaking with KDE 2 and has been consistently downhill ever sense)
I consider iOS to generally get the job done pretty well.
https://en.wikipedia.org/wiki/Nokia_N900
/s
I still have a pixel 1 from 4 years ago that I think just stopped getting major upgrades. Not great, but not bad. My samsung note 4 was around a year behind on updates, and felt very slow because of all the crapware. I switched to a nexus 5, with a much lower spec and it felt MUCH better. Even simple things like hitting the home button had much less lag.
I did end up installing Cyanogen on the Note 4 which made it feel quite a bit snappier.
In any case Kotlin/Native doesn't bring nothing to Android itself.
ART makes use of AOT/JIT with code cache, which is much better than straight AOT on languages with reflection, dynamic dispatch and dynamic loading everywhere.
This is why they gave up on pure AOT introduced during Android 5 and 6 lifetime.
Then the NDK is tailored for writing native libraries for consumption from ART, only exposing C bindings, even though most of the code is actually C++.
So hardly a win having Kotlin/Native there.
Overall I wouldn't say Android development is aweful, I think it's iOS is just marginally better. Swift is a nicer language than Kotlin but creating UI layouts sucks on iOS.
As for complexity, you hit the ceiling very fast, and the solution is to break up in smaller and smaller custom views and modifiers.
I'm not going to learn a new language which isn't used anywhere else AND a new UI toolkit just because Google's internal team structure has put them in a position to keep Dart going.
Back when Dart came out, it made sense. But Typescript came along, filled basically the same niche and got significant mindshare.
Not to mention that Flutter experience isn't nothing more than cute to anyone that has experience doing UI design on Common Lisp or Smalltalk environments, which I reckon all of us are quite old for SV standards.
EDIT: Or if you really want to be amazed go play with SELF.
That may be true, but right now, none of them has something as polished and usable as Flutter. And it looks like it will be many years before they do, all the while Flutter keeps getting better. So, if you have time to wait for these other platforms to catch up, go ahead while people who need to write code right now can enjoy something else.
> EDIT: Or if you really want to be amazed go play with SELF.
Oh come'on, are you really suggesting something that looks straight out of the early 90's is something that would amaze anyone today? Or there's something that actually looks and behaves modern out of the Self and Smalltalk world (certainly was not the case last time I checked, a few years back)?
What I am suggesting is that the reasoning why Dart instead of something else is flawed and can only be naively bought by those that lack experience in UI domain.
How pretty those UIs used to look like is secondary.
Flutter is being positioned to rescue Dart, and make it meaningful beyond the AdWord team, the place where it landed when all Dart designers eventually left Google.
Where is the "Google's Commitment to Dart" blog post?
I don't see any reason why Typescript (for example) couldn't be made to meet them (relatively easily).
They should dump the most widespread mobile operating system ecosystem... because some people think API's are "OO nonsense"? Would you also want Microsoft to abandon whole Windows ecosystem just because WinAPI dates back to Win16?
This is insanity and completely ignores the reasons why ecosystems get popular.
Don't let your fanboyism blind logical thinking.
I've used Java, Python, Ruby, Go and Kotlin. Kotlin is def my favorite and goto. Do you have any specific examples/complaints?
As for other languages: Python is ok for smaller stuff. I don't like Go. My favourite languages are probably Swift and Julia. And recently, I've grown to really like C++ although I used to hate it.
Barely. You can't even read a file without java.io.
Android is going the way of Google Reader. Kotlin is just to keep developers happy in the meantime before explicit deprecation. Fuchsia + Flutter is the new platform. Android Runtime will be emulated to allow backward compatible Android apps at a performance penalty, but Fuchsia will only have first class support for native compiled languages like Dart, Go, C++, Swift, similar to iOS.
</speculation>
Jetpack Composer is obviously they fighting back to the continuous flow of Flutter questions at Android conferences.
What good is Kotlin's FFI to Java, if everything that you have at your disposal are out-of-date java libraries?
Even the new desugaring being done in R8 and D8 can only go as far as what ART is capable of, sometimes with worse performance, because the Java libraries rely on new JVM bytecodes and intrisic APIs.
So the only long term solution, assuming they keep ignoring modern Java, is to rewrite the world in Kotlin.
Arriving there, means that they could just rename ART into KVM and be done with it.
Kotlin works on all Android versions. Java updates don't. That doesn't mean Google shouldn't update the JVM on Android, it does however mean that any update to Kotlin immediately translates to wins across whole ecosystem, including people supporting Androids back to versions like 4.x, while Java updates don't.
It's a significantly better tradeoff - similarly like using TypeScript and polyfills gives you more powerful language on the web without restricting you only to newest browsers.
^^ This precise phrasing looks like an OKR.
I had it look it up: ""collaborative goal-setting tool used by teams and individuals to set challenging, ambitious goals with measurable results"" -- among other definitions and graphs.
Is this management speak about vanity metrics? What do these measurements even mean?
O: improve the usability of Kotlin
KR: 90% of top 1K Android apps have Kotlin deps
Q4 score: 67% (achieved 60%, goal was 90%)
- Increase number of signups for our app by 10%.
- Decrease the rate of customers churning off our platform by 20%.
- Reduce the median time it takes to ship a product out of our warehouse from 3 to 2 days.
Well, it’s no surprise that google can run multiple projects that solves more or less the same thing.
On the flip side, Apple could buy JetBrains and seriously mess with Google, although that acquisition wouldn’t really make as much strategic sense.
I dont know... maybe if apple bought jetbrains they could get them to rewrite xcode for them. :/
this says it all: https://cdn1.hubspot.net/hubfs/2564010/The%20activity%20and%...
and it gets worse with every release
Every UI Toolkit has something similar.
Same events for IOS: https://developer.apple.com/documentation/uikit/app_and_envi...
it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS
as a result you need to implement masses of error prone boilerplate crap for each and every activity, and nearly everyone gets it wrong in subtle ways
rotate your screen? better implement that serialisation perfectly else the user will lose state when they rotate their device
a lot of apps just disable features like rotation, because they're too time consuming to implement (and a nightmare to test)
This even led to the point where a huge amount of iOS apps simply banned rotation support to not deal with it.
It's just a different tradeoff. The underlying issue is that developers don't want to deal with storing the state which causes issues on lower end devices, which start to break as users multitask. The Android tools for that also aren't all that great - although I also haven't really seen any other toolkit do it better.
That said, I agree. Rotation should not be conflated with general app suspension. They are two different concerns. iOS does this.
This is literally how iOS and other mobile toolkits work as well.
e.g. Look at this issue[1] of Fragments in the LinearLayout, every now and then with the update of the SDK; the order of fragments changes i.e. with one SDK version the fragments are displayed in the order it was added 1,2,3,4 and with an update to SDK the order is 4,1,2,3 or any other.
For issues like this, every time I updated the SDK I had to spend lot of effort in testing and mitigating issues which were unwarranted. Meanwhile, my colleagues(whom I trained) who developed the same application for iOS didn't face such issues with API/Toolchain i.e. in iOS development what doesn't work, don't work and there is no hidden surprise with each SDK/Build Tools/NDK etc. updates because they are not updated separately.
[1]https://issuetracker.google.com/issues/37086731
Jetpack Compose - a react like paradigm to build apps - is the future of android app development. And I could not be more excited.
Kotlin Multiplatform is on track (https://twitter.com/zsmb13/status/1202507590674112513) and will let ios apps be built using android studio without a Mac.
Kotlin 1.4 is touting upto 3x compiler improvements.
The question here is about the future of Flutter. Why do Flutter/Dart when Android is officially throwing its weight behind Kotlin and Compose is going to be every bit as react-y as Flutter or SwiftUI.
Management is throwing money at them and watching who brings the best numbers back home, kind of thing.
Although like ChromeOS was forced to eventually support Android, I imagine that Flutter will eventually loose the battle.
Betting on Dart was never a clever option to start with, and now with Xamarin/WinUI, JetPack Compose and SwiftUI all demoing Flutter like experiences, it is clear that the reasoning for Dart being a special case isn't really the case.
JetBrains is very short-sighted about this[1], putting their own IDE-s success over the success of Kotlin: not healthy for the language if you ask me.
A lot of developers using Kotlin are also gaslighting everyone who doesn't want to use IntelliJ for Kotlin as if using the editor of your choosing is some sort of madness.
Kotlin needs to be a foundation, it clearly has a big community to drive the language and its accompanying tooling and integrations. Kotlin needs to be completely decoupled from JetBrains to succeed outside the JVM/java legacy areas.
[1]https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan...
Kotlin, here have InteliJ, oh yeah there is also this 2nd class plugin for Eclipse, and nothing else for the others.
Nowadays I keep waiting for the JetBrains acquisition news story to pop up.
If that's the case, then you don't need an app in the first place, and shouldn't develop one.
We don't need apps for every online store and every website.
But Android is slowly limiting the power of apps further and further, until there won't be any need for apps anymore.
The whole point of apps is to interact with hardware browsers don't support, to interact with files and provide high-performance functionality. To speak protocols browsers have never even considered supporting.
Material Design for Android is just a design guideline about how the UI widgets are shaped.
You can easily implement it in html/css/javascript for the browser. The official Material Design docs refer to 4 platforms currently: Android, iOS, Web and Flutter.
https://material.io/components/app-bars-top/#
How do you implement diagonal corners on elements?
You can implement some of Material on the web, but not all of it - which is why many components and styles are missing
You need a native app if you need native features not offered by the browser but you can still use chromium webview for the UI. That's my use case at www.waiterio.com. A webview with React is fast enough for the UI but my app needs to speak with hardware using USB, TCP sockets and Bluetooth sockets.
I'm fully aware of WebUSB but it doesn't work well with the hardware I use. WebUSB seems like a prototype built to work for a demo with Arduino and that's it.
> But Android is slowly limiting the power of apps further and further
I believe Android is adding more fine grained control of apps power permissions but I'm not sure about the reduction in power.
> The whole point of apps is to interact with hardware browsers don't support
I agree on this, I don't criticize apps interacting with native API/SDK. I criticize the UI systems of native apps. On paper swift/kotlin should be fast but in practice Google put so much work in optimizing Chrome and Facebook put so much work on React that Chromium+React is faster than the native UI kits.