6 ms·

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:

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.).
  - g_p 6y ago
    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.
rahkiin 6y ago
SwiftUI has this list functionality. You just loop over a list of items and set how to show it. SwiftUI will do the rest.
- g_p 6y ago
  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)
  - rahkiin 6y ago
    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
    - IggleSniggle 6y ago
      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.
mschuster91 6y ago
> 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)
- nexuist 6y ago
  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.
realharo 6y ago
>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 https://firebase.google.com/docs/auth/android/firebaseui but haven't used it myself.
rohan1024 6y ago
Flutter does exactly what you are expecting. Have you tried it? If not, give it a try!
- nexuist 6y ago
  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
kllrnohj 6y ago
> 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/ https://material.io/develop/android/components/lists/

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.).
- g_p 6y ago
  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.

rahkiin 6y ago

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

g_p 6y ago
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)
- rahkiin 6y ago
  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
  - IggleSniggle 6y ago
    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.

mschuster91 6y ago

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

nexuist 6y ago
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.

realharo 6y ago

>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 https://firebase.google.com/docs/auth/android/firebaseui but haven't used it myself.

rohan1024 6y ago

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

nexuist 6y ago
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

kllrnohj 6y ago

> 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/ https://material.io/develop/android/components/lists/