Best Platform For Hobbyist Mobile Development? 143
An anonymous reader notes a blog entry, possibly his own, comparing and evaluating 8 mobile platforms from the point of view of their suitability for a hobbyist programmer. Covered are iPhone, Java ME, Windows Mobile, Linux, Palm, Brew, Symbian, and Blackberry. The writer seems open-minded and is a strong fan of free software, but he gives the edge to Windows Mobile for this class of developer.
Badly written (Score:5, Insightful)
Re: (Score:2)
Re:Badly written (Score:5, Funny)
Re:Badly written (Score:5, Informative)
Nothing to see here.
Re:Badly written (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:Badly written (Score:4, Insightful)
Re: (Score:2, Interesting)
Re:Badly written (Score:5, Insightful)
I have tried all the platforms. Palm based treos are decent if you use CASL to write for them. it's fast enough for management to be happy and powerful enough for the typical programmer. but it sometimes causes problems and connectivity out the cellular connection can be a PITA.
windows smartphone 5 after getting past the C# strangeness is actually quite nice to write for. and releasing for a new phone is as easy as a compile. the current software I write for the company on the phones we are about to roll out (deploying the samsung blackjack to all field employees and throwing away the blackberries.) allows full job tracking and other task management easily. all phone report back to a central server management has a complete up to minute picture as to where all projects are at and the employees love the fact that they do not have to do any paperwork anymore.
I suggested the Linux phone offering on openMoko but it's hardware and software is still early beta and not ready for company wide use. right now the dirt cheap WM5 smartphones are the best solution for rapid deployment of mobile applications for a company.
and I hate to say it but Microsoft seemed to got this one right. which does suprise me. they dropped the ball on all the other ones. AutoPC and the others (windows CE) sucked HARD.
Re: (Score:2)
Re: (Score:2)
OpenMoko? (Score:2)
As an iPhone owner, I am really considering looking at this product. Running something like Processing (processing.org) on a device with a touch screen would be great. Windows/Microsoft has alway had a pretty decent perspective on developer support, even if their products aren't personally relevant.
SuperWaba and OpenMoko (Score:3, Interesting)
First, SuperWaba [superwaba.com.br]. It is by no means a fully feature platform, but if you are just doing some basic programming and want to be able to support multiple platforms (WinMo, Palm, and Blackberry) then it is fairly easy to get up and running. Also, it based on java, so 90% of java examples will "just work" when programming with SuperWaba. FWIW, that is what we are using for our deployment of a mobile solution for our company. Also, it is GPL for the community ve
Re: (Score:2)
Re: (Score:2)
Strong fan of free software??? (Score:5, Funny)
Coming next to Slashdot: up is down and black is white.
Re:Strong fan of free software??? (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Re:Strong fan of free software??? (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2)
If it were just software people had to buy, with no online element, thepiratebay would provide an adequate delivery service that would force the company out of busines
Re: (Score:2)
Is it? oh dear. far too many people I know have said this.
Still, I will continue writing mine. Either I succeed or I create a new level of sucking at game design.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
It's already here: Our uptime. Your downtime.
Re: (Score:2)
Mostly useless (Score:5, Insightful)
Examples:
iPhone
It's not clear he's developed for it. He spends his time whining about the closed SDK, which is valid enough, but could have simply said "Apple doesn't welcome outside developers currently". And left it off.
Blackberry
I can just quote him
"Next comes the blackberry, I have no idea about this as a programming platform so cannot say much about the SDK support."
Brew
And here:
Brew as a platform is great but its not a platform for a hobbyist programmer. The tools are "supposed to be good. I have never directly worked on a brew project so cannot say much about it."
Linux
(goes off boring us about his dislike of GPL (fine, but out of place). And then finally gets to the matter
(His JavaME and Windows Mobile coverage is decentish)
Re:Mostly useless (Score:5, Funny)
Re: (Score:2)
Documentation and examples are plentiful.
Supposedly, there are over four billion devices that can run Java ME. (Aside: the fact that Apple rejected Java ME for the iPhone is a testament to how closed they wish to keep it.)
I have written several games for my $20 el-cheapo phone. I had two choices for loading the application. 1. Get Internet service on the phone (which I already have) and put my JA
Issues (Score:3, Interesting)
Right off the bat, two very large platforms, he says 'I've never done anything with this one.' So he counts it out -- why even put it in the article?! My minimal experience with Blackberry development seemed pleasant enough -- it was easy to compile the software and get it on the phone, and it was easy enough to execute it. Granted, it was a loaner blackberry so I only got it for a few days, which in my case, was enough time to tinker with example code.
As for Brew, which the author also states he has no experience with, but goes on to talk about the horrendous signing requirements...which I guess is better than the one-sentence approach to Blackberry.
As for Symbian, wtf is he talking about? I had a good friend that was porting some small-time development house's flagship phone cardgame suite from, believe it or not, XBox to a Symbian smart phone. I don't recall what version of the OS it was, but it certainly didn't seem like it was a pain to sign anything. He showed me the entire process - save code in IDE, compile code, open phone in My Computer > Bluetooth Devices section, drag-n-drop the compiled package, go on phone, run program.
He did however complain about how picky Symbian was about memory management, and that it was extremely annoying in that it would tell you about every byte you didn't clean up perfectly when your application closed. I suppose thats a good thing and a bad thing. Maybe they had some weird dev phone that didn't need signing, I don't know -- they were big enough to have a developer XBox 360 several months before it was officially released.
For some reason, I have a feeling this guy was just running out of material and got bored.
Re: (Score:3, Informative)
J2ME (Score:2)
Sun is snatching defeat from the jaws of victory; give it another few years and they'll have thoroughly destroyed the mobile Java market as well, just like they did with the Java desktop market.
Re: (Score:2, Insightful)
Re: (Score:3, Interesting)
It's the Java way, or maybe the Enterprise way. They like acronyms and buzzwords and pretending they've invented something new, when it's really something that has existed outside the Java world for ages, or a workaround for some limitation of Java.
``Sun is snatching defeat from the jaws of victory; give it another few years and they'll have thoroughly destroyed the mobile Java market as well, just like
Re: (Score:2)
Oh, but your phone app should work just fine in a browser, ye
Re: (Score:2)
No, this one Sun did to themselves. While Sun squandered away Java's installed base in the browser, Flash managed to establish itself as a de-facto standard.
Microsoft made it not work on Windows. Not being able to reach 90+% of your target audience = dead product.
Microsoft has done many sleazy things, but "making Java not work on Windows" isn't among them.
Re:J2ME (Score:5, Interesting)
Java EE is an utter mess, in my opinion. Too many acronyms and buzzwords and oh god the XML configuration files where everything has to be configured in three different places and then when you get something wrong it breaks and you can't figure out why... *deep breath*
That was my impression of it anyway. Some of it was incredibly useful, but all the unnecessary configuration just got in the way.
J2ME is nowhere near as complicated or difficult to get up and running. Eclipse, the EclipseME plugin and a compatible device are all you really need. The plugin does all the essential stuff for you, and having bluetooth on both the device and your PC makes deployment easy. For more serious stuff I use J2ME Polish (as in Mr Sheen), which handles handset compatibility and APIs quite well, as well as giving more control over the GUI.
That said, I got the distinct impression from TFA that, on the subject of J2ME, the author didn't have a clue what he was talking about:
For a start, MIDP 2.0 is part of the CLDC Wireless Toolkit. And as for "where am I supposed to test it"... well, the toolkit comes with an emulator for precisely that purpose. Most modern mobile phones are also MIDP 2.0 / CLDC 1.1 compatible, so that shouldn't be a problem. There are also optional APIs that the mobile manufacturers can provide according to the capabilities of the phone (for example, the Nokia N95 contains a GPS unit, so the Location API is included).
I'm not saying that it's the best mobile development platform out there, as I've come close to tearing my hair out when faced with some of it's limitations. But if there's one thing I can't fault it on, it's the shallow learning curve. I suspect the author wasn't really trying.
Re: (Score:2)
*repents fervently and in the least sincere manner possible* >.>
Re: (Score:3, Interesting)
Re: (Score:1)
Re: (Score:2)
I have a sprint ppc-6700 that I have to carry for work. It's junk. The os hangs multiple times a day. Any app but the most trivial crushes it. Starting any app is dog slow. It is truly painful to use.
Re: (Score:2)
If you're aiming for CDC/PP then you just need to target Java 1.3-compatible class files.
Not just J2ME (Score:3, Funny)
How many different 3 letter combinations starting with J can still be available?
P.S please don't work it out, it was a rhetorical question
Re:Not just J2ME (Score:4, Insightful)
It's crazy isn't it. What's most infuriating is it means when you go for a Java job half the time you'd get turned down because you haven't got the latest three letter abbreviation in your CV (resume) even though you're perfectly capable of churning out Java code and you'd be familiar with whichever two APIs they use most pretty quickly.
Re: (Score:3, Insightful)
It's crazy isn't it. What's most infuriating is it means when you go for a Java job half the time you'd get turned down because you haven't got the latest three letter abbreviation in your CV (resume) even though you're perfectly capable of churning out Java code and you'd be familiar with whichever two APIs they use most pretty quickly.
There are only 676 possible TLAs that start with 'J'. Why not just list them all?
Re: (Score:2)
Re: (Score:2)
Re:J2ME (Score:4, Insightful)
It starts from what J2ME is. Or rather what it is not.
First and foremost, it is not a product -- at least of the the company that controls it. You can't buy J2ME and plop it on your phone; it has to be put there by the manufacturer, who in turn sells them through the wireless carriers, who don't give a shit about anything unless it can be turned into a monthly service fee.
Secondly -- and this accounts for the alphabet soup issue -- J2ME isn't really a platform. It's more like a family of specifications, or at least it is "marketed" (?) that way. Sun's direct audience for J2ME isn't users, it isn't developers, nor is it enterprises. It is device manufacturers. Since devices come in all shapes and sizes and capabilities, J2ME is balkanized so that there is a J2ME specification that work on just about anything more powerful than a PIC. Furthermore any J2ME implementation is going to extend the standard both with non-standard capabilities and with a non-standardizable selections of optional features. Which means that if you aren't careful you end up with a program that doesn't run on all.
If you step back and squint, J2ME is handled exactly the opposite way that Java is handled. There are no standardized implementations you can deploy on, not even on PDAs, which would bring a lot of ideas and talent in from the developer community. This diametrically opposite effect explains why Java, which is so important in the enterprise, is a toy platform in the mobile world. You either develop for a specific device, or you develop trivial games that don't cause a lot of grief when they don't work cross platform.
It's not entirely Sun's fault, at least on the mobile end. Our de-regulated telecom model means that the wireless companies are gatekeepers between developers and consumers. However, the failure to extend Java to the PDA was a lost opportunity to gain momentum before PDAs lost ground to smart phones, and smart phones lose ground to closed devices like the iPhone.
Re: (Score:3, Interesting)
If you step back and squint, J2ME is handled exactly the opposite way that Java is handled. There are no standardized implementations you can deploy on, not even on PDAs, which would bring a lot of ideas and talent in from the developer community. This diametrically opposite effect explains why Java, which is so important in the enterprise, is a toy platform in the mobile world. You either develop for a specific device, or you develop trivial games that don't cause a lot of grief when they don't work cross platform.
Oh really? If J2ME is a toy platform, what is the real platform then? J2ME is deployed on billions of devices and it would be insane for any ISV to ignore that. Yes, the platform is balkanized and you have to perform a lot of painful compatibility testing to ensure that your software works on a wide range of devices. Exactly the same problem you would have had if you wanted to deploy commerical apps targetting GNU/Linux. And yes, write once run anywhere is a myth. But what is your alternative? The Windo
Re: (Score:2)
What is deployed on billions of devices? It is something that allows the same program to run unmodified on those same billions of devices? If not, it's not a platform.
My alternative would be two products, a CLDC sort of product and a CDC sort of product that (a) come from a single source, (b) are simple and convenient to buy/license in any size lot, (c) are avail
Hecl (Score:3, Interesting)
Also, for fun, I created a prediction market about which platform will domin
Re: (Score:2)
Programming J2ME is FUN with NetBeans 6 ;) (Score:5, Interesting)
Sun is snatching defeat from the jaws of victory; give it another few years and they'll have thoroughly destroyed the mobile Java market as well, just like they did with the Java desktop market.
There are several samples included: like sounds, graphics, basic networking, games. I recommend everyone who is interested in developing application for mobile devices to check it out
But if you already hate Java, then just stick to the Windows platform. It's also very good.
Re: (Score:3, Interesting)
I'm writing an OpenSource J2ME application as an hobby (shameless plug: http://jbit.sourceforge.net/ [sourceforge.net]) and I don't think J2ME it's that complicated. Its basic API (MIDP1) is very simple. Its second incarnation (MIDP2) is also simple. There are a lot of optional APIs, but I believe you can write interesting applications without them. Sure, if you want to use GPS, you need to use a specialized API and not every phone will support it. I think it's fair.
But this IMHO is missing the point. Are there any other
Re: (Score:2)
I hate to say it, but you must be new here. Or someone that has an active hand in perpetuating the current mobile Java soup.
So I say
Re: (Score:2)
Of course, I don't know what I'm doing; that's the point: Sun makes it too f*cking hard and confusing to figure out.
Oblig OpenMoko shill (Score:5, Informative)
And the Neo 1973 GTA02 hardware [openmoko.org] is looking to be pretty sweet. Includes 3D accelerometer, GPS, WiFi, Bluetooth, and touch screen (with rumor of enabling multitouch [openmoko.org] through a driver update).
Re: (Score:2)
Re: (Score:1, Offtopic)
Re: (Score:1)
Re: (Score:2, Interesting)
My Take (Score:5, Interesting)
1. J2ME. It's the Java you all know and either love or hate, but with a different library. Some things work the same way as they do on the desktop. Some things work differently. And some don't work at all. Generally, there will be differences from device to device. Lots of devices come with J2ME implementations. Developing tools are freely available. J2ME seems to be a relatively stable target.
2. Linux. It's Linux. In theory, it's the same as desktop, server, etc. Linux. You should be able to use the same developing tools and libraries, which are freely available. In practice, devices may have odd differences and limitations compared to desktops running Linux. Sometimes, vendors go out of their way to introduce incompatibilities. It's a mine field. The number of devices Linux runs on is limited, and the ones you can reasonably limited are fewer still. Although the core of the platform is stable, parts of it are very much moving targets.
3. Windows Mobile (formerly known an Windows CE and Pocket PC). Pretends to be Windows but isn't. The platform has odd limitations and restrictions that differ from version to version and from device to device. Developer tools are available, but not necessarily free of charge. It all depends on the target device, its configuration, and the version of Windows Mobile. In general, you will have to pay for developer tools, compile different versions of your app for different targets, and pay for signatures on some targets. Many devices come with some incarnation of Windows Mobile on them. The whole platform is a moving target, with incompatibilities introduced at about every release.
The way I see it, of the three, Java wins hands down. It's the only one that is actually workable.
I don't know where Vivek is coming from when he says ``I never thought that Windows Mobile would take the pie, but for a hobbyist programmer they offer the best SDK's and you can make applications without worrying about certificates while testing and debugging. With a windows mobile one really feels in control, if you want to screw up your mobile device its really upto you. One rarely feels tied down the API's are clean and functional. Getting your first demo program onto the device takes a few seconds. It just makes sense to develop for windows mobile. There is almost no need to get your applications signed, at least for testing.''
To me, it has been the exact opposite of that. It's a nightmare. It's a nightmare to figure out what you have to download to get up and running. You can compile binaries for th platform with various tool chains, including some (user friendly for me) open source ones, but they won't run on all devices, as they will be lacking the right signatures. If you do get your application signed (which is costly; you have to sign every version of every exe, dll, and cab), it won't work on older releases that don't support code signing. The platform is almost ridiculously limited, and limitations aren't consistant across versions (e.g. you may or may not be able to get at a given file using the file open common dialog).
I'm thinking Vivek just tested things using one device, and was lucky enough that it didn't throw a tantrum.
Re:My Take (Score:5, Interesting)
Personally I was put on the spot with no mobile device experience -whatsoever-, with a 2 weeks deadline to learn it AND deliver a tested, fully working and deployable (on customer devices) remote real time inventory management software su pporting most mainstream Windows Mobile enabled barcode scanners (I realise I'm not talking hobby anymore) with nothing but the lowest version of Visual Studio that supported it (which is incredibly cheap, especially since you can get an upgrade from virtually anything, including competing products), and I actually finished ahead of time.
Then by replacing the bits that actually used the barcode scanner with a stub, we were using my boss' cellphone to demo it to customer without any changes (beyond the one I just mentionned). That was pretty fun
Re:My Take (Score:5, Informative)
Hello, fellow Windows Mobile barcode scanner developer. I hate my life.
I hate the compact framework. It's got limitations everywhere that drive me nuts. It's a memory hog. P/Invoke is virtually required. Generics make jitting 10x slower, and it's already pretty damn slow.
I hate taking 4 minutes to deploy a multi-dll app using Visual Studio.
I hate debugger freezes that require soft-resets.
I hate how every device behaves differently.
I hate constant out of memory errors since the compact framework is a memory hog and the devices are all under-equipped.
I hate how CF 2.0 apps are compiled to be "hi-res aware" because Microsoft assumes that all of your controls are going to scale properly.
I hate the input panel and it's flaky behavior.
I hate Microsoft SQL CE. Poor documentation. Vague errors. Slow.
I hate having to deal with 3 different barcode scanning APIs from 3 different vendors that won't give me devices or up-to-date documentation.
Basically, the only reason I'm still doing this is because the other teams at my company are using VB6. I think I'd rather die.
Re: (Score:2)
there is hope, though - you can already make simple windows ce apps with lazarus.
Re: (Score:3, Interesting)
My quick take from a nightmare project about 8 years ago
Java : I actually believed them when they said "Write once, run anywhere". For me this became "Write once, run away". Ive not to
Re: (Score:2)
Yes it uses a lot of memory and it can be slow but when you know the limitations you can work around them. If you require optimal processor and memory usage, use C++ (but be aware that your development times might increase).
Deploying applications is quick after the Compact Framework has been deployed on the first run.
The debugger rarely freezes unless there is a connectivity issue. Disconnecting the
Re: (Score:2)
I develop applications for Symbol, Intermec and HHP devices using the Compact Framework and I really like it.
Congrats! :)
Yes it uses a lot of memory and it can be slow but when you know the limitations you can work around them. If you require optimal processor and memory usage, use C++ (but be aware that your development times might increase).
C/C++ is not an option for my company.
Deploying applications is quick after the Compact Framework has been deployed on the first run.
Deploying applications isn't "smart" when you have an app that dynamically loads modules. Maybe your app isn't as complicated as mine.
The debugger rarely freezes unless there is a connectivity issue. Disconnecting the debugger from a running application can cause the device to lock up (particularly if you are using some of the OEM libraries) but if you close the device application down properly, it is normally OK.
This mainly happens with HHP devices for me. And although it doesn't happen often, it happens often enough.
I don't get constant out of memory errors. Try and make sure all the resource intensive objects are wrapped up in "using" statements so Dispose is called on them when you have finished with them. In particular every file and form should be in "using" block.
Yea, I do that, I'm not a n00b. :)
It only takes about 30 seconds to rip out the hi-res aware code if you don't like it.
Please tell me the compiler flag that disables the HI_RES_AWARE resource. I actually made a program that runs after compile that rips out that resource... and then it didn't fix
Re: (Score:2)
Re: (Score:2)
What is this garbage doing on the front page? (Score:5, Insightful)
The author's few actual opinions about technologies are equally worthless; his rambling about Palm and J2ME makes it clear that he's never actually used the technology for more than a few minutes, and the ranting about Linux's license and the hassle of 'signing' applications makes you wonder if he's ever written any software at all. Someone who considers the Java Mobile API 'beyond him' probably shouldn't be writing articles about programming.
Ummm... (Score:1, Flamebait)
Thank You,
The Management.
Disappointing - this is needed information (Score:3, Interesting)
It may just say that the mobile space is really not targeting the hobbyist... should we change that?
If someone has actual experience in this, would much welcome reading it.
The "hobbyist" (Score:1)
While mobile phone companies may not care much for garage tinkerers, some of these "hobbyists" might actually turn into market opportunities. Imagine a company writing software normally targetted at PCs or embedded platforms. They could see an opportunity to port their stuff to mobile phones, but only if someone within that company has experience with this from tinkering at home or if entering into this field of programming is easy and painless, e.g. a linux based SDK which looks and feels like programming
Re: (Score:2)
hobbyist... should we change that?''
Hell yes! Imagine how cool it would be to develop apps for a hobby, and have yourself and your friends use them on your mobile phones! This is the scene where a little bit of programming effort can get you a hugely popular app, unlike the desktop space where you don't count unless you have spinning cubes and professionally designed lifelike 3d animated graphics.
It will be like the golden age of the home co
Blackberry is pretty good (Score:2)
If you know Java, the Blackberry platform is the simplest and most powerful platform you will find.
Best Platform for Hobbyist Mobile Development (Score:2)
Anybody else out there think that this was going to be an article about robotics?
Re: (Score:2)
No. You must be American. You call these things "cell phones". The vast majority of the rest of the English-speaking world calls them "mobile phones", or just "mobiles" for short.
HTH
Who got the Jelly? (Score:1)
I'm confused...
My experiences (Score:5, Interesting)
They wanted to get away from their usual approach of having to make a whole new custom system for each car project, so we made a custom hardware platform running Windows-CE that we could sell to different car manufacturers just by modifying the front panel and changing some of the graphics.
Anyway I just told you all that to establish my experience and tell you that porting CE to a custom platform and developing drivers etc. for CE sucks very badly compared to doing the same with Linux due partly to the poor documentation and lack of support from Microsoft, and also that CE itself and its APIs are very badly designed and structured compared to Linux.
Mobile Development Experience (Score:1, Interesting)
Re: (Score:2)
A lot of systems ran on m68k processors back in the days.
Unless You're A Web Developer (Score:2, Interesting)
You can make HTML+CSS+JS with any Unix to W3C standards and test in Firefox and your work will display beautifully on the iPhone or iPod, which also has an excellent HTML+CSS+JS debugger and Bonjour networking. Very low cost of entry, especially if you were going to buy an iPod or iPhone anyway, and the stuff you make also works on every Web 2.0 system. You can also include ISO MPEG-4 H.264/AAC media and you're compatible with everything, even Flash as of v1
Blackberry (Score:2)
The best one WAS the Sharp SL-5000D (Score:2)
Before that... well, it was probably the C-64.
Linux Vs Windows Mobile (Score:2, Insightful)
Whenever i need to do something on windows mobile/wince i never commit on a deadline because you don't know where will you get stuck with so many libs (without source code) around. Microsoft is not going to support you until you really mean something to them and windows mobile documents sucks.
Some point of time, I had to demo VoIP on wince. I plan to use wince messenger but it was returning 421(IIRC). I was using M$ SIP stac
Qtopia? (Score:2)
Bad journalism (Score:1)
Entire article is probably astroturf (Score:2)
He damns all platforms except the one he's pushing with faint praise, with every one having a show stopper problem. The one he's pushing is perfect, with no problems at all, which in the real world is bullshit.
And that's ignoring the fact that the entire premise is nonsense. Without knowing where the hobbyist programmer is coming from and what they're trying to achieve to claim one mobile platform is better than another is vacuous, the sort of content free nonsense that marketers push every day.
Another
Embedded Engineering (Score:3, Informative)
Creating a new device using WinCE or Linux. Advantage Linux
I've been to all the MS "Training" Tech seminars on WINCE and Mobile .NET. I've asked alot of questions. I usually bring a stack of questions with me because MS trots out "experts" at these things. I have only once received an answer to what I saw as a common question. I've seen countless Demos. I even tried it on two different devices. At first it all looks great but I quickly ran into problems that only peeking at the source can root out, which in many cases is not allowed.
Under Linux I get all the source I need (and then some) to understand the problem. I can turn to the community for help. And by community I usually mean the author of the code I'm having trouble with. I can reuse a ton of code. Hell, sometimes I only have to write a surprisingly small amount of code to accomplish what I need.
The hardest part I've found in developing Embedded Linux Applications/Devices is getting the boss to open the code (Not always necessary but I insist on it every chance I get).
Yeah VS integration is nice, but then I have to use Visual Studio, not something I like to be forced into. I have no problem using a variety of different tools and toolkits to get the job done on Linux.
I am quite fond of QT, and nothing beats the customization of the kernel. I can test on the desktop, cross compile and test on the device.
I've done Brew and a few of the others, I have no real interest in Cell Phone development though, so I can give no real opinion on how they stack up against the penguin.
MoSync (Score:1, Informative)
Support for Symbian and Windows Mobile, which allows you to use the same C/C++ codebase as for J2ME, is in the works.
There are also plans to show, at the Symbian Smartphone show in London [symbiansma...neshow.com] support for the Ruby language, as well as a graph-based visual programming tool called Mobile Author.
s60v3 and python (Score:3, Informative)
Its almost impossible to test the application without signing it.
Not true for s60 python scripts. You just copy them over and run them from the interpreter. Done.
Developing native applications is only for people who plan to develop free applications or for big organizations, getting a certificate for a free application can take weeks if not months. Its no longer seems like a platform for hobbyist programmers.
So, em, why this big imperative to develop "native" applications then? I thought python, perl, ruby, tcl/tk did away with the "native application" bigotry along time ago...
The python implementation for s60v3 is actually pretty clean. I seem to recall an article from one of the id guys (was it Carmack or Romero?) on the nightmare of developing Java ME apps, what with differences in implementation from one device to another.
Developing environement (Score:2, Insightful)
At an amateur level, J2ME is the best because is well documented, reasonable IDEs and free. It is not very powerful or fast, but it is simple and will do a lot of things.
At a professional level, Symbian and Windows CE/Mobile are the viable options. If you want to build a decent UI, get good performance and use decent IDEs and get lots of resources, that's the way.
Linux is the most promising new platform, but I tried to get into openmoko, as a useful hobby, but the development tools are a lot differe
I've done BlackBerry development (Score:5, Informative)
The biggest advantage of BlackBerry Java development, IMHO, is that the OS itself is practically a JVM, and the built-in apps are also Java. On most phones, running a J2ME app requires waiting forever for the thing to start and never integrate well. On the BlackBerry, your own Java apps start instantly and can look just like all the other built-in apps. Finally, BlackBerry is a common platform across a wide range of popular devices, so you'll always have plenty of potential users even if you build BlackBerry-specific apps.
And now for the shameless plug...
Back when I got my BlackBerry, I found that there were no decent available E-Mail clients for them. (only the service-based E-Mail, which stinks if you're not hooked to a corporate BIS server.) So, I kicked off an open-source project to write my own:
LogicMail - http://www.logicprobe.org/proj/logicmail [logicprobe.org]
Strange (Score:2)
The real criteria for a good hobbyist device? (Score:3, Informative)
1. Low cost of entry -- if the hardware is expensive or the toolkits are expensive, it's not a good hobby tool
2. Ubiquity -- if the hardware is hard to find or only three people have it (and two of them are in Zagreb) it probably won't build a good community of enthusiasts
3. Plentiful and understandable documentation -- if information on it is hard to find or understand, you wouldn't learn about it to start with
4. Uses languages I already know -- why learn something new?
5. Vibrant community -- you want to feel part of something interesting, most of the time
6. Easy tools to use -- good for the non-coder just-get-it-done-so-that-I-can-show-my-buddies
7. Good tools to use -- good for the uber coder who just-get-it-done-so-that-I-can-show-my-buddies
8. Simple distribution -- I want to be able to share my apps with my friends or the world.
9. Path from hobby to profession -- making a living out of it!
Under these criteria, I'd rank major mobile platforms this way:
1 - Java ME (Ubiquitous on even low-cost cellphones with low cost data plans, easy to learn, low cost if you already have the phone, tools are free and some are even good, documentation is available although mas-o-menos, distribution is reasonably easy in most cases, path to profession is clear although bumpy. Java is well known.)
2 - WinMobile (Ubiquitous -- getting a cheap PocketPC these days isn't difficult, easy to learn if you have the good tools -- thought a pain if you use the free tools, great tools although the best are expensive!, documentation is plentiful, distribution is generally easy as long as you're not trying to hit SmartPhone platform, easy path to profession), community exists but probably not passionate [I went to a winmobile developer conference and the folks there looked as excited as someone waiting for a colonoscopy].
3 - Linux (if you can find a Zaurus on the cheap, and are already a Linux coder or can pick up *nix thinking, it's a good platform for making some very complete applications. Development tools are ubiquitous but can be hard to figure out for the beginner, but the community will help you out through building makefiles. path to profession on mobile linux limited given small range of devices, unless you're a consultant). C is well known. Other platforms (Python, Perl, ROR) are available, though not sure about the mobile side.
4- Symbian (devices are ubiquitous in europe, coding for it can suck, distribution can be tricky at best, but there's enough community support that it may be worthwhile, although if I were a hobbyist I'd try different things. C is well known but the API set I've heard is miserable.
5 - BlackBerry (Easy to find devices although service can be expensive, tools are great if you don't need a visual IDE (visual IDE costs more overall because you need a Blackberry enterprise server + MDS), documentation is very good, community is animated though smaller, path to profession is clear. Java, XHTML, ECMA script are well known.
6- Palm OS (easy to find cheap devices, no services required, tools are adequate, documentation is solid, not exactly great for quick throwaway apps though. C and Java ME available
7 - BREW: BREW is designed to discourage hobbyists. The point is to make it so that mobile operators only have to deal with pros or companies that put money into the bucket.
Any other thoughts?
Re: (Score:2)
Any schmuck can download the SDK and play with Brew apps on the emulator, but only a company can get the access you need to run apps, even for testing, on a real device. I think this is a shame; Brew does some genuinely interesting things.
(Yes, I do Brew for a living. I can (and do) run apps on real devices on real networks.)
My c
Best Hobbyist OS != Best OS (Score:2)