151–160 of 290 posts
This analysis elides the fact that all OSes in the Symbian era had to compulsively ask about accessing the Internet because data usage was at such a premium.
That's not completely correct. My NEC smartphones didn't. Nor did the early BlackBerrys that I used.
Earlier quoted context omitted.
> 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 man…
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 I remember another pain point was feature detection, but can't recall the specifics.
I don't really understand why setting up permissions for apps are seemingly so hard get right for Android and apple. It's not complicated at all yet they fuck it up endlessly. It seems screamingly obvious that I might want to give apps access to some of my files but not all of my files. Some of my contacts but not all of my contacts. No such options exist. Many other permissions are also needlessly coarse grained for…
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. Net…
Earlier quoted context omitted.
I really liked the Meego iteration. Its UI was top notch.
There is Tizen and some other derivative I can't remember still actively developed. I would by a Tizen phone if I could be sure there are enough of good apps available for it and if I didn't trust Samsung even less than I trust Google.
Nokia owned Qt and Samsung didn't want to pay fees or buy Qt outright, so they went with the mostly unknown Linux Enlightenment project (didn't hurt that it's main dev worked for them at the time). Likewise, Nokia owned rights to SwipeUI, so they opted for a remake of the Android UI.
If they'd gone with something like a cleanroom implementation of SwipeUI or webOS, I think Tizen could have been a success. Instead, it just feels like a bad, outdated edition of Android. If users wanted that, they'd just use Android instead.
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. Net…
> 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 man…
No std::string
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.
> With the latest releases of Android and iOS, we’re back to where we started. Both now prompt you the first time an app asks for access. Both give you regular reminders of which apps may be snaffling your data. Both let you manage access and selectively deny apps. Every OS should do this, desktop OSes included. For the last 2 decades I've been using personal firewalls on Windows to do just this, now I use LittleSnit…
Earlier quoted context omitted.
From the inside it wasn't that apparent, hence why the first Linux based prototypes did not had any radio support. And as cumbersome as Symbian C++ might have been, Android Studio + NDK + JNI wrappers still make me wish for Carbide + Symbian C++ + PIPS.
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.