Comment Re:NIMBY at its finest (Score 1) 409
And your credentials are what, exactly?
And your credentials are what, exactly?
The main difference in OS5 was the addition of "PNOlets", chunks of native ARM code. Chapter 14.
It's still tricky. When I ported Palm's OS4 emulator to Android, I had to do some library coding and tracking down sample source code was... nontrivial. Definitely look for open-source Palm programs, like pssh, and learn from them.
What the FUDGE are you doing in the woods where you want a Cell phone on all the time?
Staying available in case my wife or any of my kids who aren't on the trip have a medical emergency? I apologize for having purposes that don't meet up with your approval, or enjoying myself in ways that you frown upon. I will re-evaluate all my life choices in light of your preferences immediately.
Feature phones work better in areas of sketchy cell service. Their battery life is very long. The battery requires less power.
I agree. But that means I have to have multiple cell phones for different purposes. Which brings us back to... Modern phones do a lot more, and a lot faster, than older tech... but I admit I miss the battery life of the old Palms. One month on a couple of triple-As. Not having to charge my phone every single night would be pleasant. Wise words indeed.
Solar battery takes care of the problem.
Not in Michigan woods. Not even in the middle of summer, with several days of clear skies, using this. And yes, I speak from experience. Especially when you're in areas with poor signal that drain the battery faster.
Leaving aside issues of unexpectedly not being near your chargers for too long even in day-to-day life, etc.
Clearly you're happy with your battery life. Congratulations, felicitations, mazel tov, and so forth. That doesn't mean that people who are not satisfied are wrong, however.
Because setting a phone down on a charging mat next to the bed is oh so hard.
In a tent - yeah, it is.
My own 486 had extremely dissappointing performance when compared to a even mere 68000 until RAM prices became low enough to adequately equip a PC.
True. I was astonished when I invested a decent chunk of change and bumped my 100MHz 486 from 16MB to 64MB of RAM. Multitasking actually became practical, especially running Mozilla alongside something else. Of course, the 68K Macs of the day weren't that much better at supporting 'a browser and something else'. The cooperative multitasking of the Mac OS helped reduce overhead, but it still took RAM.
And the 68k platform seemed to be neglected by Motorola.
It sure seems like the M68k architecture could have been pushed forward more. Yeah, it was CISC, not RISC, but it was a very clean CISC. Modern x86 chips are really RISC machines internally, they just have a bunch of translation from the CISC instruction set to the 'real' ISA inside. If nothing else, that approach could have worked for M68k, right? Probably better, since the basic M68k ISA isn't so crufty and ugly like x86.
Congratulations, that's one of the stupidest things I've ever read on
"They are the only people who would have actually earned it."
Everyone here is dumber for having read that.
It's like there's some strange black hole of information available on the internet that only happens around the super specific topic the Ask Slashdotter is interested in. I'm pretty sure all of these folks are the ones that were our best horses in Keener Bingo:
Ding ding. Fuck, C# is fine and dandy and pretty fucking fast, if your target platforms and related asset and tool ecosystems are cool with it, and you're not boneheaded about what you're doing. Questions like these are so silly - if you do so much homework to know what you know and what you don't know, I'm pretty sure you're smart enough to find the right information, books, etc. What a passive aggressive inquiry. If you're convinced you can write an intelligently framed question with tons of context, then why on earth can you not do a little google mining for books that focus on C# game development? This discipline is hardly a secretive cabal.
Though I do agree that JNI is a serious pain. On the other hand, I've developed for Netware and Palm OS, so my standards for pain are probably artificially high.
So the core of the app, the 'engine', is in C++ and must be natively compiled, while the UI and such is in Java. Naturally, the binary's compiled for ARM first. This actually runs on a lot of Intel Android tablets because they have ARM emulators. But, thanks to a user finally asking, I put in some time and now I can make an Intel version. (Heck, the original source was written for Intel anyway, so it wasn't a big stretch.) The existing tools are sufficient for my purposes. And it runs dramatically faster now on Intel.
However, for the developer it's mildly painful. The main issue is that you have a choice to make, with drawbacks no matter which way you go. You can include native libraries for multiple platforms, but that makes the APK larger - and according to a Google dev video I saw, users tend to uninstall larger apps first. In my case, it'd nearly double the size. So instead I'm putting together multiple APKs, so that ARM users get the ARM version and Intel users get the Intel version - but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.
Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.
I've noticed several design suggestions in your code.
