Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Lensflare I have a meeting with them next week where I'm going to have to explain all the issues that surround it...and just hope that they understand it. But I guess they'll tell me it has to be done anyway and in 4 weeks time the client will ask me why the back button doesn't do what they expected :/
-
@ojt-rant yeah I had a similar experience some years ago. Try to show or explain them why this is a bad idea by providing concrete examples of use cases. And good luck!
-
Curious:
These pages with javascript navigation that don't handle back-button navigation properly: would they even work nicely outside of your app?
If not, then you should argue that it's time to make everything anchor links.
The language choice could be stored in a cookie and handled conditionally when the page is rendered. If the devs of these pages are lazy or the pages are served as static html...maybe it's even possible to handle routing based on language cookie via some new service that responds to the initial requests and routes depending on language cookie. -
@jiraTicket many webview pages in the app call completely different websites, with their own way of doing things. Some are one-page websites using Js to make it appear as if there are other pages (sometimes...but not always...using hashtags to declare a new page)
I've done the best I can do. In one or two pages if the user presses back they wil simply go back to the ptrevious route rather than a previous web page in the webview in the app. And its basically tough shit -
@ojt-rant OK, I understand. So even if every individual SPA site handles back-button navigation on their own site, problems occur when jumping between sites that link to eachother.
-
@jiraTicket yes.
I think I did a pretty good job of handling it given the circumstances. It's now in review.
An app I'm making for a client currently has 23 "pages" that are simply web views.
Most of those pages have A HREFS which open other pages (some external pages that I have no access to as a developer).
Of course, some of the links aren't HREFS and are javascript calls to change the content on the screen without going to another page. So the user thinks they have gone to another web page when then system doesn't recognise it as another page...
Additional to this, there are multiple versions of the pages depending on which language the user has selected in the app.
And nobody seems to have considered how the default back button handles all these possible eventualities (whether it can go back to previous web page, IF it was an HREF and not just JS mimicking a new page (and how would my webview even catch that), and of course IF the language hasn't changed during the user journey etc etc)
Am I wrong for being annoyed about this? Am I the dick for not developing a clean solution to it? Or am I justified because webviews have no place inside an app!
I'm sort of hoping apple deny this app due to too many web views :S
rant