6 ms·

This is quite interesting to see, as I recall experimenting with something similar a few years ago. In that case, borne out of anger and frustration from how sl

by g_p 6y ago

This is quite interesting to see, as I recall experimenting with something similar a few years ago. In that case, borne out of anger and frustration from how slow Android was at some things, I complained to one of the engineers I had brought onboard about how a 1970s computer was vastly more responsive and performant (to the user's perspective) than these modern (in ~2016) Android devices. We ended up building a prototype of a vertical scrolling ListView, implemented entirely in C, implementing all the "normal" functionality required to allow Android to use it. I believe my initial frustration was borne from performance tracing of an app we were developing, and finding the amount of time spent in nested constructors and other kinds of inherited object-oriented bloat was actually impacting on the user perceived performance (users said it was slow to scroll). My hypothesis was that if the functionality itself was implemented in C, properly and efficiently, with none of these extra layers of abstraction, it would be faster. That was definitely validated. I don't recall the figures now, but you could scroll a list with no perceptible latency as fast as you liked, with no stutter. The performance traces were nice and normal. It was smooth and fast. Mobile apps were something I got far away from for a while, but every time I return, I'm disappointed to see an ecosystem of re-inventing the same (boilerplate) wheel, and running the same code. For the number of layers of abstraction I saw the OS burning cycles on, it is absurd to me why the "end-developer" is left to do so much boilerplate coding! Surely at least one of those layers of abstractions could get developers to a place of implementing their own logic, rather than platform-specific logic. Case in point, the Android activity lifecycle (!)

nexuist 6y ago
It is a bit confusing why developers are still expected to implement entire UIs themselves. Almost every app today that's not a game uses the same exact layout: tables and grids. As a mobile app developer I could save so much time by having the OS ask me what I want to put in these tables or grids, rather than having to implement the UITableViews and ListViews verbatim in almost every single project. Since we're on this topic: Why is there still no native user login/registration widget? Why can't the user just press a button to have the OS autofill and save all of their information across all of their apps? I know someone is going to say you can already do this, but the truth is, you still can't do it reliably enough to make it the first option. Sure, password manager extensions are supported by the OS, but I still have to go through whatever native interface my password manager wants to show me before I can get close to having a form filled out. In most cases, for most form fields, I am not prompted to fill anything out unless I'm in a web browser. It's a massive waste of time and developer energy considering these forms almost universally require the same input: name, profile icon, email, password.
- gamegod 6y ago
  They want you to use Google Sign-In, so Google can lock your users into their SSO. The more locked into the Google ecosystem people are, the easier it is for them to keep their search ad monopoly in the long term.
- g_p 6y ago
  Can't agree enough - when you delve beneath the scenes, it gets so ridiculously complex for something that just shouldn't be. For a List view, I can understand making something to put into that view. I miss the days of VB6 and creating a GUI in drag-and-drop, aligning everything, and then double clicking each component to add add the default event handler. Occasionally I didn't want the default event handler, so I'd pick another one. Done! I feel like with VB6 (and similar tools of the era), it was straightforward - I knew if I wanted to set the Label of Button1 programmatically as the window opened, I'd create a Window1.OnLoad method, and set Button1.Label to whatever I wanted... Doing this on Android will entail reading about the opinionated Android lifecycle model, which seems a good way of the OS forcing Devs to handle tasks that any sane OS should (i.e. handling loading, suspending and resumption of the app...) That should be given to me by the platform as a default! Overrideable if needed. Why must I totally redraw everything if the user rotates their phone? Can't I get shown 2 templates when I draw my UI, and make the landscape one a copy of the portrait, with some common sense adjustments (horizontal list view rather than vertical)? Then I wouldn't have to save and restore all state if the user jostles the device! To your point about login, absolutely - if there was a simple Login View (I believe I recall one in VB6, just saying...) it would probably reduce a whole host of security issues from Devs doing it wrongly and logging credentials to places they don't belong, or putting them places they shouldn't be. It just seems crazy that for such dense and weighty platforms, we don't get any of this functionality included properly by the OS!
  - realharo 6y ago
    >I miss the days of VB6 and creating a GUI in drag-and-drop, aligning everything That was a fixed non-resizable layout, showing static content. >I knew if I wanted to set the Label of Button1 programmatically as the window opened, I'd create a Window1.OnLoad method, and set Button1.Label to whatever I wanted... That works initially for simple UIs, but gets ugly really fast once you need to start displaying data items, including possible loading states and error states, etc. Mobile apps tend to fetch content from the internet a lot. You could also do your example in Android - just add a setText call to onStart of whatever empty Activity the wizard created for you. Jetpack Compose promises to make Android UI development much nicer in the future https://developer.android.com/jetpack/compose https://developer.android.com/jetpack/compose - there is bit of a trend of mobile moving towards more React-like UI patterns (e.g. SwiftUI, Flutter, etc.).
phkahler 6y ago
And dont forget they like you to use the preferred language for the environment.
- g_p 6y ago
  Yeah I never understood why everything should be so tightly bound to a single language... We mastered the idea of different software on a desktop PC using different languages a long time ago. Yet on mobile, given the fragmented and non-standardised ARM ecosystem and runtime environment, we have to put up with the complex abstractions given to us by the operating system... I can't access the accelerometer without using the blessed Google API for it, because I can't know where on earth the user's phone manufacturer saw fit to put it, nor even what chip they used... At least on x86 PC we got most of this stuff nailed down long ago, and we can boot an operating system without the permission of our motherboard maker and CPU designer.
  - monocasa 6y ago
    It's not like accelerometers are standardized hardware on PC platforms either.
    - shakna 6y ago
      No... But the drivers _are_ expected to implement a standardised interface. So whilst you're beholden to the OS on how to access it, it isn't an insanely obtuse Android-style interface. For example, if the driver implements iio/accel, like it should for a Linux device, then you can either use the C-interface (including via FFI), or just treat it like a file and read/write from it however you feel like in your chosen language. You don't _have_ to use C, and C-style semantics, to get at the accelerometer. You can use any language that can either read/write files, or has an interface to FFI.
      - monocasa 6y ago
        What's the standard driver interface for accessing accelerometers on Linux then?
vvanders 6y ago
If you call malloc/free in the inner loop of a C program you'll have the same problems. Android has a RecyclerView for the exact reasons that you call out. The framework is far from perfect but at least from the details you listed I don't see why you had to drop to C.
- g_p 6y ago
  Just for clarity, we resorted to C mostly as an experiment to prove our hypothesis that the abstraction and instantiation overhead was genuinely ridiculous. I don't have any of the screenshots to hand sadly now, but the performance traces were just appalling. And this was across the board Our experiment in C showed that it was possible to implement a simple Android "view" or "control" (however it should be called), in native C, with significantly better performance than Android itself provided. It wasn't intended to be the least effort solution, rather a side project to prove something we always suspected. RecyclerView is a start, but I believe we still found it slow. The delays from malloc()/free() were very significantly lower in impact, though admittedly we weren't doing them in nested loops or anything. I would like to think using C forced us to think more efficiently and we probably did a few little optimizations (noting it was just a side project) that were a bit like the recycler view does, to create enough memory in advance for a feasible scroll buffer both up and down, and fill it as the user moved.
- toast0 6y ago
  The recycler view means at least you don't need to rebuild the object trees when you want to replace something, but it's still super slow to build it the first time.
  - g_p 6y ago
    Must confess I had gotten as far as possible from UI development in Android by the time recycler views came around (or at least I became aware of them), but this sounds very familiar. I think we were talking about hundreds of milliseconds to setup the view, full of nested constructors calling each other, calling their inherited super class constrictor, calling a few factories too for good measure. It was liberating to reverse all that obfuscation and abstraction, and get all the logic into one single file, as a series of functions implementing the Android-expected API, without having to call out to a black box of stutters and constructors!
on_and_off 6y ago
> I'm disappointed to see an ecosystem of re-inventing the same (boilerplate) wheel Do you have some examples ? Nowadays with "modern" Android dev practices, the amount of boilerplate I write in day to day dev is pretty minimal.
- g_p 6y ago
  The examples given by Android Annotations spring to mind - http://androidannotations.org/ http://androidannotations.org/ To throw some trivial examples from the top of my head, to just make a button do something when clicked, you need to call setOnClickListener to a new OnClickListener lambda type thing. I just found absolutely every step of the way clunky and unwieldy. The amount of typing and keystrokes required to achieve anything was 5x more than it seemed to need to be, even with auto completions. I just wished for an event driven model like VB6 and old desktop programming, where the focus of the code was on my own logic and functionalities, rather than remembering I have to manually fetch every view by ID because of some arcane reason to do with how Android splits the UI and Java worlds! Maybe my issues are outdated and fixed? Maybe android annotations has come far enough to alleviate my annoyances? I guess the day I can write a pleasant looking Android app that doesn't require me to think about someone else's vision for how my activity should behave in a complex lifecycle of different events, I'll be happy... What happened to sane defaults? Maybe my app (with its activities inheriting from activity) should have sane defaults already in place from the parent class, avoiding my need to even see such horrors, unless I want to?
  - on_and_off 6y ago
    oh wow that's one blast from the past ! I remember that project from very long ago (I never used it for various reasons) hmm As far as click goes -> myButton.setOnClickListener { doSomething() } kotlin makes this pretty minimal, I don't really see much we can remove there
    - pjmlp 6y ago
      If Java had proper support, the click example would be quite similar.

by g_p 6y ago

nexuist 6y ago

It is a bit confusing why developers are still expected to implement entire UIs themselves. Almost every app today that's not a game uses the same exact layout: tables and grids. As a mobile app developer I could save so much time by having the OS ask me what I want to put in these tables or grids, rather than having to implement the UITableViews and ListViews verbatim in almost every single project. Since we're on this topic: Why is there still no native user login/registration widget? Why can't the user just press a button to have the OS autofill and save all of their information across all of their apps? I know someone is going to say you can already do this, but the truth is, you still can't do it reliably enough to make it the first option. Sure, password manager extensions are supported by the OS, but I still have to go through whatever native interface my password manager wants to show me before I can get close to having a form filled out. In most cases, for most form fields, I am not prompted to fill anything out unless I'm in a web browser. It's a massive waste of time and developer energy considering these forms almost universally require the same input: name, profile icon, email, password.

gamegod 6y ago
They want you to use Google Sign-In, so Google can lock your users into their SSO. The more locked into the Google ecosystem people are, the easier it is for them to keep their search ad monopoly in the long term.
g_p 6y ago
Can't agree enough - when you delve beneath the scenes, it gets so ridiculously complex for something that just shouldn't be. For a List view, I can understand making something to put into that view. I miss the days of VB6 and creating a GUI in drag-and-drop, aligning everything, and then double clicking each component to add add the default event handler. Occasionally I didn't want the default event handler, so I'd pick another one. Done! I feel like with VB6 (and similar tools of the era), it was straightforward - I knew if I wanted to set the Label of Button1 programmatically as the window opened, I'd create a Window1.OnLoad method, and set Button1.Label to whatever I wanted... Doing this on Android will entail reading about the opinionated Android lifecycle model, which seems a good way of the OS forcing Devs to handle tasks that any sane OS should (i.e. handling loading, suspending and resumption of the app...) That should be given to me by the platform as a default! Overrideable if needed. Why must I totally redraw everything if the user rotates their phone? Can't I get shown 2 templates when I draw my UI, and make the landscape one a copy of the portrait, with some common sense adjustments (horizontal list view rather than vertical)? Then I wouldn't have to save and restore all state if the user jostles the device! To your point about login, absolutely - if there was a simple Login View (I believe I recall one in VB6, just saying...) it would probably reduce a whole host of security issues from Devs doing it wrongly and logging credentials to places they don't belong, or putting them places they shouldn't be. It just seems crazy that for such dense and weighty platforms, we don't get any of this functionality included properly by the OS!
- realharo 6y ago
  >I miss the days of VB6 and creating a GUI in drag-and-drop, aligning everything That was a fixed non-resizable layout, showing static content. >I knew if I wanted to set the Label of Button1 programmatically as the window opened, I'd create a Window1.OnLoad method, and set Button1.Label to whatever I wanted... That works initially for simple UIs, but gets ugly really fast once you need to start displaying data items, including possible loading states and error states, etc. Mobile apps tend to fetch content from the internet a lot. You could also do your example in Android - just add a setText call to onStart of whatever empty Activity the wizard created for you. Jetpack Compose promises to make Android UI development much nicer in the future https://developer.android.com/jetpack/compose https://developer.android.com/jetpack/compose - there is bit of a trend of mobile moving towards more React-like UI patterns (e.g. SwiftUI, Flutter, etc.).

phkahler 6y ago

And dont forget they like you to use the preferred language for the environment.

g_p 6y ago
Yeah I never understood why everything should be so tightly bound to a single language... We mastered the idea of different software on a desktop PC using different languages a long time ago. Yet on mobile, given the fragmented and non-standardised ARM ecosystem and runtime environment, we have to put up with the complex abstractions given to us by the operating system... I can't access the accelerometer without using the blessed Google API for it, because I can't know where on earth the user's phone manufacturer saw fit to put it, nor even what chip they used... At least on x86 PC we got most of this stuff nailed down long ago, and we can boot an operating system without the permission of our motherboard maker and CPU designer.
- monocasa 6y ago
  It's not like accelerometers are standardized hardware on PC platforms either.
  - shakna 6y ago
    No... But the drivers _are_ expected to implement a standardised interface. So whilst you're beholden to the OS on how to access it, it isn't an insanely obtuse Android-style interface. For example, if the driver implements iio/accel, like it should for a Linux device, then you can either use the C-interface (including via FFI), or just treat it like a file and read/write from it however you feel like in your chosen language. You don't _have_ to use C, and C-style semantics, to get at the accelerometer. You can use any language that can either read/write files, or has an interface to FFI.
    - monocasa 6y ago
      What's the standard driver interface for accessing accelerometers on Linux then?

vvanders 6y ago

If you call malloc/free in the inner loop of a C program you'll have the same problems. Android has a RecyclerView for the exact reasons that you call out. The framework is far from perfect but at least from the details you listed I don't see why you had to drop to C.

g_p 6y ago
Just for clarity, we resorted to C mostly as an experiment to prove our hypothesis that the abstraction and instantiation overhead was genuinely ridiculous. I don't have any of the screenshots to hand sadly now, but the performance traces were just appalling. And this was across the board Our experiment in C showed that it was possible to implement a simple Android "view" or "control" (however it should be called), in native C, with significantly better performance than Android itself provided. It wasn't intended to be the least effort solution, rather a side project to prove something we always suspected. RecyclerView is a start, but I believe we still found it slow. The delays from malloc()/free() were very significantly lower in impact, though admittedly we weren't doing them in nested loops or anything. I would like to think using C forced us to think more efficiently and we probably did a few little optimizations (noting it was just a side project) that were a bit like the recycler view does, to create enough memory in advance for a feasible scroll buffer both up and down, and fill it as the user moved.
toast0 6y ago
The recycler view means at least you don't need to rebuild the object trees when you want to replace something, but it's still super slow to build it the first time.
- g_p 6y ago
  Must confess I had gotten as far as possible from UI development in Android by the time recycler views came around (or at least I became aware of them), but this sounds very familiar. I think we were talking about hundreds of milliseconds to setup the view, full of nested constructors calling each other, calling their inherited super class constrictor, calling a few factories too for good measure. It was liberating to reverse all that obfuscation and abstraction, and get all the logic into one single file, as a series of functions implementing the Android-expected API, without having to call out to a black box of stutters and constructors!

on_and_off 6y ago

> I'm disappointed to see an ecosystem of re-inventing the same (boilerplate) wheel Do you have some examples ? Nowadays with "modern" Android dev practices, the amount of boilerplate I write in day to day dev is pretty minimal.

g_p 6y ago
The examples given by Android Annotations spring to mind - http://androidannotations.org/ http://androidannotations.org/ To throw some trivial examples from the top of my head, to just make a button do something when clicked, you need to call setOnClickListener to a new OnClickListener lambda type thing. I just found absolutely every step of the way clunky and unwieldy. The amount of typing and keystrokes required to achieve anything was 5x more than it seemed to need to be, even with auto completions. I just wished for an event driven model like VB6 and old desktop programming, where the focus of the code was on my own logic and functionalities, rather than remembering I have to manually fetch every view by ID because of some arcane reason to do with how Android splits the UI and Java worlds! Maybe my issues are outdated and fixed? Maybe android annotations has come far enough to alleviate my annoyances? I guess the day I can write a pleasant looking Android app that doesn't require me to think about someone else's vision for how my activity should behave in a complex lifecycle of different events, I'll be happy... What happened to sane defaults? Maybe my app (with its activities inheriting from activity) should have sane defaults already in place from the parent class, avoiding my need to even see such horrors, unless I want to?
- on_and_off 6y ago
  oh wow that's one blast from the past ! I remember that project from very long ago (I never used it for various reasons) hmm As far as click goes -> myButton.setOnClickListener { doSomething() } kotlin makes this pretty minimal, I don't really see much we can remove there
  - pjmlp 6y ago
    If Java had proper support, the click example would be quite similar.