Mobile Web. J2ME is a walking ghost at this point due to the fact that fragmentation has made it a nightmare to even target anymore.

Why go through the hassle of having multiple builds to target dozens of devices (fun fact: the shittiest feature phone per carrier is usually the top priority phone that Java ME devs must target), and having to water down said app for the lowest common denominator phone? Mobile Web keeps most of the business logic on the backend with scripts taking care of that stuff, all they have to do is make it look nice on the feature phone's browser.

That and the fact that the carrier's testing requirements are notorious for being harder than Chinese Algebra, since I started my career working on J2ME apps, where at times, we would target up to 60 phone per carrier for each app, so there was a lot of corner cutting and scaling down to the point where we were trying to polish a turd.

With Android and iOS, the scope of fragmentation is very narrow since the OS is very consistent across the board, in other words, no half-assed implementations. The point is moot for iOS since it's rock solid.

Bottom line, J2ME won't be number two for that long, lots of folks' contracts will be up this year and with smartphones being offered for next to nothing, they'll start bleeding profusely by year's end.

Let's just say that my Bachelor's Senior Project produced my code samples, which in turn got me my start in the mobile software development industry a month after graduation five years ago. Even then I was still able to produce code that enhanced my skills outside of work (yay for iPhone to Android ports). So far, now that we're trying hire more iPhone and Android devs at work, I'm always asking for and reviewing prospective candidates code samples before we can even consider them for interviews.

For me, when I graduated college two and a half years ago, I went into the job market with not experience, but with code samples. If you're starting out at entry-level and wanna have a damn good chance of getting the job, you gotta have an app of some sorts that you can demonstrate to potential employers so they get a better idea of your programming style and whether you were able to apply the concepts that you learned to that said app.

The way I managed to get my code samples was through my Senior Project, in which I wrote two J2ME demo games for two different handsets (both MIDP1 and 2). One month after graduation, I interviewed for a mobile game developer and had my samples on hand to give to the employer. As a result, I was hired by them shortly thereafter and managed to hold on to that job up until early last year when I was let go. Even after that, I still had connections to the mobile industry and I was taken care of with more work up until last summer, but at least I came away with experience and contacts, something valuable in this economy. Without those code samples, God knows where I could of ended up, probably doing code for some dodgy come and go Hedge Fund, but the fact remains the same: just like artists have samples of their work, so should software engineers. said app.

Also, OP should broaden his search and not just focus on IT given the state of this dismal economy. In other words, build up your digital portfolio to showcase to employers when interviewing for whatever entry-level software engineer position matches your skills. The important thing right now is to get your foot on the door and pop your cherry with some professional experience. Best of luck to you in this fierce job market.

See, I used to work within the depths of the mobile apps industry, so I pretty much have first hand knowledge of this sort of info. For example, when I worked for this dev that primarily worked on games and personalization apps for cellphones, most of the time, we went straight to the carrier to get our apps on the "deck," which is industry slang for the carrier's applications store that you access from your phone, hence we had business relationships with the major carriers. However, when that company first started out, it had to rely heavily on publishers, which in turn busted their balls in terms of QA'ing the apps to meet the dreaded carrier requirements.

When I was over there, I had to work with this publisher called Airborne for supporting one of our flagship games on AT&T. We tried our best to essentially cut them off completely in order to go direct to the carrier instead, but like the parasites that they are, they were ready to turn the tables on us and affect already live builds out on the market by killing off our subscription based system that is at the heart of the game in question. So we had no choice but to stay with them and put up with their piss poor staff that were in my honest opinion, some of the shittiest QA testers I've ever worked with, always reporting non-issues thinking that they are showstopper bugs, hence they held back submission to the carrier due to false alarms.

On the other hand, there are times you will need publishers since some of them hold the necessary digital signatures necessary to use certain MIDP API's locked out by the carrier. Case in point: T-Mobile, which requires THEIR very own digital signature to use the network on a J2ME midlet. Problem is: that sort of sig is only given out to big time mobile distributors and developers, so a person like you for example that runs a small time operation will have to rely on a publisher. What's worst is that when I worked on T-Mobile builds, I also had to work with Airborne and constantly send the builds to get signed in order to run it on the phones, and that would either take hours, or in some cases, days to get back fully signed, further slowing down the development process.

Long story short, take your game directly to the carriers, cut the middleman, I say again, bypass him. Your game is near completion right, so surely you can easily whip up a demo that you can present to the carrier's product manager, and garner enough interest on their end to establish a business relationship with them. You're better off showing it to AT&T first since they're the largest J2ME phone carrier in the country, and most of their MIDP API's aren't locked down like the ones you need to playback video and sound. However, you're going to have to invest some money into things like digital signatures and more handsets to test it on, since once you get your foot through the door, they're going to want you to port your game to high priority devices like the RAZR and the low end LG's and Samsungs, so you have to make sure that your code is scalable to support these crappy, but high selling handsets. If I were you, I would just pool up some money to get yourself a few phones off of eBay, like a Moto RAZR, since the install base on AT&T is in the tens of millions, and a tiny screen phone like the LG CG225, which is slow as hell and has Jar size limits, but like the RAZR, is more prevalent among customers in the network. Pro-tip: the shittiest phones sold by AT&T are always the ones on the top of the priority list. Basically, the easy part was creating a working app, the hard is yet to come, where you have to port your code to various other handsets, which will mean different screen sizes, speed, and heap memory available, plus the bugs associated with them.

However, if you want to take the independent route, you could also try a site like hovr.com for example, which provides free games to users, but the devs get a cut of the ad revenues. Still, you would have to invest on at minimum a digital signature to ensure that your games are completely immaculate and not tampered with, which will set you back about $400 annually, plus some more phones so that your game can run on multiple devices. Hope that helps you in trying to get your game out there to the masses.



P.S.: Some phones like Samsungs and LG's only install apps over the air, and not through data cable, so make sure you have a line with a pretty hefty data plan.