Comment by g_p | Hacker News Reader

Comment by g_p | Hacker News Reader

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 (!)

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.

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.

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!

>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 - there is bit of a trend of mobile moving towards more React-like UI patterns (e.g. SwiftUI, Flutter, etc.).

Thanks for mentioning Jetpack Compose - not something I had heard of. Sounds like there is a growing trend towards declarative UI models, and that doesn't seem too bad. I don't particularly take offence with using XML to define the UI as such, but the clunky integration with Java was what annoyed me.

Agreed regarding the limitations of VB6 to static and non resizeable content, though I suppose from a developer perspective it worked nicely. It just seems genuinely strange we haven't seen innovation to improve on the UI design side. Maybe the declarative shift will give us this though!

Regarding the dynamic fetching and challenges there, absolutely this is the new challenge for an app model. But equally, surely this kind of logic is now the new "boilerplate"? Most apps need (or would benefit from) some kind of smart lazy loading. Can totally get my head around that, and clearly we need to work asynchronously. But I've never really seen anything that fit the bill for solving this, and it never felt like Android was trying to improve it itself.

To my mind the API should be elegant to the point of near invisibility, for simple tasks - assuming I already know the URL to fetch from and any HTTP Auth is handled by my HTTP library, in an ideal world, I'd just say where to get the "data stuff" from, and then tell it what to do when that happens. In this ideal world, caching helps to keep the UI responsive (and fresh) with minimum need to tweak this unless I want to.

It just feels to me that this should be a standard solved problem, either provided by the API, or by a library everyone uses near universally. I'm guessing the fact it's not the case means there's too many complex edge cases (but I could easily envisage a library telling me to provide it a function to call if there's a connectivity issue, and me being able to simply implement my desired logic to pop a little warning above the content, showing an exclamation mark and saying there are gremlins and content might be stale.

> That was a fixed non-resizable layout, showing static content.

It eventually morphed into the Windows Forms builder which handled dynamic layouts quite well, if a little different to most. Elements could be "anchored" to specific points of their container, so you button 10px off the bottom left would always be 10px off the bottom left, elements you wanted to grow to fill available space could be anchored on either side. All handled well by the visual designer.

Generally I prefer the gtk/qt method of just writing code, but the forms builder works really well too, both options are much better than the xml mess that is android and windows development these days.

This actually predates Windows Forms - it's the model used by Delphi/VCL (and these days, Lazarus). However, anchors are nowhere near as flexible as layout managers, and there are many things that they can't handle. For example, when localizing UI, length of labels can change substantially, which requires the other controls that they're labeling to be moved around.

Delphi definitely handles resizable layouts and data loading nicely: I’ve played around with again via Lazarus, and the experience is much nicer than any alternative I’ve seen, even for complicated layouts.

> 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!

Android Studio almost does this - you still have to connect the event handler in the Java code, but the display itself is drag-and-drop:

https://developer.android.com/studio/write/layout-editor#int...

Looks like the android studio setup is better than the old eclipse one. I'd love to be able to double click a control there and have a default event handler appear in my code, ready for me to add event logic.

This does look pretty nice however, though I imagine it's a one way sync, so only visualising the UI from the XML file, rather than letting you visualise and tweak your UI after seeing it populated with content that gets loaded in by Java code? I guess as everything has evolved, the amount of the actual layout contained in the XML is reducing over time.

Maybe this is where the more declarative approaches will make it easier to reconcile the layout and the content-filled layout.

> though I imagine it's a one way sync, so only visualising the UI from the XML file, rather than letting you visualise and tweak your UI after seeing it populated with content that gets loaded in by Java code?

Yeah, though you can (for example) put default text in that then gets replaced by the Java code before anyone sees it. I don't think it's very thorough for the other widget types, though.

> I guess as everything has evolved, the amount of the actual layout contained in the XML is reducing over time.

This is still all XML, it's just auto-generated for you through the GUI editor.

Thanks - I think I perhaps didn't explain what I was "asking for" that well - what I meant was akin to what Jetpack Compose looks to do for Android (thanks to another commenter for pointing it out!) with the "@Preview" notation to create some "real example" UIs that can contain real exemplar content.

You don't need to miss it. I still use Visual Basic .Net for a successful commercial Windows application. It's still that simple. I think C# is just the same, isn't it? Windows is also the most popular desktop OS by a large margin. It's not dead just because phones exist.

Making a performant list view is actually a very non-trivial task. All the weird complexity you see in the API is there to make it possible at all to have large list views that do not absolutely kill your phone.

That’s only necessary because a View in Android is ridiculously heavyweight and slow.

I ported a game from iOS to Android and just wrote simple C wrappers for all the views. I didn’t bother much with optimization, but lists with hundreds of complex items worked just fine, no lazy loading or recycling necessary.

This is a great example of technology going in cycles. From my own experience:

1. ZX Spectrum - PLOT and LINE commands, graphics trivial and fun;

2. Using an X windows library in the early '90s writing 'idl' files to specify windows = super low-level stuff, 'attachments' to connect widgets together, incredibly easy to mess up, eg "where tf is my window? Oh right, it's that little ball of pixels over there, I must've messed my attachments up and the whole thing has scrunched in on itself like an effing neutron star"

3. VB6 - back to nice, easy, fun;

4. The Web | Mobile. JavaScript libraries (l'embarras du choix), or complex UI frameworks; back to pain.

Try Qt with QtDesigner/Creator it gives you pretty much the same experience as VB6 did. Knocking up UIs that look good, perform well and scale as the windows are resized is fast and easy. One of the best parts of Qt and stuff that generally speaking works really well.

SwiftUI has this list functionality. You just loop over a list of items and set how to show it. SwiftUI will do the rest.

Well that helps me pick my next book to read!

I was looking at Flutter recently and admiring the idea of cross platform (if you're going to use abstractions, at least let's get some benefit from them as developers!), but also grabbed a book about Swift UI too, just to see what was going on in iOS.

That sounds rather pleasant if it is performant (as I imagine it will be on iOS)

I can only recommend it. It is still in beta though. SwiftUI is also cross platform: the generated UI is different on mac than iphone. With SwiftUI you are programming more with semantics than before

SwiftUI is not crossplatform in the context of Flutter, which builds to iOS, Android, web, macOS, Windows, and Linux, natively.

I've only played around with it a little bit, but it's quite an impressive achievement. It doesn't quite feel native, but it's pretty damn close.

If you are familiar with React Native, it is very similar in both its coding style and in how it works. It's like the virtual DOM with the middleman of the DOM stripped out.

> It's a massive waste of time and developer energy considering these forms almost universally require the same input: name, profile icon, email, password.

There's more to a user login/registration flow, way more, and that list is only what I could manage to write down in 5 minutes:

1. Support for a variety of custom 2FA methods - SMS, Yubikey/other tokens, RSA dongles, chip-TAN (used by German Sparkasse credit unions, works with an external chip reader), phone calls, the list is endless

2. Support for GDPR compliance (i.e. double opt in confirmation of email addresses)

3. Support for SSO solutions, with the added complexity that each app needs their own set of tokens for each social network

4. Support for password recovery in all the loads of combinations

5. Support for enterprise authentication (SAML / shibboleth)

Sure! I agree. There are plenty of different authentication standards. But if these are all highly ubiquitous standards implemented by a myriad of apps, why is this work passed on to the developer, and not handled by the operating system? Why can't I pass my OAuth tokens to this hypothetical login view (a la Firebase Auth), and let that handle signing my user in through X service? Why can't I just provide a shibboleth endpoint and let the native view handle exchanging tokens?

I'm not asking Apple or Google to figure out my highly custom one-and-done authentication protocol that relies on smoke signals and written poems to let the user sign in. I'm asking them to give me the tools to support these decades-old standards, standards that basically every app has to support already. It makes sense especially in the context of GDPR to provide system-wide support to a legal problem, as opposed to each developer having to solve the same exact problem over and over again.

>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.

A basic single-item-type RecyclerView on Android doesn't have that much boilerplate over just creating the "item" layout in any other way (which is still worse than a React-like automatic reconciliation would be). There are much bigger issues with Android's UI.

>I know someone is going to say you can already do this,

I know about https://firebase.google.com/docs/auth/android/firebaseui but haven't used it myself.

Flutter does exactly what you are expecting. Have you tried it? If not, give it a try!

Funny that you mention that. I just spent a year developing and self publishing a Flutter app on the Play/App store, which is where my gripes with native development come from :P

> Almost every app today that's not a game uses the same exact layout

The problem is that they don't. This is why RecyclerView took off over ListView, even though "out of the box" RecyclerView requires more work to use. ListView was that thing that everyone does - just define your bindings, and you're done. But it wasn't flexible enough. Everyone wants that one special change for their special app.

But you're not expected to start from scratch, it's why things like the Material Design Components library exists: https://material.io/develop/android/components/lists/

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.

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.

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.

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!

Yeah, I'm usually a backend person, but I have an app I want to build, because everything else that does it sucks. But the learn how to make Android UI stuff I need to do is all deathly slow, or says 'make a webview and do it there' if you want it to be fast, which is peobably true, but depressing.

I just want to fetch some data, and put it in something vaguely tabular. I can prefetch the data, so I have it when the app needs to draw, but I can't make drawing fast, which is super demotivating.

On the other hand, now I understand why even with 4GB of ram, Android is sluggish, and it's not worth using a 2GB phone anymore.

I'm in a similar position, although probably not with an idea for what I want to build right now. But been there in the not so distant past.

For me the "logic" part is easy - I can make it in a terminal UI fine. I could probably make it in a VB6 style UI similarly easily just from ancient muscle memory.

I have never actually built any personal "app" for Android, despite having been heavily into it since 2009, running an app development company (!) and doing a load of platform engineering. It just isn't enjoyable for me. Demotivating is a great way to describe it.

Any time I have an idea, the UI side ends up frustrating as the model for positioning components is very prescriptive and doesn't help me build fast. Once I get that UI, I then start uncovering horrific complexities in how it's bad to run things on the UI thread, but then apparently none of the effort has gone into making it straightforward not to do so.

The closest I got to something that made sense for me was Android Annotations (and a similar project whose name I forget) - http://androidannotations.org/ This made it less painful for me, although sadly it wasn't quite pain-free enough for me to actually cross the line and build a personal side project app...

If only it was possible to more easily chain together the APIs exposed by Android, without having to immerse oneself in the highly opinionated way of doing so "correctly", and instead focus on the logic required to get the data to the right address in memory.

You can easily run stuff off the UIthread with Kotlin an Coroutines

You might find android annotations interesting, or https://android.jlelse.eu/the-ultimate-android-development-f...

Came across this (and remembered about Android annotations, which made life a bit less painful) and thought it might help you if you were trying to build the app equivalent of some basic CRUD stuff, and fetch some data into a view etc.

> 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.

The examples given by Android Annotations spring to mind - 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?

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

If Java had proper support, the click example would be quite similar.

Are you saying that Android doesn't have proper Java support? In what way? I thought Java lambdas could be used with SAM interfaces, just like in Kotlin.

(Or are you saying that if Java supported Kotlin syntax it would look similar to Kotlin?)

Android Java is a Java 8 subset, they are still catching up with Java 8.

https://developer.android.com/studio/preview/features#j8-des...

Jake Warthon was doing contributions to support newer versions, but it remains a lotto what might eventually be supported long term, thus forcing Java library authors to have Android specific versions, or constrain themselves to what all flavours might actually support.

As for SAM, yes you are right, but many Android developers only know Android Java and still think Java == 6 || 7.

Please never use androidannotations in a modern Android project. The codegen it does behind the scenes makes your compile times so much longer. It's been less than a month since it finally supported incremental compilation support. In addition, it's a lot of non configurable magic that will bite you if you ever need to do something a bit funky with different resources.

If you use kotlin, you can make use of synthethics which will automatically provide you with variables that bypass the need of calling `findViewById<T>`, including proper type inference. A slight step further, ViewBindings actually also give you type safety and null safety, depending on your layout. Then it simply becomes a matter of `binding.buttonThatIsNotHereOnLayout2?.setOnClickListener(this::onButtonClickedDoThing)`. Even if using Java, you can use the shorthand lambdas to do button.setOnClickListener((v) -> this.onButtonClicked()).

Much of the rest that is shown are matters of dependency injection, or are fixed with newer updates to the Android SDK. Fragments can have their layouts specified directly in their constructor, AsyncTasks have been deprecated over and over again, etc. AndroidAnnotations was alright in 2015-2016, where the Android API was truly dreadful. It still is, but most of the truly awful things are gone.

Thanks - sounds like the world of Android development has evolved a lot since I last looked at it. There's a lot of talk around Kotlin, so I guess it's time to look at that transition and what happened there.

It sounds promising if most of the bad and horrifying things are gone since the days of 2015/2016 when these tools helped!

Don't get me wrong, there's still plenty of crap. Google dug themselves in a deep hole with their god activities and insane fragment lifecycle. But if anything... The fragment lifecycle is about the worst there is now. The AndroidX libraries have done it a lot of good.

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

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.

It's not like accelerometers are standardized hardware on PC platforms either.

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.

What's the standard driver interface for accessing accelerometers on Linux then?

https://wiki.st.com/stm32mpu/wiki/IIO_overview

https://wiki.analog.com/software/linux/docs/iio/iio

...and Linux input ...and one off interfaces based on driver.

The point of view of a mobile platform is that the more you expose of the hardware the more your future hardware is restricted.

Reply on news.ycombinator.com