meh... it's all server side stuff. The underlying data is pretty much the same throughout all of those years. They just kept adding on the layers. Should be trivial for an old client to only consume subset of data that is only relevant to them.
Based on my experience (which admittedly is extensive and has been expensive due to BigNetCo changing their APIs) it isn't more common because there are business reasons behind the changes. There was a reason why some API was dropped and that reason doesn't involve your life being pleasant and rewarding..
The thing is that Google maps is so old and the api is so domain specific, it doesn't need to change. The data required is just maps.google.com/v2/<z>/<x>/<y>.png
There are new things like vector tiles with multiple layers of vector data, so we will definitely see more breakage with clients using that.
And the routing is response JSON also had a stable layout. It's not hard to continue to support these api because the type of data they send doesn't change. Google also versions, and accounts and charges for the api usage.
I wish there was more standardization for calendar data but many calendars, including Google, like to mess with the the underlying data and functionality, and there is not ground truth like xyz to really ground them =)
I suspect the YouTube API is similarly simple. Search to get a lost of video IDs. Look up video ID to get thumbnail, title, description, list of video stream URLs.
But they still discontinued the old API and broke all the first-gen smart TVs.
They did. Even the article mentions the Palm Treo, then there were the Nokia Communicators, etc. The iPhone was far from being the first smartphone, but it was the first to break the nerd-wall and sell to the masses.
The first iphone was not even a smartphone, it was a featurephone with a fancy UI.
Only with the 3G could they start claiming it was a smartphone.
Sadly didn't stop boneheads like a NYT writer to try to relabel it as a "superphone" because smartphone was apparently by then too pedestrian for something Apple made...
Of course it had apps, just no 3rd party apps. Email, texting, contacts, calendar, and by far the best web browsing experience made the very first iPhone plenty smart. Jobs pretended you didn't need 3rd party apps, everything could be done on the web; of course Apple always intended to allow 3rd party apps.
The whole point of a smartphone are third party apps.
LG had more than a dozen phones with touch screen (resistive) at that time that had "apps" but no third party apps (except for JavaME apps).
The game changer (as the linked site from Apple states as well) was an App Store allowing direct access to third party apps. And that's what created another modern tech revolution.
> The whole point of a smartphone are third party apps.
No. The point of a smartphone is to expand the scope of what can reasonably be done so they it can be considered more like a computer than a dedicated device with a narrow, defined set of capabilities. Jobs was right that the quality of the iPhone's browser was sufficient to raise it to that level.
Of course having 3rd party apps raises it to another level. It would have been a death sentence if the iPhone proceeded for too long without them while competitors developed a robust app ecosystem but that was never the plan.
> mail, texting, contacts, calendar, and by far the best web browsing experience made the very first iPhone plenty smart
Back then pretty much every high end phone had that... The IPhone wasn't anything special at that time. The IPhone really took off then they allowed 3rd party apps.
Cell phones have only existed since the 80's... "smart phones" have existed since the 90s - back in a day when Palm, Nokia, Windows and Blackberry ruled...
10 years ago? As far as cell phones go? Most definitely the "Dark Ages"... Considering we are moving into a time frame when watches are starting to have cell connectivity:
"more pixels" is quite an understatement. From 320x240 and 640x480 to 1920x1080 and beyond (Sony made a 4K phone!).
But from EDGE to LTE, from weak single core processors to 64-bit 4/6/8 core beasts, from no GPU to what would be considered desktop grade back in the day, from shitty 3gp 144p videos to hardware accelerated 4K H.264/5/VP8/9…
Yeah, people still do messages, but messages now include high quality multimedia edited on device.
Also, web surfing rules. Opera Mini on J2ME and others sucked, it was nothing like the modern mobile web.
And here i still find myself preferring OMini set for single column, as it also strips out all the "modals" and JS bloat found on this "modern" web of yours.
As for editing videos or such on a mobile device, bah humbug. The interface is not there in any more than the most rudimentary way. If anything it has regressed unless one happen to have a Galaxy Note, as fingers simply do not offer the precision.
Lots of high-end feature-phones had all these features in 2007–2008. (GPS was not common before then, but some had it earlier.)
> Facetime in realtime to anyone in the world?
Video calling was a heavily promoted feature of the first 3G phones, a long time ago.
> What about doing all of the above at the same time?
Good feature-phones had multitasking in 2006. I would often listen to music while running multiple third-party apps (!) at the same time.
Of course, these phones cost a tiny fraction of the price of the first iPhone, so hardware limitations like having only a few megabytes of RAM were a bit constraining. The functionality was basically there though.
I owned a Moto Razer (original). I've owned a Treo. I've owned multiple iPhones and multiple Samsung Notes.
Even comparing the original iPhone vs the current batches of iPhone - we are talking GENERATIONS of improvements. Massively better camera's, GPU, CPU, Batter, Screens - both pixel counts and size, network infrastructure, software infrastructure (MySpace vs Facebook).
Orders of magnitude improvements across ALL of those metrics.
Simply talking multi-tasking on the original Android and iPhones vs today? Comparing those vs the Palm and Blackberries they replaced?
I've lived through 20 years of Cell Phone... 10 years ago may not have been the "Dark Ages"... but it was the time immediately afterwords (Palm/BB/WinPhone were definitely the Dark Ages).
We are comparing Horses & Buggies, Model Ts and 2018 Honda Civics... the Model T was better than horses and buggies... but not that much better.
I had a touchscreen phone that could hold hours of video or hundreds of songs, send instant messages, browse the web, get apps, use WiFi... In 2004. In 2005 you could alreday get GPS, more versatile hardware and better accessories.
The much maligned N-Gage had a true multitasking OS with internet and apps in 2003, except Americans never got along with Nokia or Symbian OS.
It may make you laugh, but when I was homeless, someone gave me an outdated iPad thinking that would help me out. It was essentially useless.
A lot of people who have old phones have them because they can't afford anything newer. The pressure to constantly update to newer hardware is a hardship for poor people. It de facto is one of the ways they get excluded from modern life.
I am also real freaking tired of Google apps being a suite on my cheap phone that constantly updates and threatens that you may break other apps if you disable this one. It makes it very challenging to add any apps to my phone. And my wants and needs are not huge. But Google is eating a large share of the storage space and eats into my time for clearing the cache, etc, to keep the phone functional.
My mom gave me an old iPad that’s limited to running iOS 9.something. Even though GarageBand existed back then, it refuses to install from the App Store. It took a decent bit of hacking, including an older version of iTunes and mitmproxy, just to get an older version installed that would still run on it.
There’s an easier way (had the same issue with Spotify and iPhone 4): use the same iCloud account from the “old” device to login on a newer device. There, download the app you want to use on the older device. Once it’s installed, go back to the older device and go to the App Store to “purchased apps”. This will now include the app you just downloaded on the newer device. Click “download”. The App Store will recognize that this app won’t run on your crappy old iOS version, but since you purchased it, it will offer you to download the latest version that still works on your device... insane, I know, but less involved than a mitm-proxy...
That’s the first approach I found to be recommended, but nope, didn’t work in this case for some reason. The app appeared as one I had indeed installed previously (on my newer device) but still refused, saying a newer version of iOS was required. I wonder if it may have been because I had never downloaded the older version of GarageBand, only the latest one.
That's interesting; I still use a Nexus 7 (2012) as my main mobile device. It's occasionally frustratingly slow, but I haven't found almost anything that wouldn't actually run on it. Is the iOS ecosystem worse in that regard, or was the iPad even older?
I agree with the Google Apps thing, though; my employer gave me a new but cheap phone with just 4GB of internal storage, and I'm always having to cleanup so I can install anything new. And an SD card barely helps, lots of stuff simply can't be moved.
I don't remember how old the iPad was and I no longer have it. But it was old enough that support had been discontinued for its os and I was having trouble finding ways around that. Perhaps someone more technical could have found a solution. I did ask around, but to no avail.
Thanks. Experiences like yours are why I'm always wary of the pushes to make access to services exclusively online. They're usually an attempt to cut budgets by throwing the people who need it more under the bus.
A lot of libraries don't have the latest software. Internet access is often limited to 2 or 3 hours per day on public computers. Public computers frequently do not allow for even temporarily saving images or other files to the desktop, which seriously limits what you can do in them.
I love the internet. It makes my life vastly more workable. But it makes me crazy that there is so little effort to keep the bar for entry low in terms of money and technical savvy.
Why does my cheap phone need so many apps that I don't use, that cannot be disabled and that promptly update again after I delete all the data off of them, forcing me to delete the same data repeatedly? Is this really necessary? Come on.
Some tips, just in case they help. When disabling apps, you can generally ignore the warning that other apps may break. Do not disable Google play services, though. Also, go into the account settings and make sure sync is turned off for everything, you can sync manually when needed. Finally, disable auto-update in the play store. Google apps update frequently but will generally continue to work for quite a while if you refuse those updates.
I had no idea I could turn off auto update in the app store. I couldn't find a way to do it on my phone, so I thought it could not be done. That alone should make this more manageable.
I'm not the OP but I'm guessing it makes him laugh because you can still run things on Windows that were written in the early 1990s. I have personally worked on an application in 2016 that was written in 1989 and still ran. It depended on mainframe code that was written in the 1980s and possibly some from the 1970s.
(Yes, it would have to be Windows NT to run I think)
Read Raymond Chen's fantastic blog for how much MS have worked to keep backwards compatibility going.
And then we come to backward compatibility and mainframes:
"The IBM Z family maintains full backward compatibility. In effect, current systems are the direct, lineal descendants of System/360, announced in 1964, and the System/370 from the 1970s. Many applications written for these systems can still run unmodified on the newest IBM Z system over five decades later.[3]"
> It really should not be though. It is saddening how fixated on "new" the vally mentality is.
That's not a fair characterization - it is impressive regardless of the industry. I was impressed just the other day reading about Mercedes classic has stock of spares for old cars (not all parts). I would like to think the number of generations of Mercedes cars is comparable with the number of generations of Maps APIs that have been rolled out. Maintaining support for old products takes effort, and is unlikely to be profitable (directly), one is justified in not doing that without fixation on the "new".
Even the usual car parts stores (Autozone, Advance auto, etc.) stock a lot of parts going back at least 30 years. My car is over 20 years old and I'm surprised how many basic parts I've been able to just walk into a store and buy (radiator, alternator, starter, etc). The amount of warehouse space in those stores does not seem that big but they manage to keep a very useful selection of parts spanning several decades. Much more convenient than going to a dealership and paying 3x the price and waiting a week because they don't actually stock the parts anyway.
"The phone runs Palm OS 5. It doesn’t understand Unicode. Of course, it has no idea what an “emoji” is. When you send it a text message that has one character outside of the printable ASCII range, it freaks out and corrupts the whole message. It doesn’t have Wifi of any kind. It doesn’t even connect to the Sprint’s 2G EV-DO/1xRTT network (because the data provision server is long dead). In short, it has no easy way to connect to the Internet at all. In order to get the thing to connect to the Internet, I had to fucking emulate a Dial-up Modem over Bluetooth using a Raspberry Pi."
Google's support is probably just a bunch of old APIs and test suites -- comparatively easier to keep working.
I wonder how much of this backward compatibility is because of the Google Maps API? I'm not sure if these products use the API themselves, but even if they don't the discipline required to have and support an external API means you don't just break old URLs without consideration. There have been deprecations in the Maps API but not many, and each with long lead times.
The JS api is more of an SDK so it doesn't expose urls or anything and doesn't have all the features of the site. There are url endpoints but they are pretty limited and I'd highly doubt it's dog fooded.
I had this same experience the other day with Google Maps for PocketPC. Still works. Smart API cross-compatibility is something we should strive for, within reason.
For years I refrained from doing a post like this because I feared (and still fear) that somebody at Google will notice what is going on and shut the old APIs down.
"What? server XYZ still works!? Mel was supposed to turn it off in 2010!"
The J2ME midlet has been very useful in the past years and I really don't want to lose it. (Ah, the pain and sorrow of relying on somebody else's service.)
Of course! With some defensive programming, e.g, the client ignoring unrecognized elements in the XML response while still reading the ones it does recognize, and not changing the API endpoint URLs, so long as the API output contains the values the client is looking for, there shouldn't be any reason why this stuff would break.
If the client used tilemaps versus vector data, I would expect the tilemap data to be out of date, but the directions would still be valid.
But this is Google. They deprecate things with last week's milk. I feel like they have a pretty good idea of what's still running, and shut it down if it doesn't make them at least half a billion a year. I still miss many products, and I wasn't even a Reader user (so no, it's still other stuff I'm disgruntled about).
These days you can't even do a Youtube search without an account, and an account needs a phone number of course, so you have to resort to HTML scraping to do simple stuff like just using the top hit (so you can fire off a tab with some song in the background, without waiting for it to load and click a result with the mouse). There used to be an API for simple things like that.
Right, but if it requires maintenance, and it doesn't bring in enough money to cover the costs of that, turning it off might be more cost-effective than doing the maintenance.
Look at Google Finance, for example - uses Adobe Flash, which is 2 years away from EOL. Presumably it's not making any money and doesn't have a maintenance budget; if it did, they'd have moved away from Flash when the iPhone came out. But when Flash hits EOL, maintenance is mandatory.
Well, they're probably reading proto buffers instead of xml[1]. And proto deserialization automatically drops unrecognized fields. So yeah, as long as you continue shipping your core data in already-established fields, and don't radically change the interpretation of those fields, backwards compatibility is going to be built in.
[1] - So goes the standard joke: Some people think Google is an advertising company. Techies recognize Google as an advertising company. But in reality Google is a company which turns protobuffers into more differenter protobuffers.
No. New clients use vector data, but even the web version will go back to bitmap tiles if your browser does not support WebGL, the GPU is slow or busy, etc.
There was a whole MapReduce (which Jeff Dean used for years in public talks to explain the concept), part of a larger pipeline, that converted the road and POI network into bitmap tiles. It didn't run by accident or maintain itself, so this is probably not a coincidence. :-)
Actually, with the push toward edits going live quickly and the styling/multilingual support in the Maps API, it's likely that a good chunk of tile traffic is rendered on the fly now, but the HTTP requests to the servers would look the same and there would still be enough demand for the stock tiles.
Even on modern versions of Maps, South Korea uses bitmap tiles. On a phone, scroll so Pyongyang and Seoul are in the same viewport and observe what happens to them if you try to rotate the map.
For anyone unwilling to open maps and check: the South Korean tiles are bitmaps (you see this because the city labels rotate along with the map in SK but not in NK).
That's interesting though,why does South Korea use bitmaps?
South Korea has this brain-dead law that prohibits any map data on South Korea from being exported: the data must physically remain in a server located in South Korea.
Obviously, this is a huge problem for Google, who wants to keep the world's map data in multiple data centers across the world. So... imagine what kind of horrible kludges some unfortunate developers had to write just to comply with that law.
I think the law distinguishes between an end-user accessing map data and transferring the whole data overseas. But as you pointed out, that's not really a meaningful distinction. Anybody who's interested in a particular place in Korea (be it CIA or North Korea) can simply visit map.naver.com or buy commercially available satellite photos.
I don't know about whether it is deliberate, but I know it's much more complicated than just retaining old APIs. It's incredibly easy to break legacy compatibility. You only need to provide a server that serves images. What can possibly go wrong?
I notice that many text-only websites don't even work with old phones/computers now. It's because some older browsers don't do HTTP/1.1. More importantly, they don't do modern encryption standards, and web servers don't like that at all. Or maybe you have expired (root) certificates on the client, and the OS/your app doesn't provide a way to override/upgrade the certificates. I have seen more legacy apps break because of encryption than any other cause. You patch/upgrade the server software or you renew your certificate, and suddenly the legacy support is gone.
It's very tricky. I don't know, but I bet part of what made Gmaps clients so compatible is because the legacy clients didn't do HTTPS, and Google's servers don't require HTTPS.
Those old clients can have security advantages. For example, my MPC7400 processor is immune to meltdown and spectre. It also isn't supported by a typical javascript JIT, so that wipes out lots of other potential exploits. I'm pretty sure the RAM is old enough to be immune to rowhammer; it is PC133 in slots specified for PC100.
The web browser is of course obsolete. Newer ones run slower, take more RAM than the 512 MiB that the system has, expect a GPU, and have lots of dependencies.
I know this feeling all to well. My friends and I created a facebook group in 2005 that doesn't have a name- we managed to sneak some null characters through their filters. Our nameless group occasionally causes problems, including crashing the IOS Facebook app for about a year, but we didn't want to make a bug report because we thought they'd just give the group a name (ultimately one of our friends at Facebook filed a bug report and got it fixed without outing us).
One of the first things I'll do if I notice any unsanitized input causing problems is to find as many examples as I can of the broken/malicious data and use them as test cases while fixing the bug. Obviously I don't stop at what's already in the system, but it's a good starting point.
In other words, I wouldn't be surprised if Facebook knows now.
I recall there being a Twitter account with a username zero characters long. I've only seen retweets of it, because of course, https://twitter.com// is treated the same as https://twitter.com/.
Not 0 characters long, just full of unicode whitespace that got stripped out of most rendering layers. It was right up there with people like this: https://twitter.com/_
My guess is they likely know and that it's tied to business applications that still rely on older software/hardware. Vendor agreements, etc. - just a theory.
I forgot how much the APIs changed, but yeah, Google Maps used to be 2d image tiles, huh? It's vector-based now, which I think saves bandwidth. How else has it changed?
Oh man, I had the Sprint Treo and Centro and the Palm Pre. I even remember using maps on a trip I took for work to New York City, even before Apple's phone was released.
Palm OS crashed a lot too. No memory protection either. Their IDE was based on Eclipse though. That was a different era for sure.
As a personal experiment (starting a bit over a week ago), I switched all of my browsers' default search engines to DDG and it's so far been surprisingly pleasant. To me, it actually feels faster than searching with Google. Results seem easier to read through too.
Be sure to read about the !bangs feature and take full advantage of it - it's probably the feature that won me over most easily but the rest of it is good too: https://duckduckgo.com/bang
I wouldn't really call it great... it didn't do turn-by-turn directions or provide any way of reconciling what turn is next based on your location. It was for "planning purposes only" and you'd have to hit this arrow button repeatedly to show you each turn in a route.
> How about iOS? Google Maps for iOS 1.0, released late 2012, still works just fine. [And] That was [just] the first version of Google Maps ever released as a standalone app after Apple ditched Google’s map solution on iOS
It wasn't a built in Google Maps app. It was written by Apple backed by Google's API. Just like today Apple Maps driving directions are still backed by third parties.
"In short, it has no easy way to connect to the Internet at all. In order to get the thing to connect to the Internet, I had to fucking emulate a Dial-up Modem over Bluetooth using a Raspberry Pi."
I was more impressed by the author getting this to work than the entire article about Google maps backwards compatibility.
It is not that hard to setup using bluez if you know that you want the modem emulation mode (ie. DUN) and not the native ethernet over bluetooth mode (PAN or BNEP). Probably biggest issue is getting the pairing to work without some kind of desktop environment (modern bluez expect dbus service that handles the UI).
In 00's this was the way to connect palm devices to internet wirelessly, there even were ready made "bluetooth accesspoints" that did exactly that.
I wish I knew that piece of information before wasting hours just to figure out I had to use the DUN profile instead of PAN/BNEP.
After another half a day I decided that there was no chance I could understand bluez system in the Raspberry Pi to make it provide DUN via the USB Bluetooth dongle. So I thought to configure my HC0x Bluetooth dongle to provide DUN via serial tty. So I went the alternative route of hacking the HC06 Bluetooth module to HC05 (or the other way around) because I only had the wrong kind laying around. I needed to wire 30 wires from the desktop parallel port to the dongle to reprogram it. And had to install Windows XP 32 bit on the desktop because the firmware programmer only likes that. It took days to get the Palm to connect to the Internet.
It was a crazy journey & deserves a long blog post by itself :)
I just wrote post to facebook about the only time I had seen BNEP working at all (and in the most complex configuration possibly and on top of that reliably), also something worth of series of blog posts (I'm somewhat fuzzy on why exactly we built that, I remember clearly that there was some bussiness reason for spending whole day on that, which either means that there was some real problem that got solved by that or it was just part of qualification test for Thinkpad T60).
In my experience whether the dongle is connected through USB or as native UART is mostly immaterial from the bluez PoV. Another thing is that when we started playing with this disconnecting USB BT dongle reliably caused deadlock in kernel (on linux 2.4.25 or something like that, about half a year before first realy usable 2.5.x kernels)
Today, APIs don't keep working for a month because someone thought replacing careful design with a bad emulation of SQL is the new hotness. They call it GraphQL.
Can you name an API that was deprecated in favor of GraphQL? (Considering that article is about maintaining backward compatibility while continuing to innovate)
All the docs for graphql (and Apollo) recommend always making backwards compatible changes.
If anything, graphql apis would be easier to maintain in the long run, since clients asks for what they want. New clients could ask for the new data, without breaking the responses for old clients.
This is really neat, but at the same time, Google Maps/Navigation and Google Search are easily two of the slowest apps on my 2013 Moto X.
I guess what it comes down to is: they have a confined, well defined feature set (maps + navigation), which only requires a simple API to maintain. The functioning of the different versions that talk to that API is independent of that API.
If you program a modern custom web app (let's say with vue) with Google Maps you will also start to curse at it because it's complicated and frustrating to deal with.
Nothing against legacy support (it should stay!) but sometimes you want to work with things easily with modern techniques.
This post is very interesting in a number of things besides the Google Maps.
I still have an old iPod touch, the iPad 1, and dayly use my iPad 3 (iPad with Retina). I also own the new iPhone X. But especialy on the iPad I have no use case on updating it besides it is running this old iOS, for which no update is available anymore. Because there is no update all the apps for it are also not anymore updated, because Apple requires in Xcode a minimum iOS version for compiling. So I am more and more cut off from many services just because a newer iPad does not provide more except to stay up to date with the services I use.
Comming from an industrial background where systems are running for 20 years, 30 years, and more that is really frustrating, when even 5 year old technology doesn't run for other use cases.
The first gen iPad still works with Netflix, Hulu, Plex, Spotify, Crackle, Google Drive, and all of Apple's iWork apps. Of course these are all older versions. It supports AirPrint and AirPlay.
Yes. I reset my first gen iPad last year and redownloaded all of those apps. If the newest version is not compatible with your iOS version, It gives you the option of downloading the last compatible version.
On another note, when Apple first implemented two factor authentication, they didn't make it well known, but you could enter your password+authentication code for older iOS versions. Later, they actually added that to the password prompt.
The only caveat is that you can only download previous versions if you have downloaded any version of the same app previously. If you haven't, you have to download the newest version from another device first or you have to download it via iTunes and then you can download it from the App Store on the older device.
> The phone runs Palm OS 5. It doesn’t understand Unicode. Of course, it has no idea what an “emoji” is. When you send it a text message that has one character outside of the printable ASCII range, it freaks out and corrupts the whole message.
When you have one character outside of the ascii [1] range, the whole message needs to be encoded in UCS-2 [2], so it's not surprising that the whole message is illegible, since the phone doesn't understand unicode.
[1] it's more likely to be the gsm-7 range, although ascii sms is possible
[2] or UTF-16, which is outside the SMS spec, but works enough, and enables emoji, so....
Sadly, I wish all that backwards compatibility extended to keeping access to the old web client. The last few years have seen a steady decline in web client for my purposes. For example, the max of 10 via points on a route, or lately seasonal closures make certain routes impossible, even when I set the route date to a date when the road isn’t closed. I also wish panoramio was still around and the photos were visible on the map. The current design for showing photos on the map is much less useful.
I wish this were really as true as the author suggests. Unfortunately about two years ago Google turned off the backends that deliver public transport directions for older versions of Maps (in particular, the version that runs on Gingerbread), forcing me to switch to the (much less stable, much slower) CityMapper to find my way around town.
I mean as long as the apps are still available on the respective app store why would they stop working?
I imagine with every new major version they switched to a different Web API Endpoint and left the old ones intact. So app-wise nothing really had to be changed or maintained over the years.
Backwards compatability is something, that should be a diffrent kind of partially open source project. Meaning- the software provider promises to include a dll that connects to current API and releases the source code. If there is interest to maintain the backwards compatability- work will appear.
131 comments
[ 2.7 ms ] story [ 171 ms ] threadYou say "should be trivial", but in practice that doesn't seem to be the case for most applications.
For example, Google Calendar changed their API some years back which caused the calendar display on Samsung refrigerators to fail.
Why did that seemingly trivial task of calendar synchronization fail?
It's not more common because we as an industry have a terrible habit of designing systems to be non self-maintaining.
There are new things like vector tiles with multiple layers of vector data, so we will definitely see more breakage with clients using that.
And the routing is response JSON also had a stable layout. It's not hard to continue to support these api because the type of data they send doesn't change. Google also versions, and accounts and charges for the api usage.
I wish there was more standardization for calendar data but many calendars, including Google, like to mess with the the underlying data and functionality, and there is not ground truth like xyz to really ground them =)
But they still discontinued the old API and broke all the first-gen smart TVs.
Guess it was because it couldn't support Ads?
Only with the 3G could they start claiming it was a smartphone.
Sadly didn't stop boneheads like a NYT writer to try to relabel it as a "superphone" because smartphone was apparently by then too pedestrian for something Apple made...
The very defining feature of a smart phone are the apps, though.
EDIT: Due to downvotes, here’s Apple’s own page advertising how iOS 2 (introduced with the iPhone 3G) adds apps to the iPhone: https://web.archive.org/web/20080912112138/http://www.apple....
LG had more than a dozen phones with touch screen (resistive) at that time that had "apps" but no third party apps (except for JavaME apps).
The game changer (as the linked site from Apple states as well) was an App Store allowing direct access to third party apps. And that's what created another modern tech revolution.
No. The point of a smartphone is to expand the scope of what can reasonably be done so they it can be considered more like a computer than a dedicated device with a narrow, defined set of capabilities. Jobs was right that the quality of the iPhone's browser was sufficient to raise it to that level.
Of course having 3rd party apps raises it to another level. It would have been a death sentence if the iPhone proceeded for too long without them while competitors developed a robust app ecosystem but that was never the plan.
Back then pretty much every high end phone had that... The IPhone wasn't anything special at that time. The IPhone really took off then they allowed 3rd party apps.
http://www.nicolasnova.net/pasta-and-vinegar/2015/6/28/some-...
10 years ago? As far as cell phones go? Most definitely the "Dark Ages"... Considering we are moving into a time frame when watches are starting to have cell connectivity:
https://www.lifewire.com/smartwatches-with-cellular-connecti...
Where are we going to be 5 years from now? 10? 20? Compare the Treo and BlackBerry to the current iPhone X, Note 8, etc...
And i see screens with more colors and pixels, but other than that not much new. It is still calendars and messages that rules.
But from EDGE to LTE, from weak single core processors to 64-bit 4/6/8 core beasts, from no GPU to what would be considered desktop grade back in the day, from shitty 3gp 144p videos to hardware accelerated 4K H.264/5/VP8/9…
Yeah, people still do messages, but messages now include high quality multimedia edited on device.
Also, web surfing rules. Opera Mini on J2ME and others sucked, it was nothing like the modern mobile web.
As for editing videos or such on a mobile device, bah humbug. The interface is not there in any more than the most rudimentary way. If anything it has regressed unless one happen to have a Galaxy Note, as fingers simply do not offer the precision.
What about doing all of the above at the same time?
"I only see" is because you are limiting what you see in a way that goes against what the vast majority of people see.
That's like saying the new MacBook is no different than a 286 because you had Excel Worksheets on both.
Or saying there is no difference between a Model-T and a 2018 Honda Civic - they both use gas, have 4 wheels and a windshield.
Lots of high-end feature-phones had all these features in 2007–2008. (GPS was not common before then, but some had it earlier.)
> Facetime in realtime to anyone in the world?
Video calling was a heavily promoted feature of the first 3G phones, a long time ago.
> What about doing all of the above at the same time?
Good feature-phones had multitasking in 2006. I would often listen to music while running multiple third-party apps (!) at the same time.
Of course, these phones cost a tiny fraction of the price of the first iPhone, so hardware limitations like having only a few megabytes of RAM were a bit constraining. The functionality was basically there though.
Even comparing the original iPhone vs the current batches of iPhone - we are talking GENERATIONS of improvements. Massively better camera's, GPU, CPU, Batter, Screens - both pixel counts and size, network infrastructure, software infrastructure (MySpace vs Facebook).
Orders of magnitude improvements across ALL of those metrics.
Simply talking multi-tasking on the original Android and iPhones vs today? Comparing those vs the Palm and Blackberries they replaced?
I've lived through 20 years of Cell Phone... 10 years ago may not have been the "Dark Ages"... but it was the time immediately afterwords (Palm/BB/WinPhone were definitely the Dark Ages).
We are comparing Horses & Buggies, Model Ts and 2018 Honda Civics... the Model T was better than horses and buggies... but not that much better.
The much maligned N-Gage had a true multitasking OS with internet and apps in 2003, except Americans never got along with Nokia or Symbian OS.
https://youtu.be/s3xsSwjQ1oA
A lot of people who have old phones have them because they can't afford anything newer. The pressure to constantly update to newer hardware is a hardship for poor people. It de facto is one of the ways they get excluded from modern life.
I am also real freaking tired of Google apps being a suite on my cheap phone that constantly updates and threatens that you may break other apps if you disable this one. It makes it very challenging to add any apps to my phone. And my wants and needs are not huge. But Google is eating a large share of the storage space and eats into my time for clearing the cache, etc, to keep the phone functional.
I agree with the Google Apps thing, though; my employer gave me a new but cheap phone with just 4GB of internal storage, and I'm always having to cleanup so I can install anything new. And an SD card barely helps, lots of stuff simply can't be moved.
I love the internet. It makes my life vastly more workable. But it makes me crazy that there is so little effort to keep the bar for entry low in terms of money and technical savvy.
Why does my cheap phone need so many apps that I don't use, that cannot be disabled and that promptly update again after I delete all the data off of them, forcing me to delete the same data repeatedly? Is this really necessary? Come on.
Thank you.
(Yes, it would have to be Windows NT to run I think)
Read Raymond Chen's fantastic blog for how much MS have worked to keep backwards compatibility going.
And then we come to backward compatibility and mainframes:
"The IBM Z family maintains full backward compatibility. In effect, current systems are the direct, lineal descendants of System/360, announced in 1964, and the System/370 from the 1970s. Many applications written for these systems can still run unmodified on the newest IBM Z system over five decades later.[3]"
https://en.wikipedia.org/wiki/IBM_Z
It would be interesting to see someone try to see what the oldest unmodified app they could run on a Z series was.
That's not a fair characterization - it is impressive regardless of the industry. I was impressed just the other day reading about Mercedes classic has stock of spares for old cars (not all parts). I would like to think the number of generations of Mercedes cars is comparable with the number of generations of Maps APIs that have been rolled out. Maintaining support for old products takes effort, and is unlikely to be profitable (directly), one is justified in not doing that without fixation on the "new".
"The phone runs Palm OS 5. It doesn’t understand Unicode. Of course, it has no idea what an “emoji” is. When you send it a text message that has one character outside of the printable ASCII range, it freaks out and corrupts the whole message. It doesn’t have Wifi of any kind. It doesn’t even connect to the Sprint’s 2G EV-DO/1xRTT network (because the data provision server is long dead). In short, it has no easy way to connect to the Internet at all. In order to get the thing to connect to the Internet, I had to fucking emulate a Dial-up Modem over Bluetooth using a Raspberry Pi."
Google's support is probably just a bunch of old APIs and test suites -- comparatively easier to keep working.
"What? server XYZ still works!? Mel was supposed to turn it off in 2010!"
The J2ME midlet has been very useful in the past years and I really don't want to lose it. (Ah, the pain and sorrow of relying on somebody else's service.)
If the client used tilemaps versus vector data, I would expect the tilemap data to be out of date, but the directions would still be valid.
But this is Google. They deprecate things with last week's milk. I feel like they have a pretty good idea of what's still running, and shut it down if it doesn't make them at least half a billion a year. I still miss many products, and I wasn't even a Reader user (so no, it's still other stuff I'm disgruntled about).
These days you can't even do a Youtube search without an account, and an account needs a phone number of course, so you have to resort to HTML scraping to do simple stuff like just using the top hit (so you can fire off a tab with some song in the background, without waiting for it to load and click a result with the mouse). There used to be an API for simple things like that.
Look at Google Finance, for example - uses Adobe Flash, which is 2 years away from EOL. Presumably it's not making any money and doesn't have a maintenance budget; if it did, they'd have moved away from Flash when the iPhone came out. But when Flash hits EOL, maintenance is mandatory.
Turning it off is what I'd do in that situation.
Hyperbole or...?
https://youtube.com/results?q=never%20gonna%20give%20you%20u...
seems to work fine without an account.
> so you have to resort to HTML scraping to do simple stuff like just using the top hit [...] There used to be an API for simple things like that.
[1] - So goes the standard joke: Some people think Google is an advertising company. Techies recognize Google as an advertising company. But in reality Google is a company which turns protobuffers into more differenter protobuffers.
https://github.com/google/protobuf/issues/272#issuecomment-2...
There was a whole MapReduce (which Jeff Dean used for years in public talks to explain the concept), part of a larger pipeline, that converted the road and POI network into bitmap tiles. It didn't run by accident or maintain itself, so this is probably not a coincidence. :-)
Actually, with the push toward edits going live quickly and the styling/multilingual support in the Maps API, it's likely that a good chunk of tile traffic is rendered on the fly now, but the HTTP requests to the servers would look the same and there would still be enough demand for the stock tiles.
That's interesting though,why does South Korea use bitmaps?
Obviously, this is a huge problem for Google, who wants to keep the world's map data in multiple data centers across the world. So... imagine what kind of horrible kludges some unfortunate developers had to write just to comply with that law.
I notice that many text-only websites don't even work with old phones/computers now. It's because some older browsers don't do HTTP/1.1. More importantly, they don't do modern encryption standards, and web servers don't like that at all. Or maybe you have expired (root) certificates on the client, and the OS/your app doesn't provide a way to override/upgrade the certificates. I have seen more legacy apps break because of encryption than any other cause. You patch/upgrade the server software or you renew your certificate, and suddenly the legacy support is gone.
It's very tricky. I don't know, but I bet part of what made Gmaps clients so compatible is because the legacy clients didn't do HTTPS, and Google's servers don't require HTTPS.
Yes, and come July 1st, many websites will only allow TLS 1.1 and TLS 1.2 to be PCI compliant, which will knock out a bunch of old clients.
> I bet part of what made Gmaps clients so compatible is because the legacy clients didn't do HTTPS, and Google's servers don't require HTTPS.
That's my hunch too.
The web browser is of course obsolete. Newer ones run slower, take more RAM than the 512 MiB that the system has, expect a GPU, and have lots of dependencies.
In other words, I wouldn't be surprised if Facebook knows now.
It's super impressive.
http://www.financial-hacker.com/bye-yahoo-and-thank-you-for-...
Palm OS crashed a lot too. No memory protection either. Their IDE was based on Eclipse though. That was a different era for sure.
As a personal experiment (starting a bit over a week ago), I switched all of my browsers' default search engines to DDG and it's so far been surprisingly pleasant. To me, it actually feels faster than searching with Google. Results seem easier to read through too.
Be sure to read about the !bangs feature and take full advantage of it - it's probably the feature that won me over most easily but the rest of it is good too: https://duckduckgo.com/bang
> How about iOS? Google Maps for iOS 1.0, released late 2012, still works just fine. [And] That was [just] the first version of Google Maps ever released as a standalone app after Apple ditched Google’s map solution on iOS
I was more impressed by the author getting this to work than the entire article about Google maps backwards compatibility.
That dedication ._.
In 00's this was the way to connect palm devices to internet wirelessly, there even were ready made "bluetooth accesspoints" that did exactly that.
After another half a day I decided that there was no chance I could understand bluez system in the Raspberry Pi to make it provide DUN via the USB Bluetooth dongle. So I thought to configure my HC0x Bluetooth dongle to provide DUN via serial tty. So I went the alternative route of hacking the HC06 Bluetooth module to HC05 (or the other way around) because I only had the wrong kind laying around. I needed to wire 30 wires from the desktop parallel port to the dongle to reprogram it. And had to install Windows XP 32 bit on the desktop because the firmware programmer only likes that. It took days to get the Palm to connect to the Internet.
It was a crazy journey & deserves a long blog post by itself :)
In my experience whether the dongle is connected through USB or as native UART is mostly immaterial from the bluez PoV. Another thing is that when we started playing with this disconnecting USB BT dongle reliably caused deadlock in kernel (on linux 2.4.25 or something like that, about half a year before first realy usable 2.5.x kernels)
If anything, graphql apis would be easier to maintain in the long run, since clients asks for what they want. New clients could ask for the new data, without breaking the responses for old clients.
I guess what it comes down to is: they have a confined, well defined feature set (maps + navigation), which only requires a simple API to maintain. The functioning of the different versions that talk to that API is independent of that API.
I still have an old iPod touch, the iPad 1, and dayly use my iPad 3 (iPad with Retina). I also own the new iPhone X. But especialy on the iPad I have no use case on updating it besides it is running this old iOS, for which no update is available anymore. Because there is no update all the apps for it are also not anymore updated, because Apple requires in Xcode a minimum iOS version for compiling. So I am more and more cut off from many services just because a newer iPad does not provide more except to stay up to date with the services I use.
Comming from an industrial background where systems are running for 20 years, 30 years, and more that is really frustrating, when even 5 year old technology doesn't run for other use cases.
On another note, when Apple first implemented two factor authentication, they didn't make it well known, but you could enter your password+authentication code for older iOS versions. Later, they actually added that to the password prompt.
The only caveat is that you can only download previous versions if you have downloaded any version of the same app previously. If you haven't, you have to download the newest version from another device first or you have to download it via iTunes and then you can download it from the App Store on the older device.
When you have one character outside of the ascii [1] range, the whole message needs to be encoded in UCS-2 [2], so it's not surprising that the whole message is illegible, since the phone doesn't understand unicode.
[1] it's more likely to be the gsm-7 range, although ascii sms is possible
[2] or UTF-16, which is outside the SMS spec, but works enough, and enables emoji, so....
I imagine with every new major version they switched to a different Web API Endpoint and left the old ones intact. So app-wise nothing really had to be changed or maintained over the years.