I used work for Symbian. The OS itself was great at the time (it's open sourced somewhere), and got security correct (I don't recall 'privacy' ever being an explicit goal) but it was an absolute bitch to develop for. It had its own dialect of C++ which looks nothing like modern C++, the learning curve was huge. It tried really hard to have an app ecosystem but it was nothing like what google and apple have today. Network operators desperately wanted an alternative ecosystem to avoid being dependent on Android and Apple (but mainly I believe so that they could build their own walled gardens).
But by the time Nokia took over Symbian it became apparent that they saw Linux as the future OS for high-end devices and Symbian was to be relegated to mid-level devices.
I am Brazillian, and I think killing Symbian was a huge and stupid mistake.
When Microsoft release that memo that killed Symbian, in Brazil its marketshare was INCREASING, there was a lot of people learning how to code for it, many people saw it as a good future, because with it you could make blazing fast CHEAP phones, iPhones were crazy expensive, and android was a slow buggy mess.
Thing is... iPhones are STILL crazy expensive, and android STILL is a slow buggy mess if you buy a cheap one.
I am yet to find a smartphone I like as much I liked symbian based phones, that are phones first, smart second, and work great for actually phoning people.
GPS is a completely passive signal, so it's not really surprising that it lasts a long time. You can get similar battery life with IoT SoCs deployed on the field.
The difference between then and now is that modern smartphones use sensor fusion, combining cellular, WiFi, and GPS signals to generate a location. The end result is more accurate output, at the expense of battery life.
> The end result is more accurate output, at the expense of battery life.
Do you have sources? GPS is passive, yes, but the signal is very weak and several orders of magnitude below the noise threshold. Keeping receiver circuits enabled for a long time costs battery power as well. WiFi information can be obtained entirely passively as well, as AP's transmit their info regularly.
I think the difference rather comes from lots of bloaty background services on Android.
My understanding is that cheaper devices (at least historically) tended not to have a discrete chip for handling GPS, which could run extremely efficiently and at very low power, and instead were forced to use the CPU to do the work - contributing to the reputation of being slow and power inefficient.
Modern devices do the sensor fusion on CPU but it's just polling the GPS chip for coordinates as required, which handles all the actual signals processing stuff.
Are there any phones that allow you to customize this? I recall Android having a Developer Options setting for GPS + WiFi or just GPS for Location Accuracy. But IIRC, this didn't make a substantial impact to battery life. Maybe because I'm not a passive phone user.
That device was not continuously receiving a GPS signal. It was relying on network location services, and maybe occasionally waking up the GPS receiver.
Symbian was a dead OS walking when they killed it. They might have been able to keep it struggling along for a few more years but due to fundamental architectural limitations it would have fallen further and further behind iOS and Android.
I worked at Nokia starting in about 2004. Looking back on my career, one of the single greatest feelings of accomplishment was getting a Hello World application to run on Symbian/S60. I thought I knew C++ going in, but I wasn't prepared for two phase constructors and the 6 files you'd need to draw a simple list view on the screen. Felt amazing once it worked though!
Lol. At least you guys had actual phones to work with. Until we became Nokia all we had was a techview UI shell running on H2, or later, H4 boards that would boot an MMC card. Of course, when we became Nokia we got the flashing stations and access to Phoenix. Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.
> Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.
Oh, I remember it was near impossible to get access to service manuals Level 1 & 2 (just for understand how to repair/replace few parts on my N82), and fully impossible get its Level 3 & 4.[0]
AIKON service centers had monopoly on repairing devices.
First job out of uni was writing device drivers for Motorola Symbian devices on H4 boards (I want to say LDDs and PDDs?). Codewarrior or carbide if you fancied a reboot every 2 mins, 40 minute turn-around times to flash and boot your software, boards without working SD and having to log to the screen ...I do not miss those days at all. BlackBerry was like a bloody dream.
I also went through a dev board phase later on when I was working on Maemo, etc. but they took it easy on me when I was fresh out of school and let me have real production hardware
I totally know what you mean - the sense of satisfaction and joy when you get even the most basic "end-to-end" functionality working in a new environment is hard to match.
I loved symbian and the whole "java on phone" never seemed right to me. I would prefer having a linux phone - I dont ask for much - working camera, working calls, mms and sms, gps, bluetooth). I dont care for anything else.
All my hopes are now leaning into Cosmo Communicator( https://www.indiegogo.com/projects/cosmo-communicator - please take care, I have jumped into this with "I will loose my money" mentality - I still dont trust, they will realize the linux part, but hope dies last), it reminds me of beloved Nokia Communicator and if they realize my conditions (camera, calls, mms, sms - gps already works same as bluetooth ) I will give my foot a very long swing and remove my Android phone (even if heavly modified) from my life.
As an owner of a Gemini, the hardware is innovative and good enough, but the OS is really an afterthought. You can browse their current wiki and see how organised it is.
No disrespect to the team, it just seems like taking sufficient care of this is a bigger job than they have the resources for.
But I'm glad I backed the kickstarter, and would do the same for something similar in order to diversify a very un-diverse market.
> the whole "java on phone" never seemed right to me
I'm not sure which Java on phone you are referring to, the Android Java or the older J2ME. The older J2ME apps ran well in limited resources, but was also incredibly complicated to develop due to device fragmentation.
I have one of planet's previous devices, the gemini. It's not very good. The software is some unpatched old android. And the available linux doesn't support very much.
I'll have to try the pinephone next, but I have much higher hopes for it.
I already have it, but it is usefull for me only as linux device (well until they release v22 firmware to mod it). But my main motive for buying it was linux/sailfish.
Symbian was great, and I loved my indestructible all-silver Nokia E61 non-US version (which included WiFi, unlike the carrier-crippled ones I found in the US).
I actually looked recently at trying to buy another E61 in good condition, and how much trouble it would be to kludge up access to my email through it. I figured it would be more productive for email than my current mainstream smartphone setup.
I have to resist the urge to look into this open-sourced Symbian... :)
My beloved E6 had its flaws. It was a pain to sync, the syncs were not serviceable, but at least it was syncing to my computer, not to the cloud. On this one, Symbian Anna felt better than Symbian Belle and it would have been a pain to revert.
That said, it was small, smaller than an iPhone SE. And it had a hardware keyboard. I'm not against fancy apps and stuff on my phone but, besides calling reliability, the first thing I want is to be able to type small things.
I must confess I was unhappy that it even had a touchscreen: a nightmare when it was raining. I guess I just loved the form factor and its promises.
I'm thinking of making this an ode. The E6 ballad. Sorry for that long little-informative comment...
But when J2ME support was added, it became easy to develop apps. I used to develop J2ME apps as hobby, I made a game and took it for my first job interview. In that job I had to port a 30,000+ J2ME code app to Android in 2010. The company I worked for was even experimenting with NFC payments in Nokia Symbian phones in 2010!
> But when J2ME support was added, it became easy to develop apps.
And adding Python support for S60 (PyS60) was the best gift by Nokia for users as it brings Symbian devices to be "on-the-go handheld devs tool for developing apps without desktop PC".[0]
Has you ever know that there is fully functional Blender-like 3D mesh editor & animator app written in Python for S60 (PyS60) directly on Symbian smartphone?[1]
Oh my, this thread is bringing back sweet nostalgia!
>And adding Python support for S60 (PyS60) was best gift by Nokia
Yeah installing python interpreter in S60 on my Nokia N70 ME, motivated me to checkout Python programming book from my college library. As I was reading it in the class during break, the top-ranking girl student came across and asked me "Why Python, isn't it a dead language?"(circa 2006-2007) I assumed she must be right, I didn't write python until several years later; I bet she's using Python in her job now.
So if all these things were possible on Symbian so early what in the world happened that they lost the market race so badly. Too much engineering-driven design? Lack of a unifying Jobs-esque force at the top to make hard decisions?
• iPhone's capacitive touch screen vs Nokia's resistive touch with stylus requirement was too much of a friction (pun not intended). 1 year after iPhone's release, Nokia released 5800 marketed as iPhone killer; guess what? it had f'in stylus with resistive screen.
• Then when android happened, which was poor man's iPhone; Nokia hugged Windows Phone OS. Which never became a thing as it lacked Google apps (Google killed it, MSFT would have done the same to Google if places were interchanged). Other comments have detailed possible leadership sabotage related to the MSFT deal, which I agree with.
That's true of several mobile hardware/SW of that time, I mentioned capacitive screen to show typical consumer preference.
Btw, you can also add native 3G video calling via front camera to that list, my Nokia N70 did that years earlier in India. Not many westerners seem to know about this feature in my earlier discussions.
The market have shifted. Before iphone, everyone was trying to build the smalles phone possible. Jobs convinced the world for brick sized devices and SymbianOS lost its USP - doing a lot on small batteriess. Had there been a wearables market back then, it could have had a second lease of life.
Which is why Elop got the bonus from Nokia shareholders as per the signed contract. Finn press found out all the dirt about the contract back then, and the news are still relatively easy to track down.
There were MIDP profiles[1] as long the version matched, the apps worked fine in my experience on any device although the devices themselves varied in their key pad placements; Nokia went crazy in their phone designs[2]!
I had a 3660 (friends called it the "communications brick"). There was no wifi and I couldn't afford a data plan but I was able to have the phone dialup via Bluetooth (think "reverse tether") to my Linux desktop. I never got into J2ME: being a fledgling Linux snob in college, I went for Nokia's C++ target and got stuck in the quagmire.
But MIDP profiles were so limited that you could only build the simplest apps. To do anything complex required calling proprietary extensions, which destroyed portability.
I can understand the desire to have the brackets at the same indent... but WOW does this break my brain having the inner code not indented from the bracket level. (I tend to prefer the opening backet being on the same line as the condition gate/guard and rely on the parser to inform me of missing brackets. This is even better in languages that have a single format convention.)
Wow. I had a CS professor insist on exactly that style. I couldn't stand it at first, but making accommodations was the whole point. Unfortunately it got me thinking about what I would want. Now I'm the weirdo and I rarely get to write it the way I want. <shrug>
I worked at STMicro for a while, and a neighboring team worked on Symbian support. I remember they had this weird coding standard that was essentially "why the fuck not?".
Now, over a decade later, I understand that they looked at the Symbian standard, and saw that anything goes.
Oh, I got a Symbian phone when I was 16 (I think?) and of course I did try writing native apps for it. Yes, the SDK was horrendous. The C++ dialect was so weird I was never able to make sense of it. (I probably could with my current experience.) I just remember that there were many, many methods that ended with L, this meant "Leave", and this was some bizarre replacement for exceptions, apparently. There were more types of strings than I could count. The naming conventions for things were very weird. The hello world consisted of something like 5 classes and took a minute to build. When you wanted to actually run the thing you made, you had two options: running it in an emulator that took several seconds to process inputs, or running it on your phone via some connector app that only worked 1/3 of the time.
I didn't get very far with native Symbian development. J2ME was just so much easier, and ran on everything under the Sun (pun intended).
> It had its own dialect of C++ which looks nothing like modern C++
Was this just a "using different elements of C++" kind of dialect, or was this an "early Win32 when you had to use pretend-C++ (ATL) together with your real C++, bridging the two with C" kind of dialect?
I feel like a lot of application frameworks developed in the 90s ended up in the latter style, as C++ was just becoming popular around then, and many frameworks chose to "merge into" C++ support from C support, rather than creating a ground-up C++ SDK.
Custom exceptions (no explicit try...catch, I think only ints could be 'thrown')
2-phase construction for C-classes.
Explicit lifetime management (to be fair RAII wasn't a thing in 'normal' C++ at the time either)
Link by ordinal
One interesting thing was that there were mandated, and strictly enforced, naming conventions and coding style.
For example, above I mentioned C-classes. You had to use these in certain circumstances by inheriting from a CBase class. This gave you a virtual destructor and zero-initialised the memory. R-classes were resources classes mainly for things that needed Open and Close functionality.
I joined straight out of university and probably learned more about softare development in my first 6 months at Symbian than in 4 years of uni. There were some incredibly clever people there.
> (to be fair RAII wasn't a thing in 'normal' C++ at the time either)
RAII in C++ dates back to 1984-1989, and Strousop wrote about it in his 1994 book Design and Evolution of C++. And C++98 had auto_ptr<>. Symbian's release in 1997 means it had a weird timing relationship with C++ standardization, but RAII was still enough of a thing at the time to be in that very first standardized STL release.
There is Alexander Trufanov's free book (in Russian) on programming for Symbian 9.x with many code samples.[0]
Also, as example of complex apps, there is code of Lonely Cat Games' X-plore[1] & ProfiMail[2] apps, released to Public Domain by LCG devs in 2015-2016.
Another one Symbian open-source app that I like: `fshell` — Symbian equivalent of bash + telnet + a posix-like set of command-line tools.[3]
And the latest app in development: S60Maps — OpenStreetMap & GPS tracker.[4]
FTR, Actually there is an experimental Symbian OS emulator for Linux & Windows.[5]
P.S.: And off course there are tons of useful stuff collected by "Symbian Archive" wiki.[6,7]
I was responsible for porting a fairly large C++ app to Symbian (this was like 15 years ago, so memory is hazy). The big problems were that exceptions were weird and non-standard, and you couldn't throw them from constructors, so anything using RAII had to be rewritten.
and it used their own proprietary toolchain, as a layer on top of visual studio iirc, that kind of worked in debug but actually no, I remember we had to purchase a specific nokia to run in dev mode, as not every nokia supported it or was actually supported by the toolchain at the time.
and I remember another pain point was feature detection, but can't recall the specifics.
I think VS was used before my time (2005), but then it used CodeWarrior and then after that Nokia's own IDE called Carbide.
It had MMP files which described the project and the files in it, a then a tool called 'abld' which was a perl script that did the compiling, which actually had two commands to clean... 'abld clean' and 'abld reallyclean' :)
My boss at the Austria Press Agency wanted a software to distribute our news to Mobile Phones in 2004 or 5 or so.
So I took a deep dive into Symbian with very limited C++ understanding. It took me at least a month to figure that that C++ is not C++ at all.
In the end senior engineers, were put on it. Project went nowhere. And then came iPhone and we went down the Mobile Browser Road (years later Apps I think).
They adopted C++ very early on in the language's life. The standard at the time had not even specified how exceptions worked, so Symbian rolled their own (TRAP and User::Leave).
But then they were stuck... breaking ABI was forbidden, so more modern C++ features couldn't be used (easily).
C++ was created in 1979 - I doubt Symbian adopted it "very early".
Also, the standard doesn't specify "how exceptions work" even today, in the sense that a lot of what happens when running C++ is implementation dependent.
But I can see what you mean about sticking to pre-C++11 (maybe even pre-C++98 ?) APIs.
The first C++ standardization was C++98, released in (you guessed it) 1998. Symbian's first release, under the EPOC32 name, was in 1997, with working starting on that OS in 1994 (and the company had a prior OS, EPOC16, that was from the late 80s)
Originally we used CodeWarrior internally and then Carbide. Most of the Carbide work was done in Dallas and
I remember them having a stressful time dealing with Symbian's weird MMP + abld build system.
Yeah, I know also those nice Perl based scripts with batch files glue somehow being called from CodeWarrior, just referred Carbide, because at the end the experience wasn't that bad, specially by the Belle days.
Google just doesn't get it, note that major GDC 2020 Android talks are mostly related to NDK improvements, 10 years later.
Although the NDK is really annoying, it's not required to build an app, which it seems like Symbian C++ was. I think that's critical for getting the app ecosystem off the ground.
Good question, I can't remember if globals were allowed, maybe they were as long as they were const so the OS could be executed directly from ROM. But again, I'm not sure, it's been some time.
I started a company with friends to write games for phones, before they were smart
Our fist breakthrough was at E3 in LA with a game for Nokia 7650, but we worked on prototypes years before
My first mobile connection was with a Nokia 9000i communicator, I was working for an ISP at the time that gave them to us to test mobile connections, and it felt like a James Bond movie
I learned so much developing on Symbian, especially being a diligent C++ programmer on a system that wasn't really using standard C++
Fast forward 20 years, I work on backends in Erlang/Elixir and never touched mobile development again
J2ME was nice, but limited, I lost hope soon after when iPhones came out and it was clear that the mobile platform wouldn't be fun anymore
But by the time Nokia took over Symbian it became apparent that they saw Linux as the future OS for high-end devices and Symbian was to be relegated to mid-level devices.