Introducing the Sony DS

[AlanJohn]

Not sure. Do you have a link to your Ipega?

http://www.dx.com/p/ipega-pg-9025-multimedia-bluetooth-controller-black-256612#.U3DjkvmSwwA

 

[WiiUBricker]

http://www.dx.com/p/ipega-pg-9025-multimedia-bluetooth-controller-black-256612#.U3DjkvmSwwA

I have the other one. I doubt that this is better than or equal to a 360 or DS3 controller.

 

[Pleng]

There isn't one. WindowsCE was pretty good, but it's discontinued now.Symbian was eh-o-kay in its prime, at least everything was more or less native. WinCE though... good times.

I think you're confusing a good embedded OS (which WinCE absolutely was) with a good mobile OS (which winCE absolutely WASN'T!)

 

[Foxi4]

I don't see why WinCE or anything WinCE-based (WinMo, for instance) could be called a bad mobile OS. My Windows Mobile 5 Phone did everything my Android phone does today, except almost 10 years ago.

 

[Duo8]

I don't see why WinCE or anything WinCE-based (WinMo, for instance) could be called a bad mobile OS. My Windows Mobile 5 Phone did everything my Android phone does today, except almost 10 years ago.

Does it do N64?
I used to like those phones too. They really give you the feel of a "PocketPC". Too bad they're phased out now.

 

[Foxi4]

I don't think hardware was beefy enough to support that when WinMo was around - the last WinMo phones were 1GHz with weak GPU's, really. PS1 worked fine though.

 

[Pleng]

I don't see why WinCE or anything WinCE-based (WinMo, for instance) could be called a bad mobile OS. My Windows Mobile 5 Phone did everything my Android phone does today, except almost 10 years ago.

It's a bad mobile OS for exactly the same reasons it's a good embedded OS - it allows developers direct access to the hardware so it's extremely vulnerable to malicious code - if it had even remotely taken off there'd be just as many f*d up jammed up phones as there ae f*ed up jammed up desktops and laptops.

You're looking through the eyes of a 'computer person' and seeing a fantastic OS that allows you to do whatever you want, which is exactly why it's a BAD operating system for a mobile phone which is supposed to be used by Joe Public.

Plus the UI absolutely stunk!

 

[Foxi4]

It's a bad mobile OS for exactly the same reasons it's a good embedded OS - it allows developers direct access to the hardware so it's extremely vulnerable to malicious code - if it had even remotely taken off there'd be just as many f*d up jammed up phones as there ae f*ed up jammed up desktops and laptops.

You're looking through the eyes of a 'computer person' and seeing a fantastic OS that allows you to do whatever you want, which is exactly why it's a BAD operating system for a mobile phone which is supposed to be used by Joe Public.

Plus the UI absolutely stunk!

I was fine with the UI because it was based on Windows, but I see your point, my view is indeed jaded. That being said, you could always create a User account and have admin access restricted (add a nice password that can be inputted from a recovery screen), then slap a nice skin on the UI and presto. Android is also full of vulnerabilities and new phones get rooted and customized within weeks from their release, but we live with that just fine. No OS is perfect, but some OS'es are just better than others when you want to develop for them.

 

[Pleng]

The UI didn't really share much in common with Windows. And I don't think rooting and customizations are security issues.

I agree with your point about development; although my reasons for preferring CE over Android are pretty much the opposite from yours - With CE you get access to the .NET framework and you can easily develop with the Visual Studio IDE.

Android development is messy, to say the least! But are your complaints about Java and APIs really valid? I'm guessing that most emulators are coded with the Native Development Kit. Now I don't know much about the NDK but I assume it gives you much closer access to the hardware?

 

[Foxi4]

The UI didn't really share much in common with Windows. And I don't think rooting and customizations are security issues.

I agree with your point about development; although my reasons for preferring CE over Android are pretty much the opposite from yours - With CE you get access to the .NET framework and you can easily develop with the Visual Studio IDE.

Android development is messy, to say the least! But are your complaints about Java and APIs really valid? I'm guessing that most emulators are coded with the Native Development Kit. Now I don't know much about the NDK but I assume it gives you much closer access to the hardware?

Essentially you can't program an app 100% in the NDK, no matter what you do. In fact, sometimes programming some sections in the NDK can lead to lower performance rather than higher performance. What NDK does is pre-compiling some binaries for you into machine code so that they can be executed by hardware instead of being interpreted. Thing is, the Virtual Machine still manages that. In practice it means that your application calls up a native binary, said native binary bounces off of the Virtual Machine, lands on the hardware and then executes - it's not your usual native access and it's far from convenient.

As for my dislike of API's, how many do you want? Programming on Android is so abstracted from the actual hardware that when I dabbled with it, sometimes I wasn't even sure what I wanted the thing to do. Just to give you a quick run-down of everything you have to worry about:

• The Application Manifest (this shouldn't even exist as a part of the application and necessitates that you learn XML on-top of Java)
• Virtual Machine, be it Dalvik or ART (this you don't touch, but you know it's there and you hate it because all it does is slowing your sh*t down, even if by a marginal bit)
• "Activity/ties" (because having a main() is for idiots)
• "View/s" (I know how to organize my screen, thanks, Nazidroid)
• "Intents" (if you happen to feel like running several Activities at the same time - because parallelism is only fun if it comes with frustration)
• OpenGLES (if used, but probably "yes", because it's the best way to get GPU acceleration)
• Shader Programming (If OpenGLES 2.0 or higher is used, be prepared to also learn OpenGL Shading Language, because Shaders are stupid and don't know what "default" means)
• NDK (whatever native binaries you tied to your code - of course you need to know C/C++ to use those!)
• Your actual f*cking application. In Java.
• Resources for ten zillion quadrillion resolutions (for busy idiots, not really necessary)

Your average Android app block diagram looks like an invasion of Daleks, and to make full use of the kit, you need to know 4 languages. Great. I'm sorry, but this is just unhealthy - what happened to "type sh*t in main() and it will happen"? Android confuses me. Hell, Java confuses me.

 

[Pleng]

Well it all stems from the fact that your app is not the most important app on the device. The phone NEEDS to be responsive when a call comes in. It's great if a phone can play kick-arse games and emulators but not at the expense of its primary function. This is why the activity lifecycle exists. Yes, it's overly and necessarily complex but there is absolutely a need for some kind of system in place.

You want to run everything in main(). I'm sure you're a good programmer who understands what you're doing. But there are hundreds of others out there who don't and all it takes is for one sloppy app to clog up the UI thread and you've got no way of dialling 999 when being chased down by a some maniac - is your desire to have full access to the hardware more important than the safety of other phone owners?

Manifest absolutely essential - you've never gone to the play store to download a simple app and then cancelled because it uses the permission "Read contacts and make phone calls"? I have - and if it weren't for the app having a manifest I'd never have known that the app was intending to be so intrusive.

I have no issues with the layout system. It's a pain to learn but very powerful. You say you "know how to organize my screen" - I can only assume you work with some kind of base layout then scale up or down depending on the screen size? Well layouts do that for you without you needing to do all the math yourself. What about supporting tablets vs phones, or even small vs big phones? Do you just continue scaling, or do you have a bunch of conditional statements in your code which will add additional elements on bigger screens? If you don't you're missing the point of the layout system, and if you do then you're just reimplementing it yourself anyway. Which is fine - you can do that using a canvas as your base view - but just because you "know how to do it", why do you think other people shouldn't be able to benefit from the system.

GLES/Shader Programming - I have no experience of, so can't comment.

I agree the resources system seems a bit daft - certainly when it comes to graphics, I just tend to use a single size. But it can come in handy. I've actually found being able to have a different set of strings resources for different screen sizes is generally more useful than having multiple graphical resources.

As an OS designed for a mobile phone everything there is there for a reason. Yes, in some areas they seems to have come up with overly-complex systems (the activity lifecycle for one), but for the end user it's essential that they are there.

WinCE is a great OS for embedded systems. Something like the Raspberry Pii, where you've got a piece of hardware that you intend to use for a dedicated purpose. But a mobile phone is first and foremost a communications device. Yes, they're now used for so much more, and there are plenty of people making money (and not making money) by making apps that really have nothing to do with communications. But if you want a bite of that pie, if you want the privilege of developing apps for phones, instead of software for devices, then you have to accept that you are not the primary focus - the user is.

 

[Foxi4]

You don't have to sacrifice any of the primary functions of the phone by going full native - the CPU's perfectly capable of running on a scheduler. Do you have a ridiculous framework like this for PC applications? No, you don't (maybe aside from the Window manager, which is easy enough to handle). Do they magically lock up everything else while they run? No, of course not, that's ridiculous. Each application should get an appropriate portion of processing time depending on the CPU load, with the primary system processes taking priority. The manifest could just as well consist of a drop-down menu with Android targets, a few fields for strings and a couple of privilege checkboxes - there's absolutely no reason why you should compose it yourself. The layout system is great for when you want to build a drag and derp application using the built-in drag and derp widgets, but other than that you're unlikely to use the default Surface View in this day and age - you'll use OpenGL, there's no reason why you wouldn't, making these components almost entirely useless. I'll give shader programming a pass only because it has to be done cross-platform anyways - that was Khronos' idea and supposedly improves shader performance greatly, it's just a pain in the butt to deal with. As far as resources are concerned, I just shrugged at it and used a one-size-fits-all solution, namely LibGDX, but even then it doesn't cover you as far as icons and misc. crap is concerned, so that's a waste of time, still.

Back to WinCE, I always found it a great OS in general, not just a great OS for embedded systems, such as ATM's and whatnot. It simply did whatever I asked it to do and it never complained. It was simple, simplistic even, but it did the job without whining or overcomplicating anything, and I praise it for that. It's a shame that it's gone, but all I can hope for is a new dawn for x86 cellphones and other portable devices, or rather, ones that don't suck. ARM is all nice and dandy, but something using the x86 Windows core or an x86 Linux distribution would blow anything else away - a "real Windows Mobile" would be the answer to my prayers.

EDIT: I just realized - we're srs in EoF. Stahp.

 

[Pleng]

Yes poorly written applications have locked up my PC, they can even force a reboot.

The manifest could just as well consist of a drop-down menu with Android targets, a few fields for strings and a couple of privilege checkboxes - there's absolutely no reason why you should compose it yourself.

You don't need to compose it yourself. Both eclipse and Android Studio will compose it for you based on, uh some strings and checkboxes.

The layout system is great for when you want to build a drag and derp application using the built-in drag and derp widgets, but other than that you're unlikely to use the default Surface View in this day and age - you'll use OpenGL, there's no reason why you wouldn't, making these components almost entirely useless.

If you're doing game programming, maybe. For anything else, the widget system is widely used.

 

[Foxi4]

Yes poorly written applications have locked up my PC, they can even force a reboot.

Now that's a doozie - my system usually remains stable, but I suppose that does happen on occasion. It also happens on Android though, so it's not like the convoluted life cycle helps in any way here.

You don't need to compose it yourself. Both eclipse and Android Studio will compose it for you based on, uh some strings and checkboxes.

That's not entirely correct - some changes to the manifest have to be inputted manually, depending on what you're doing. Yes, you are getting a generated Manifest, but it's grossly incomplete.

If you're doing game programming, maybe. For anything else, the widget system is widely used.

Which is why Android applications widely suck. The default surfaceView is not hardware-accelerated in any way, so it taxes the CPU with tasks the GPU would perform more... admirably, namely rendering. The default surfaceView wouldn't be one of my gripes if only it didn't suck.

Again, srs in EoF, mayn.

 

[WiiUBricker]

I guess there is now too much value in this thread for keeping it in the EoF, even though only due to off-topic posts.