Hacker News Reader

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

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.

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.

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