Ah, it's nostalgia-a-clock. I worked on Skype for J2ME with a 3-4 person dev team. Custom UI kit, 128x128 screens, 128kb available memory and other fun limitations.. I think we re-wrote our text rendering/styling/wrapping code more times than there were actual releases of the app :)

I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment.

> I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment.

As someone from the c64/apple][/atari generation... it was constantly amazing to see how much people could push a single device. Lots of creativity, as you say. But... we seemed to hit a wall with the whole j2me-era of "just get creative to work around things!" mindset. Because, IIRC, there were dozens of different devices that all didn't work the same way - you'd have to get really creative to get things to work in 128k, but then do it again and again and again for each target device.

There were millions of C64 units in people's hand in, say, 1986. And similar for Apple ][ units. You could be assured of a decent audience/sales/users if you ported to that platform, even if there was a lot of 'creativity' to deal with. The j2me device world always seemed a lot more fragmented to me (but maybe it wasn't?). But just saying "this runs on a java device" was different from distribution - allowing 'regular' people to get something in to a centralized store/distribution point seemed another big win for the iPhone world.

EDIT: fwiw, this made me spend a few minutes in youtube looking at old c64 and apple and Atari demos. what people ended up doing with those devices - years after they were mainstream - is still crazy to me.

> fwiw, this made me spend a few minutes in youtube looking at old c64 and apple and Atari demos. what people ended up doing with those devices - years after they were mainstream - is still crazy to me.

The craziest ever, to me, is the following in 256... bytes. Bytes (including the music ofc, which is the whole point).

https://youtu.be/sWblpsLZ-O8

Then you are going to love this 256 bytes demo.. :-)

Memories by Hellmood https://youtu.be/Imquk_3oFf4

That's incredible!

> The j2me device world always seemed a lot more fragmented to me (but maybe it wasn't?)

Oh it sure was! There were device specific workarounds and hacks all over the codebase.

Also that version of Skype was way better than this hot steaming pile of manure currently shipped by Microsoft.

Thank you! It really was a different era back then :)

My very first industry job was making J2ME games and oh my god does it still give me nightmares.

If you miss it, just try Android, contrary to Google arguments against J2ME, the fragmentation experience is kept unchanged.

We have many more issues supporting multiple versions of iOS than supporting multiple versions of Android. But neither are not even close to the nightmare that was J2ME.

Another one that wasn't blessed with OEM deviations from AOSP.

We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers).

Anyway, even including those cases it is still very far from J2ME days.

- Bluetooth issues

- Camera is hit and miss, even after the renewed API

- Apps randomly killed on the background

- Intents that don't launch as expected

- NDK debugging that cannot attach to the server running on the device

- Unstable GPGPU drivers

- Keyboard handling

- Perfectly working code that needs to be rewritten just because

Yeah so much better than J2ME.

You know, even if you're right we still see much more issues in iOS. For example, a simple Xcode minor upgrade can randomly break some flows.

> - Perfectly working code that needs to be rewritten just because

This issue is much more frequently on iOS than Android, since iOS deprecates features much faster and there is no compatibility layer between versions.

Except on Android that happens on the same Android version across devices.

> - Bluetooth issues

Aren't they rewriting this thing in Rust?

> - Camera is hit and miss, even after the renewed API

Give it time. CameraX is already vastly better than what we had before.

> - Apps randomly killed on the background

Up to OEMs.

> - Intents that don't launch as expected

?

> - NDK debugging that cannot attach to the server running on the device

Welp.

> - Keyboard handling

Fixed.

> - Perfectly working code that needs to be rewritten just because

?

- Devices never see updates, other than a select few flagship models

- It does not matter if the blame is on Google or OEMs, it is still fragmented

Circular arguments are circular.

Nope, just the Google support team arguments that ignore how similar Android is to J2ME in many aspects.

One needs to support the home team after all.

So now I am promoted to "Google support team" just because I bought to the discussion some observations from my own company? But you bringing your own observations does not put you on "Apple support team"? This seems completely fair /s.

Well, my point in the end is that even with all the issues that you pointed (some are true, some we didn't hit because we don't use those features), we still see more issues on iOS even when they're a smaller portion of our user base.

Heck, even if we got the most problematic Android phones for us (Asus budget phones comes to my mind), it is still has less issues than iOS.

It's not as bad as it used to be. The "drawers full of devices", all terrible and broken in unique ways, gave me flashbacks to the Android 2.x days.

They are still quite actuall,

https://pamartinezandres.com/running-android-tests-on-cloud-...

Especially with respect to Bluetooth quirks. Every single phone has a different set of bugs in its bluetooth components, and none of those sets are remotely empty. In the end, we decided we could only afford to support the 5 most popular models of the day and if you don't have that phone, then too bad for you.

That one doesn't seem like purely on Android. I've never seen a device without Bluetooth bugs. The protocol is so complicated and implementation relies so much on chips that never get fixes that I'm surprised it works anywhere.

I wasn't criticizing Android, I was criticizing Android phones. I'm sure iPhone doesn't implement the protocol perfectly either, but we certainly observed fewer issues. Whether that's because our BT stack vendors did more testing with Apple devices or because Apple has fewer bugs or both, I'm not sure.

From my experience Apple’s Bluetooth stack is more stable than a typical Android stack and miles better than the Windows one. I have so many headphones that can pair with a Windows laptop exactly once, getting them to work again requires a full reset on both sides every time.

It was kind of bad until recently, it's ok now but gets a lot of custom protocol help if you buy AirPods.

There's a lot of tuning needed to avoid desense issues when your device supports 3+ wireless protocols - that's why your PC motherboard comes with an external antenna for Bluetooth and your iPhone doesn't.

But then they still insist on removing the headphone jacks because "wireless is better".

Don't get me started on programming with BLE on Android. *shudders*

I literally yesterday had to buy my first iphone since the 3G because my wife bought some BLE hardware for her work that won't work properly with her Pixel 3. (It's a set of 12 devices and the Pixel can only connect to six at a time). The manufacturer won't even list Android devices they claim to have tested it with.

Our management kept asking us to fix these issues with software. We tried things like transparently rebooting our BT module and prompting the user to do common fixes (e.g., "turn your phone off and on again") but most of the time these wouldn't work, unsurprisingly.

It's gotten much much better in the modern times. Android 2.x would break your app in many spectacular ways, but Google has been steadily adding more coverage to its "compliance test suite" that a device must pass to be eligible for Play Services preinstall. On 4.x, there were some Chinese phones, like Xiaomi and Meizu, that meddled with notifications, action bars and list views, sometimes to the point of making your app crash, and I do remember having to work around them. But if you support Android 6.0+, like many new apps do these days, you don't have to worry much about device compatibility.

I read the J2ME spec, looked at the procedure to draw an array of pixels to the screen, and noped out of there. Browser Java was bad enough, but J2ME? I wasn't gonna do that to myself.

What was so hard about it?

http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...)

http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...

> Java be like, "we are cross-platform" > mobile manufacturers, "hold my phone"

The problem with cross-platform development in a nutshell. Still to this day writing an Android/iOS app using PCL code is a headache

At least adapting to another private API was easier because the scope was pretty small. It's probably lost forever now, but I had a project which repacked jars to add a few wrapper classes to convert Nokia-specific j2me games to be compatible with my Siemens.

Yeah; as things get more complicated though i feel that this concept will never return

Oh wow, yeah my first mobile game studio had a huge industrial fastener shelf with little drawers stuffed with different phones. We started in 2004, and feature phone game dev was indeed wild. We did a lot of WWE games in 2d and 3d, needing ~15 different reference builds ranging from 64k 2d builds to 800k 3d for high end, plus another set for all the BREW devices. Managing code, asset pipelines, and qa across high/med/low 2d/3d Java/cpp permutations was a huge challenge, but it was so satisfying to be good at. I love what mobile has turned into, and never want to debug another random c crash on device ever again, but I do miss the cabinet of phones and all the crazy variation

I remember Javaground!!

We actually worked with the BREW platform, so we only had 50 phones instead of the 300 java ones. Lol, too funny

Cool! The BREW automation guy at JG was a genius C coder. Those phones seemed more capable in general...but just as quirky.

I worked with a few people from JG. I also worked on a bunch of J2me games. It was an interesting time to be in mobile.

I was just out of college, like the 5th employee at Irvine, a lowbie gamedev. I remember doing some collab with nearby studios (like WF), one where my future wife worked!