3 ms·

We definitely don't intend to push you into Material... can you elaborate on that? What would we have to change for you to think we were not pushing you into Ma

by Hixie 8y ago

We definitely don't intend to push you into Material... can you elaborate on that? What would we have to change for you to think we were not pushing you into Material? Regarding the crash logs, it has definitely helped us improve stability. We do try hard to notify you that it's happening. It's opt-out because people don't tend to opt in to that kind of thing and so the data would be more or less useless (not representative of real usage) if we made it opt-in.

hardwaresofton 8y ago
Sorry for the delay in response, I didn't see this. I think the problem is kind of endemic -- it's kind of like all the documentation and everything always starts from a Material component. Like if you look at provided scaffolds and you see CupertinoScaffold in the Widget Index[0], you might expect MaterialScaffold to be an option as well, but it's just "Scaffold". Little things like this indicate that you expect "MaterialScaffold" to be the default resting state. 99% of the time when I'm writing an app I have the design already and it may or may not be in material style or Cupertino style -- I personally would expect a framework to offer general tools first then the specializations. There are a bunch of other example of components that only really work correctly in the Material context. It's not a huge thing, and Google does have a pony in the race (which makes it easier for me to tinfoilhat about it), you have every right to push material as the default/make it easier to work with -- but I enjoy not having any such bias with Nativescript, even if it costs me slightly more work to get components that are stylistically coherent with either paradigm. From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google". To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far. [0]: https://flutter.io/docs/reference/widgets https://flutter.io/docs/reference/widgets

by Hixie 8y ago

hardwaresofton 8y ago

Sorry for the delay in response, I didn't see this. I think the problem is kind of endemic -- it's kind of like all the documentation and everything always starts from a Material component. Like if you look at provided scaffolds and you see CupertinoScaffold in the Widget Index[0], you might expect MaterialScaffold to be an option as well, but it's just "Scaffold". Little things like this indicate that you expect "MaterialScaffold" to be the default resting state. 99% of the time when I'm writing an app I have the design already and it may or may not be in material style or Cupertino style -- I personally would expect a framework to offer general tools first then the specializations. There are a bunch of other example of components that only really work correctly in the Material context. It's not a huge thing, and Google does have a pony in the race (which makes it easier for me to tinfoilhat about it), you have every right to push material as the default/make it easier to work with -- but I enjoy not having any such bias with Nativescript, even if it costs me slightly more work to get components that are stylistically coherent with either paradigm. From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google". To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far. [0]: https://flutter.io/docs/reference/widgets https://flutter.io/docs/reference/widgets