90% shared code? so what? (Score:-1, Troll)

is it me - or are some of the slashdot moderators total idiots? either apple or microsoft fan boys. when i was your age you were probably still in diapers. obviously they miss the point. oh well.

If you are writing different libraries for each platform -- that's not 100% code re-use

sure it is. if you use libc - is that code re-use? i have done a library for a generic platform for developing on top of. it is a library; that as a developer you dont have to write - you just use it.. just like openGL, libc, mathlib et al

You're not "just distributing" the same binary for each platform.

unless there is a universal "thick binary" standard; you are going to have to ship different binaries. thats how it is.

What are you using for graphics, sounds, storage, etc. on each platform?

graphics - you can generically define graphic sets based on DPI. scaling, layout design. it is not difficult to play with different resolutions. as for audio; worst case; you have PCM audio.

You're doing this without a bunch of #ifdef's?

yes!

How are you accounting for different screen resolutions, graphics hardware, touch capabilities, and other hardware difference?

very good design. :)

but seriously - a good architect design can allow you to dynamically detect, load and work with functionalities across platforms. abstraction is dangerous - as it typically defines a common denominator. like web technologies are being dynamic in the way they work (ref: RESTful) - you can do the same with programming.

i've been working with mobile platforms for 10+ years and i've played with almost every platform out there. i avoid .NET and Java like the plague for mobile applications - the end results are very slow and just doing deliver what i want from a programming environment.. sure, i need to do more effort - but the results are better.

this is what i do for a living as well. if you want to discuss more offline - you can reach me via the contact me section on my website.

i've been writing code across many platforms with 100% code reuse - more importantly, not using a runtime - all my applications are native. just write a few basic entry points; put the platform specific points in a library and then all your applications link against this. you then end up with native binaries for each platform - just distribute. this is not news - most developers have been able to do this for years (including myself). i can build applications for windows, linux, macosx, iphone, windows mobile, symbian series 60/uiq, palmos, moblin, maemo et al by doing this and i've been doing it since 2003.

i think this information is out of context. it is very unlikely developers will be abandoning platforms like the wii, ps3 et al - they will most likely be looking to use the iphone as a complimentary development platform more than anything else. there is just as much business everywhere; and if everyone was moving to the iphone - i would probably get out of it :) i was there from the beginning as a hobbyist - and it already is getting flooded and saturated.. it is a pity honestly.

10.3 was powerpc specific - and you can see from the screen shot that they are using pearpc - a powerpc emulation engine.

what would be much more interesting is to port iphone os to the n900 - it has an ARM cpu and should be able to run about the same speed as the iphone itself - that is more a challenge. putting msdos on symbian, android, iphone os, windows mobile is simply a matter of porting dosbox or so; when will someone take on the true challenge :) take a recovery image and flash it to an ARM device with similar specs.. should be doable :)

wow.. you surely must not get it.

what do you think the JVM is written in? JIT support is NOT available on mobile implementations typically . your confusing the advances in desktop Java vs the mobile versions.

C does not require any virtual memory / exception handling.. and most C++ support requires you disable it anyhow. if you screw up your memory access; of course it'll reset - thats something you'll learn as a mobile developer.

actually; the platform i'm built has layers for:

- palm os (68k)
- palm os (arm)
- tapwave zodiac (drm specific)
- windows mobile / pocket pc
- vtech helio
- symbian s60
- symbian s60 (3rd+) (binary break)
- symbian uiq,
- ebookman
- gizmondo (gaming handheld)
- sony psp (homebrew)
- windows desktop (95+)
- linux
- moblin (drm specific)
- mac osx
- iphone / ipod touch
- android (in beta now)

the platform is just a target when we compile :)

for android; we have a thin Dalvik application that gives us a window; from there - we have a native call using the NDK to render the framebuffer that we show as a window within the application itself.

you would NOT build different versions for droid, htc hero, G1 etc.. as long as they use the same CPU architecture (ARM in this case); the applications will work across the various devices.

depending on the phase - we have the various platforms running at the latest version; the key point is our applications use a common source code base - so, adding/removing a platform does not require any changes to the application itself.

if you have further questions - please don't hesitate to contact me. we've been building this layer for over 8 years now - and we have seen platforms come and go! our framework has been used commercially; but as a platform - you don't see it when it is being used.

my point is he shouldn't be complaining about good debugging environments. be happy and thankful he doesn't need to deal with printf() for debugging.

for applications you intend to sell on the app marketplace, you use C++?

YES!

actually; we use C basically - on iphone; you need to have some objective-c wrappers to handle the device specific execution entry point. on symbian; you need C++ classes for the the framework base.

you do need to re-compile your binary for every PLATFORM (not device). if you want to see it in action; check out http://www.mobilewizardry.com/multi-platfori/atariretro/ (commercial applications) and http://www.mobile1up.com/ (iphone, desktop apps) - this is what i specialize in. when i hear about platform fragmentation i laugh. be a good architect - and your problems are solved.

all our applications BUILD NATIVE - so, there is no runtime environments required and we have binaries optimized for the platform. when a new platform comes; we simply rebuild utilizing the tools and/or minimal custom coding for the execution frameworks

Java is he answer to platform fragmentation?

no it isn't - it is in *design* - not in practice.

Java provides the classic write once run anywhere; have you ever tried to build a J2ME client? do you know how many skews you have to build to support all the phones? so much for write-once-run-anywhere.

secondly; since mobile devices are underpowered - you need speed/fast applications to make them useful. Java runs on top of a VM - VM's are slow. you are looking at 20x speed slowdown; and there is no JIT (just in time) compilers available on mobile phones.

Java belongs on the desktop and server - not in the mobile space. you can argue as much as you want - i left Java programming to get into mobile development back in 1999. i've got years of experience within this area; surely more than the author of that article.

Show us on the doll where Chris Haseman touched you.

heh - i wonder how many people realize he is a martial arts trainer as well. i think hats off to the guy for getting the press - but, he seems to be complaining a lot about something he seems to be supporting heavily (author of book et al)..

i prefer printf() debugging - how is point 8 related to point 3? i can do printf style debugging on every platform :)

Looks like the author is so green behind the ears he does not even know where the concepts of such mini applications with well defined interactions with other mini ops are coming from. At least one thing is sure, he got the attention he craved so much.

i think we can knock that down to experience :) lets take him back 10 years and program newton and palm os devices and see how much he loves android after that.

>> how long does it take to be a "veteran mobile application developer?"

checking out his profile (http://www.linkedin.com/pub/chris-haseman/1/369/a32) he has barely touched the majority of mobile platforms :) where is his symbian, palm os (68k, arm), ebookman, embedded linux, psp, nintendo ds, experience? surely - some of us started this stuff professionally back in the late 1990's with devices like the newton and palm professional. boy how things have changed - yet some things stay the same. he announces himself that ""(and by "in my day," I mean two years ago)"".

>> 3. Device Debugging

be thankful - some platforms you still need to do printf() style debugging.

>> 6. Java—Thanks, But I'll Take It from Here

Java - probably the worst language used on mobile devices to date. the desktop and server platform has evolved in many ways which are not being reflected in the mobile space; due to battery life, talk time etc - the typical moore's law of computing doesn't apply to mobile phones. there was a period where CPU speeds dropped on mobile devices - hopefully things will change coming up with new ARM and low powered x86 CPU's - but time will tell.

A true mobile developer demands a native C/C++ interface on mobile devices - if you want something done, more than a bouncing ball on the screen - its the preferred way. NDK under Android is a must - C/C++ isn't that bad - if you know what you are doing.

>> 8. Platform Fragmentation

its a problem? come on - seriously. you deal with it. you design around it; thats where your years of experience really kicks in and allows you to build cross-platform applications without issues. just because most companies hire an outsourcing department or "specialists" on specific platforms isn't a problem - it is a choice. there are plenty of alternatives out there.

So, you going to port liberty over? ;) So we don't have to try and run it in Classic. And yeah, I remember you as another regular from the old PalmOS mailing list about 10 years ago

Liberty was written in 68k assembler :) we ported it to MIPS for a contract job. but no; gameboy emulation; plenty of other options available out there.. but i do intend to bring some of my other palm os games up-to-date :P