but I… it… it’s a PDF, its stored on my phone. I downloaded it. I actually still have it, if I need to prove I was on the train. its not in the app anymore, but I still have it here.
you know you can’t make a PURCHASE on an app without network access, right? like, it has to interact with your bank and generate the code (and that’s done on their server, so you can’t make yourself free tickets) and update “this ticket is valid” in the system. the app is literally just a web site with fewer features. all the important math happens on the server. usually, not even a timetable is stored locally, and it still has to be retrieved from the network, it doesn’t even cache, I bet. I could check, but I would have to find my phone.
all the functional parts are server calls, app or website. all of them. buying a ticket involves authenticating with both the owner’s server and my bank. that’s a network thing. can’t download my ticket til I do that, site or app. even looking at a timetable (i dont see where in the app I can do that? but point to point trips) on the app doesn’t work when im in airplane mode, but I know for a fact my browser caches, and if I’ve looked recently or left the page open, it will still be there when I come back.
there’s no advantage of an app, unless you’re doing fancy graphics shit, which eats battery like a mother fucker and makes low end devices much more unhappy.
Sounds like you’re talking about a train app or something. I’m talking about an info/tourism app for a historical cemetery, where there’s lots of potential for multimedia.
But uh, yeah, thanks for the beginners guide to client/server architecture, I guess.
okay I was using a specific example of an unnecessary app I used in the past week. never used the cemetary app, never had to deal with trying to when im outside of network range. still pretty sure it could be a website.
but I… it… it’s a PDF, its stored on my phone. I downloaded it. I actually still have it, if I need to prove I was on the train. its not in the app anymore, but I still have it here.
you know you can’t make a PURCHASE on an app without network access, right? like, it has to interact with your bank and generate the code (and that’s done on their server, so you can’t make yourself free tickets) and update “this ticket is valid” in the system. the app is literally just a web site with fewer features. all the important math happens on the server. usually, not even a timetable is stored locally, and it still has to be retrieved from the network, it doesn’t even cache, I bet. I could check, but I would have to find my phone.
Ew, reading?
(Joking btw)
I think you replied to the wrong person?
all the functional parts are server calls, app or website. all of them. buying a ticket involves authenticating with both the owner’s server and my bank. that’s a network thing. can’t download my ticket til I do that, site or app. even looking at a timetable (i dont see where in the app I can do that? but point to point trips) on the app doesn’t work when im in airplane mode, but I know for a fact my browser caches, and if I’ve looked recently or left the page open, it will still be there when I come back.
there’s no advantage of an app, unless you’re doing fancy graphics shit, which eats battery like a mother fucker and makes low end devices much more unhappy.
Sounds like you’re talking about a train app or something. I’m talking about an info/tourism app for a historical cemetery, where there’s lots of potential for multimedia.
But uh, yeah, thanks for the beginners guide to client/server architecture, I guess.
okay I was using a specific example of an unnecessary app I used in the past week. never used the cemetary app, never had to deal with trying to when im outside of network range. still pretty sure it could be a website.