I’ve got an app where it’s not appropriate for views to be created using PushTo and allowing the user to go back to the previous screen. So I have to use App.CurrentScreen.Content to move to the next step. This seems like old fashioned spaghetti code programming to me. Anybody else bugged by this?
My last app uses exclusively app.currentScreenContent. I don’t see how this is more spaghetti than Window.show.
Not all program structures have to be piles. PushTo reminds me furiously of Hypercard…
For instance, my app has a toolbar and shows views depending on what is tapped. Where would be the pile logic there ? No linearity, so PushTo is completely unnecessary. App.CurrentScreenContent permits random access, which is IMHO more appropriate to the user’s navigation.
If I wanted to use PushTo instead, that is where I would have spaghetti on my hands, with the need to manage queues of views, and know their place in the queue.
With separate views, I can keep a reference to each, and do exactly as I do with non implicit windows on Desktop.
By directly using app.currentscreen.content you loose some automatisms like swipe back to previous screen, or showing Backbutton in the Titlebar etc.). On the other hand this is more controllable, because you can write a Dispatcher-Method in a global module to navigate around your views without unwanted side effects.
For my opinion this is somewhat of a philosophy discussion. I’m more on Michel’s side because a central dispatcher is more readable.
Indeed it is a question of philosophy.
I like the browser metaphor of pushTo for some apps, but it is completely unusable for random access interface. I should know, I had to do quite a bit of spaghetti in my first app two years ago with a tabbed interface and when we had only pushto.
I think the title of this thread is completely inappropriate. Assigning views to the screen with App.CurrentScreen.Content has absolutely nothing to do with Goto.
i agree ;-))