Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open J2ME Development Options?

Cliff posted more than 8 years ago | from the write-once-run-anywhere-...really dept.

Communications 32

loganb asks: "I'm currently holding in my hand a brand new Samsung A900 cell phone with a brand new EVDO data plan. I was initially excited about the OSS/free application development possibilities, as the J2ME stack on this phone supports the new Media, Location, and Messaging APIs. Much to my dismay, however, Sprint (my carrier) locks all the interesting APIs up tighter than a drum, and makes it nearly impossible to get an app to market. You need a $400/yr Verisign certificate just to download an app to a developer-enabled phone and you need a contract with Sprint to receive the certificate necessary to distribute the app (solely through Sprint's online store) to regular users. Of course that is not really an option for free/OSS programs, 'vertical' applications, or anything that doesn't neatly fit into Sprint's business plan. Thus, do any of the other national domestic cell providers allow unfettered access to the Java APIs on their phones? Is there any sort of hackery (such as buying an unlocked phone from Europe and using it on a domestic GSM network) that has an equivalent result?"

cancel ×

32 comments

You can still return your phone and cancel Sprint (4, Insightful)

antifoidulus (807088) | more than 8 years ago | (#14697657)

if you got the thing less than 14 days ago. The law gives you 14 days to cancel if you don't like your service. As for unlocked phones, you don't have to import one from Europe, amazon sells them, as do a lot of other places.
Personally i would recommend T-mobile(since they are actually a European company!) and have fun!

You can buy software that unlocks phones. (1)

Futurepower(R) (558542) | more than 8 years ago | (#14697930)

Google for unlocking software [google.com] . There are companies that unlock phones for $15, too.

T-Mobile unlocks phones for you without charge after 3 months of using their pay-as-you-go service.

--
Before, Saddam got Iraq oil profits & paid part to kill Iraqis. Now a few Americans share Iraq oil profits, & U.S. taxpayers pay to kill Iraqis. Improvement?

Re:You can still return your phone and cancel Spri (1)

vsync64 (155958) | more than 8 years ago | (#14701230)

Personally i would recommend T-mobile
Yeah, and have fun when their first reaction to any customer service issue is to cancel your account and send you to collections.

buy a unlocked phone (3, Insightful)

johnjones (14274) | more than 8 years ago | (#14697698)

plain and simple buy an unlocked gsm phone and buy a sim card

dont put up with suppliers that will not allow you to run your app's you should at least be able to download your app to the phone via a usb cable

the location and photo API's do seem very fun I have not tried them out and wonder how much is cross platform...

regards

John Jones

Nokia 6265i or Siemens S65... feedback ? (2, Interesting)

johnjones (14274) | more than 8 years ago | (#14697737)

try getting a Nokia 6265i or Siemens S65

both have the location API how well it works I do not know anyone know ?

regards

John Jones

Re:Nokia 6265i or Siemens S65... feedback ? (1)

(H)elix1 (231155) | more than 8 years ago | (#14698490)

Another option is a blackberry. Not only will they give you the dev kit, but also a collection of emulators. Great if you are coding Java.

Cryptographic signing is not strictly required (3, Informative)

CTachyon (412849) | more than 8 years ago | (#14697811)

Things might've changed since the merger with Nextel, but AFAIK there's nothing keeping you from distributing unsigned Java apps from your own company website. The user's phone will pop up a warning, of course, but it won't stop him/her from downloading and installing your app. Assuming you know all about JAD files and MIDlets, just point the user at the JAD file.

My biggest beef with Sprint is their crappy API support, at least on their older phones (my Sanyo PM-8200 supports only MIDP-1.0, and very few of the optional J2ME APIs).

Re:Cryptographic signing is not strictly required (1)

LWATCDR (28044) | more than 8 years ago | (#14709304)

I was wondering about that. I downloaded Google local for my a900 and got a little warning message. Works fine for me except that Sprint doesn't let the access the GPS on the phone.
It looks to me as if homebrew development is possible.

Sprint is an unusual case (1)

Zigurd (3528) | more than 8 years ago | (#14697928)

Sprint is an unusual case in that they use use J2ME for mobile applications on a CDMA network. Most network operators using CDMA use Qualcomm's BREW application environment. So you have less choice among handsets for J2ME software development if you choose the Sprint network.

There is nothing second-rate about Sprint's handsets, but they may not be the best choice for individual developers getting into J2ME development.

In my experience, Nokia, Motorola, and SonyEricsson have well-documented J2ME implementations. In the U.S., you can use GSM handsets from these manufacturers on the Cingular or T-Mobile networks.

The price of signatures is unfortunate. You should check both the handset manufacturer's and network operator's policies before making your choice.

Good luck!

Phone companies want total control (2, Interesting)

Mr. Shiny And New (525071) | more than 8 years ago | (#14697973)

It's my experience, after working on a mobile-phone app that uses SMS, that phone companies are paranoid control freaks.

Some companies won't allow certain kinds of applications on their networks; for example, Verizon won't allow any applications where users can meet other users. Some companies won't allow any applications where users can chat (say, via WAP or SMS) with other users unless the chats are moderated. BY A PERSON. Some companies require that, if you plan to advertise your application, and your adviertising budget is over a certain ammount, you must disclose to the carrier your entire advertising budget and campaign.

Frankly I'm not surprised that Sprint doesn't want you writing software for their phones unless you pay them big bucks. Telcos are almost worse than banks when it comes to new ideas (or software).

I can't wait for the one telco that gets it right, and provides an environment where creativity can reign free; someone will develop a kick-ass application for that carrier's phones, everyone will flock to them, and the other carriers will finally get a clue.

I understand that in most European countries the situation is very different. In Norway, I hear, you can basically write/distribute any app for a phone, and the telcos only bother you if they get complaints about you. That's what I'd like to see in North America.

If telcos had invented the Internet... well, it'd be AOL.

Re:Phone companies want total control (1)

jonwil (467024) | more than 8 years ago | (#14698881)

Just get a no-restrictions GSM phone (even in america, getting a non-carrier phone is easy enough I believe) and a SIM card from the carrier you want and then develop away. No need to sign anything. There are probobly still APIs that you cant talk to but generally those APIs are private for good reasons (do you really want arbitrary java apps being able to read your phone book or download images (e.g. porn) and store them in your phones picture storage area?)

Re:Phone companies want total control (1)

Mr. Shiny And New (525071) | more than 8 years ago | (#14701377)

Well, in my case, it's not about developing a java app for the phone itself, it's actually an application that uses SMS messages as its user interface. So the application runs on a server, and communicates with the user through SMS messages. I can develop it for free, using an emulator, but in order to be able to bill a user I need to sign a contract with the carriers, and the carriers have rule lists that make insurance contracts seem like children's stories.

Re:Phone companies want total control (1)

grumling (94709) | more than 8 years ago | (#14699515)

I can't wait for the one telco that gets it right, and provides an environment where creativity can reign free; someone will develop a kick-ass application for that carrier's phones, everyone will flock to them, and the other carriers will finally get a clue.

Have fun waiting. Here [google.com] is a helpful link. The telcos in the US actually think they are hip deep in competition, even though all they pay attention to is talk time and price. Since telecom tends to be a closed system when it comes to employment (and education), and the first thing a new feature has to do is make it through the call center scripts easily, you won't see anything new come out until it has been completly sanitized and made (mostly) useless. That, and the cell phone companies are very worried about you stealing service and listening in on other calls.

What needs to happen is a disruptive technology, like WiMAX, but the buildout of the infrastructure will be high for "carrier class" service levels, and Qualcomm, Motorola and the gang are so intrenched in the handset market, that I doubt we'll see any big changes for at least the next 10 years.

Samsung A900 (1)

Chapium (550445) | more than 8 years ago | (#14697995)

I've got this phone and I, too, would like to unlock some features. Namely the use of USB for anything besides mp3-player songs, images, and vcards. In order to place ringtones on the phone you must upload it to the internet and then redownload it to the phone. The phone comes with a USB cable and supports the mass storage device protocol, but is crippled. ARGH!

Re:Samsung A900 (1)

AlphaWolf_HK (692722) | more than 8 years ago | (#14698610)

I use Sprint too, but I got the Sanyo MM-9000. It has all of the features of the A900 and the RAZR, plus it allows you to upload MP3, AAC, MPEG-4 video, and image files to its minisd port (which supports up to 2GB minisd cards) via the USB mass storage protocol, so it is driverless. Then you can move those files into the phones internal memory (through the phone's UI) for use as wallpapers, ringtones, etc.

The only thing the 9000 doesn't have is the buttons on the front of the phone so that you can rewind or fast forward the audio while the phone is closed. It does allow you to play, pause, and skip to the next song while the phone is closed though.

This is what we keep warning about (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14698176)

A few of us keep saying users and developers should be concerned about things like Palladium and so called trusted computing. This is an example of the real-world effects. Today cell phones, tomorrow PCs.

Sprintusers.com (1)

Xygon (578778) | more than 8 years ago | (#14698489)

Sprintusers has a utility for uploading your own applications, as well as a quite active userbase doing everything from development to featue discussions. Try your questions there, and utilize their utilities for uploading images, applications, and more to your phone, if you want. Just a huge forum board, nothing more.

Check out some of the uploaders (2, Informative)

aschneid (145265) | more than 8 years ago | (#14698594)

As stated above, there are plenty of uploaders out there that will allow you to upload your own programs. http://rumkin.com/tools/sprint/ [rumkin.com] is an uploader that will allow you to upload your own code (works with the A900...I've got one too). http://www.sprintusers.com/forum/ [sprintusers.com] is the forum mentioned above that have a lot of Sprint phone user geeks...I'm sure a lot of people on there could help answer your questions. Here's a link to their page for alternate uploaders too: http://www.sprintusers.com/forum/showthread.php?t= 83030 [sprintusers.com]

Additionally, http://www.howardforums.com/ [howardforums.com] has a lot of good information too. Here's an actual http://sprintdevelopers.com/ [sprintdevelopers.com] Sprint-centric development site too.

Although, most of this may be useless, because I see in this post http://www.sprintusers.com/forum/showthread.php?t= 52772&page=1&pp=15 [sprintusers.com] what you are talking about regarding the Verisign cert. You can run your own code, but to access the GPS stuff you are restricted. Hopefully someone in the above forums can help you out to bypass it. I'll keep an eye out, because that sounds like some pretty cool hacking to do.

Re:Check out some of the uploaders (2, Informative)

aschneid (145265) | more than 8 years ago | (#14698621)

As a matter of fact...here's a post on the SprintDevelopers.com forum discussing this...http://sprintdevelopers.com/article23.html [sprintdevelopers.com] Looks like the Sprint implementation (or actually Qualcomm's QJAE) for midp 2.0 (what's on the EVDO A900) doesn't work right now anyway....Course it looks like that is an older discussion so it may be live (but I cannot get Garmin or TeleNav to work on my A900).

Unlock the phone (1)

mpesce (146930) | more than 8 years ago | (#14698723)

For most phones from most providers, there are techniques available (Google for them) which allow you to re-flash your phone with firmware which is not completely locked up by the carrier. The manufacturer provides a full suite of features, then builds custom firmware for each carrier, basically subtracting features from the overall set.

I encountered this problem with SonyEricsson phones (first a K700, now K750), which were Vodafone branded, and wouldn't play the custom MP3 files I'd created to use as ringtones. I reflashed the phones, and voila, they play. Vodafone doesn't lock down the OS, however, so whatever J2ME programs I write [webearth.org] I can install and use on my phone.

I think you may want to take a look at a new carrier.

Copyright Office rulemaking proceedings (3, Informative)

MCRocker (461060) | more than 8 years ago | (#14699757)

Well, you missed the deadline for making comments [copyright.gov] to the "Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies [copyright.gov] " proceedings that the Copyright Office is conducting. Too bad. I'm sure your comments on this issue would have been more useful than mine were.

Perhaps you could still contact the Stanford Center for Internet and Society folks who were spearheading an effort to collect comments on cell phone locking [stanford.edu] and they could use your comments as an addendum or something.

Shout out to Lessig for his blog entry [lessig.org] that pointed these folks out to me.

You don't have to rely on Sprint. (1)

digerata (516939) | more than 8 years ago | (#14700179)

You can distribute the binaries yourself. All of the hurdles you spoke of just allow users to purchase the program from Sprint's website that is pre-bookmarked in all new phones.

If you ask me, its not worth it. People still have the ability to access other websites, so it becomse a matter of informing them about your software. I have a Treo 650 and just about no one goes through Sprint to download new software.

J2ME development issues (5, Informative)

happynut (123278) | more than 8 years ago | (#14701080)

I've read through the comments; I thought I would put in my 2 cents.

Several folks pointed out that you could get the midlet (the term for the type of app sprint runs) on the phone by hosting it yourself or downloading via a cable, and bypassing Sprint's site and the need for a developer's certificate.

They are correct, but they are also missing part of the story.

They part they are missing is: in order to use some of the APIs on the phone, your midlet must be "blessed" by the operator. Technically it has to say the protected features it wants access to and be signed by the manufacturer or operator. All this is covered in the MIDP2.0 (JSR-118) spec [jcp.org] . I was a member of the committee that wrote that spec.

So, if you want to write a local game you don't need any of that magic: you can do everything you want via the "untrusted" (that is: unsigned) profile. But to do some of the more advanced features (like using GPS data, or being able to be woken up when not running - push registry) you have to be signed by the manufacturer or operator.

Anyone who's read to this point will probably have noticed that the folks who make the phone or sell the phone (manufacturer or operator) are able to bless applications, but the folks who bought the phone cannot. This wasn't an accident.

When the committee was working out the details of the protection model manufacturers and operators were well represented. The only third party developers present were companies that were beholden to operators. There were no end users or corporations represented, so their interests didn't get a lot of weight.

I don't think it was evil intent by any of the parties. Its just that went these standard committees meet each representitive makes sure their interests are protected, and those who aren't present don't get a voice. This is a very common problem for most standard committees; its not unique to the JCP or MIDP. But it does help to explain why you, an 3rd party developer is a second class citizen even for your own phone, let alone your customer's phones.

Re:J2ME development issues (1)

vsync64 (155958) | more than 8 years ago | (#14701287)

This leaves only one question to be asked:

Were you a voice for the end user?

If not you are as culpable as the rest -- more, in fact, because you have demonstrated a clear understanding of the situation -- in working to circumvent the rights of the customer to use their own property.

If not you are an enslaver of your fellow man and a traitor.

Those of us in positions to advocate against the encroachment on fundamental freedoms have a sacred duty to do so. Technical knowledge and its associated power comes at the cost of responsibility.

Re:J2ME development issues (3, Informative)

bateleur (814657) | more than 8 years ago | (#14701795)

I see what you're saying here and doubtless would've said the same myself ten years ago.

The reality is that Java mobile standards are horribly mired in politics. Whilst you might think that sidestepping all that nonsense would be a good thing, the bizarre truth is that experience has proved that to be wrong. Look at the original MIDP-1 standard. It was a pretty simple thing, even underpowered, yet still a great many devices shipped with MIDP-1 implementations which were not properly compliant. Almost as bad was the fact that many shipped with proprietary extensions. The standard was a commercial disaster for application developers because it was not actually standard at all. The people who mattered did not fully back the standard.

MIDP-2 is much better than MIDP-1 was, but still the same problems of weak implementations plague application developers. In an effort to keep this post impartial I won't name names, but the difference between the best and worst implementations is massive not just in terms of performance but in terms of compliance to spec. Sun's compliance tests are ridiculously ineffective.

Mobile apps desperately need proper standardisation to really thrive. Currently only large developers with the deep pockets necessary to port, test and distribute to multiple platforms can make any kind of money. Creating a good standard involves an awful lot of politics. Simply knowing a requirement exists is not enough to get it acknowledged. In my view, better a slightly flawed standard than no standard at all.

(In case anyone's curious, I speak both as a developer of Java MIDlets and as a member of the development team for a well known MIDP-2 implementation. My opinions are my own and not those of my employer, just in case anyone can work out who they are.)

Re:J2ME development issues tsarkon reports (0)

Anonymous Coward | more than 8 years ago | (#14703584)

I've read through the comments; I thought I would put in my 2 cents.
Knowing what comes next, it is not worth that much.

Several folks pointed out that you could get the midlet (the term for the type of app sprint runs) on the phone by hosting it yourself or downloading via a cable, and bypassing Sprint's site and the need for a developer's certificate.
This probably already does or will in the near future be illegal. Because people like you advocate a terrorist government run by people crushing corporate juggernauts, "getting around" protections will land us all in jail. It is strange that you see nothing wrong with the first steps in this direction. I'm a big capitalist and a gun owner, and people like you want to enslave me starting with my phone, then taking my gun, then throwing me in jail for misusing my telephone.

They are correct, but they are also missing part of the story.
You are missing that you blindly advocate companies having secret sauce that could kill you. DWIs are decided by machines with closed source code. With people like you at the wheel you would mix Judge Dredd and the Termintor T-1000 into the same being, close the source code. In order to kill they would get the laws downloaded to them via signed certificate and the judged would be killed and they would never know why. This is okay with you.

They part they are missing is: in order to use some of the APIs on the phone, your midlet must be "blessed" by the operator. Technically it has to say the protected features it wants access to and be signed by the manufacturer or operator. All this is covered in the MIDP2.0 (JSR-118) spec. I was a member of the committee that wrote that spec.
If you wrote that SPEC, fuck off and die. You god damn anti people pro corporate death. Another standard Sprint uses is sucking shit and ripping off customers and getting away with it. You are a part of that. Scum.

So, if you want to write a local game you don't need any of that magic: you can do everything you want via the "untrusted" (that is: unsigned) profile. But to do some of the more advanced features (like using GPS data, or being able to be woken up when not running - push registry) you have to be signed by the manufacturer or operator.
It is my fucking phone. I own it. If a cat sneezes on it they void the warranty, so I should at least be able to use the fucking thing.

Anyone who's read to this point will probably have noticed that the folks who make the phone or sell the phone (manufacturer or operator) are able to bless applications, but the folks who bought the phone cannot. This wasn't an accident.
Fuck you then. I hate you and the operator for sucking. I know what this is. You made living thinking its okay to charge dumb-asses for applications that should cost next to nothing or be free. The problem is, you exploitative fucking asshole, that they will borrow money and go deep into debt and become a social liability. When there are roving marauding bands of starving zombies after total economic collapse brought on by you exploitative scum, I will laugh as they tear you apart for meat for sustenance, and you will turned into the shit you are via their digestion.

When the committee was working out the details of the protection model manufacturers and operators were well represented. The only third party developers present were companies that were beholden to operators. There were no end users or corporations represented, so their interests didn't get a lot of weight.
No corporations represented? Yeah right. And this is the best, you fucking admit that you made decisions without any end user advocacy. You are the quintessential asshole of the year, and you painted yourself black.

I don't think it was evil intent by any of the parties. Its just that went these standard committees meet each representitive[SIC] { representative } makes sure their interests are protected, and those who aren't present don't get a voice. This is a very common problem for most standard committees; its not unique to the JCP or MIDP. But it does help to explain why you, an 3rd party developer is a second class citizen even for your own phone, let alone your customer's phones.
I like mister standards man here cant even spell. Drunken idiot making standards without regards to end user's though or desires, despite they pay money for this shit.

You are a traitor to a free world and you should be summarily shot by an angry crowd. If I put you in certain places and told the world of victim cell phone users what you have done, you would get "stoned" by phones - everyone hates people like you.

FOAD

Re:J2ME development issues tsarkon reports (1)

LarsWestergren (9033) | more than 8 years ago | (#14731121)

Looks like someone forgot to take his medicines this morning, hmm?

If you don't have medicines, you should get some. Seriously.

Buy a hackable phone (2, Interesting)

a1291762 (155874) | more than 8 years ago | (#14702031)

I got a Motorola V220. The V-series is very hackable. In fact, even though it's not supposed to work, I can upload Java games directly from my Mac using some open source software (moto4lin). It's much simpler than the official way Motorola wants you to do it. I can even "backup" any Java apps I choose to purchase.

I do my J2ME compiles against the Motorola SDK (I had to borrow a Windows machine to get the jars) using mpowerplayer for the preverify/local testing. Then I just upload the .jar file, reboot the phone and I'm running on the device. About the only thing missing is local testing of Motorola-specific APIs but so far I've just avoided them. If could always fire up a Windows box to run the Motorola emulator on.

I'm not so concerned about other people being able to access Java apps that I write so I haven't even thought about that part. My operator (Virgin Mobile) doesn't even let me connect to the internet (just to their site, which has nothing useful that doesn't cost money) so even if I could setup a server that'd let people download my jars I'd have no way to test it.

Get a provider that is willing to give you freedom (1)

santiago (42242) | more than 8 years ago | (#14704802)

When shopping around for a mobile phone, my #1 priority was that I have control over the device, not the company. I'm fairly happy with my combination of an unlocked Nokia 6682 and a separately purchased unlimited data plan from T-Mobile. The phone itself runs the Symbian OS and supports J2ME applications as well as native ones, but most importantly lets me do whatever I want on it, without having to jump through hoops and being trapped in a walled garden that charges you $2 for a stupid GIF or a MIDI file.

In the US, you're really only going to have that degree of freedom with T-Mobile (and possibly Cingular, but their customer service is reputed to be abysmal, plus their data plans cost a fortune). All the others insist you play by their rules. If you want a flexible smartphone, though, you'll have to buy it yourself and sign up for a plan without any incentive discounts on the hardware, as T-Mobile's phone offerings are rather limited. (They used to have better ones, but they narrowed them down last year for some reason.) Be aware also that T-Mobile's network is substantially less robust in terms of coverage than some of the other providers available, though, on the plus side, it's GSM so you can take your phone internationally and have it work (though possibly at ludicrous rates, depending on specifics).

A reply from Sprint App. Developer Program (1)

juanfe (466699) | more than 8 years ago | (#14770759)

I manage Developer Platforms and Support for Sprint so I think I may have something to add here. (Apologies for the length, but there are a lot of very valid points raised in this thread that I'd like to address.)

Preamble: My personal philosophy or Where I'm coming from or My Role At Sprint

I've posted on the general topic of openness to developers [slashdot.org] before. I've been a software developer, both as a dabbler and as an employee for both startups and established companies. I've been involved in wireless developer programs for years now, and approach my job at Sprint from the perspective of the ousider more often than from that of the insider. I know that a development platform without both good developer support and a critical mass of passionate developers is likely to end up in the cool but unused [wikipedia.org] the esoteric and unusual [wikipedia.org] or the abandoned [wikipedia.org] bins of history.

That's a philosophy that those of us in Sprint's Developer Program share and spend a lot of time preaching within the company--without a developer community, we'd be nowhere, and without continuing to invest in making it easy to adopt our phones and network, we'll lose what we've gained.

Sprint's Approach to Developers: Dabblers, Hobbyists and Professionals

That said, the "open to everyone, information must be free, hobbyists rule" philosophy isn't necessarily one that is immediately embraced within a large wireless carrier with multiple people with different opinions that they can defend. By and large, as I've said before, wireless carriers are in a different world than that of straight operating system vendors:

  • We don't build the operating systems or platforms: instead, we work with device manufacturers and platform providers to find cost-effective ways of delivering a broad set of device and network capabilities within the constraints of time and money required to implement.
  • We fully own our networks and must ensure that they, and the customers using them, are protected and that we meet our service obligations to our customers. This is not the collective-sharing-we-each-pay-for-our-onramp-and- give-each-other-access-through-our-network model of the early Internet.
  • Customers see our primary role and business as voice service, and while we continue to invest in expanding data services, my humble not-necessarily-that-of-Sprint-or-its-affiliates view of the world is that customers will continue to see our primary role as voice for many years to come. This also means that as a rule, wireless carriers will tend to defer to voice requirements on their networks (and they are the carriers' networks, make no mistake about it) pretty much all the time.
  • The reason why most carriers encourage developers to adopt the platform is not so they can push additional bits through the network; it's so that they can offer additional services that customers will be willing to pay for and that developers can make money from delivering.

What this means is that wireless carriers will pretty much always defer to developers that are likely to build real, marketable software, because ultimately those are the ones that will be able to offer those additional services.

For some carriers, the calculations above have had the end result of limiting the availability of tools and such only to "vetted" developers (using whatever criteria they deem appropriate). Other carriers have opted for more openness. While I'd love to be able to say that Sprint is better than most in this regard and that we open everything, we're not an exception to market forces or social dynamics--some tools or functions end up being limited to only some developers for various reasons. Part of what our Developer Program does is work to systematically reduce the number of these limited tools to only be those that mean uncontrolled cost or major security or network liabilities.

What does this mean to the hobbyist or dabbler or even burgeoning entrepreneur? Yes, it can sometimes mean the frustration of buying the cool new device with features that, when digging under the hood, are not exposed to third party applications easily. Or it can mean that a great idea for the next Major Revolutionary Widget gets trumped by the Catch-22 of "you can't have access because you don't have a business because you don't have access". And it obviously doesn't work well for those looking to launch OSS or free software. Or it can just mean that it becomes such a pain to do something that should be simple that people give up or go elsewhere.

But there are alternatives that can make these work!. In fact, we've launched Open Source initiatives [sourceforge.net] in the past ourselves. If you do find yourself in such a spot where you can't do what you want to do, do yourself a favor and Contact us [sprint.com] and really let us know what you're trying to do and why, and we'll do our honest best to figure out how to get you there. For all of these restrictions, we have tools to mitigate their limitations and are willing to do whatever is in our power to help.

But do us a favor in turn and give us a chance to help you--don't just write to us and tell us that we suck or that we don't get it or that we'll be sued for being duplicitous or that h@xx0rs will pwn us. It is up to us to prove to you that we get it, but we also know how to use the Delete key. Work with us, realize we work within a very large corporation where we don't always make the decisions, and we'll work with you. Those [telenav.com] who [aircharge.com] have [enterprisej2me.com] find that we're willing to help and get them there.

The Whys of Requiring Signatures for Use of Some JSRs devices or Why limit access to developers?

On to the specifics about the Samsung A900 and other CDMA devices and why certain JSRs [sprint.com] are restricted on CDMA devices on Sprint's network. Firstly, you can build a MIDlet, put it on your web server, and download it to any Sprint CDMA device by pointing the WAP browser to it--provided that it doesn't use certain privileged APIs. That is, unless you're using those APIs, you don't have to get involved with us at all. Secondly, I've sat through many of these discussions internally and I can tell you in all honesty (believe me if you care to) that I haven't at any point heard someone justify any of these restrictions based on the "we must close this so that developers have to go through us" philosophy.

(As an aside, and frankly, as anyone in the mobile games industry will tell you, even when phones are very wide and open for any applications to be installed, very few applications are ever sold directly by the vendors--about 1% or so. Most average users buy stuff for their cell phones directly from carriers because it's frankly easier to find since it's all in one place.)

So let's take these APIs one by one to explain the story:

  1. JSR 120 WMAPI: sending text messages from a phone has a cost to an end user. If this JSR were not restricted, a user pointed to a MIDlet through a text message with an embedded URL could theoretically install a MIDlet that sends text messages without the user's awareness, which has cost implications. Notification that a MIDlet is going to send a text message is insufficient, unfortunately: poorly or maliciously coded MIDlet could use social engineering to gain permission from an unsuspecting user (e.g. MIDlet brings up a nuisance dialog box repeatedly and endlessly hoping that when the real message authorization message comes up the user, fed up, will just click OK). Yes, may be a far-fetched scenario in volume, but when you combine that with the fact that SMS SPAM is a growing concern overall, the people within the company that worry about such things have a case in their favor that's hard to argue against given the proliferation of email-bourne viruses on the wired Internet.
  2. JSR 134 MMAPI: This API, amongst other things, allows a MIDlet to stream media. This poses two possible concerns: network capacity overload and copyright infringement. The first is important, because streaming eats up network in ways that other data transmissions don't, and network capacity is always a concern. Voice is generally prioritized over data, but that doesn't mean that high data usage can't theoretically block off voice in certain near-capacity situations. Regarding copyright infringement--I don't want to get into a discussion of the virtues of P2P or whether or not it's a carrier's role to enforce the law, but suffice it to say that enough people, including our attorneys and our content providers who own copyrights, are concerned about that to make their message very strong.
  3. JSR 75 PIM: Personal Information Management access--contacts, phone numbers, calendars, etc--not something anyone wants to expose to just any old MIDlet. Whether it's fair or not, our less-tech-savvy users expect us to ensure that their information is protected, and we could argue that if they downloaded a MIDlet on their own they should know better, but again, think of the rash of attachment-based Outlook Trojans and you'll see why just about everyone's in agreement here.
  4. JSR 179 & OEM Location APIs: Location is a tricky one. The APIs themeselves don't require signatures, but getting the SDKs and tools with which to compile apps that use them on CDMA phones require additional approval. Nextel historically opened up the GPS APIs on the phone to anyone, and the only requirement was a phone-triggered privacy consent for location transmission; that's still the practice we're following for all Nextel phones. On CDMA phones, it's different--the location infrastructure that allows the GPS chip on the phone to get a location fix uses the data network more extensively than does the infrastructure on iDEN, and every location fix carries an actual monetary cost to Sprint. Our position determining equipment (PDE) servers on CDMA are sized based on certain usage assumptions, and a sudden spike in the frequency of location fixes that could result if that SDK were freely downloadable. We're working on changing all of that so that it's no longer a problem to distribute the SDKs, but it'll take some time.

There are some other restrictions on other devices (e.g. Microsoft SmartPhones) that I won't get into but you can read about here [custhelp.com] .

Alternatives For Those Who Don't Like The Restrictions

I know that these things don't necessarily say what many would like to hear -- that it's all free, that all you have to do is get a cell phone and go for it, and that there's nothing standing between you and mobile glory. But there are options:

  • Try it on an iDEN phone. It may sound awkward for me to be here in a public forum and say that you should choose one of our networks over another, but I'm really just talking in terms of capabilities. iDEN devices were designed for enterprise developers as much as they were designed for consumers, and as a result the APIs are more open and accessible than many of our CDMA phones. If you're really trying to build that cool location service and make it available to the world, go right ahead--build it for an iDEN device and you won't really find any obstacles at this point. Granted, the maximum data speeds on iDEN are nowhere close to those on EVDO, but I've seen a lot of very good and real applications that work very well on the network.
  • Try it on a non-phone. Cell phones that are cell phones first and data devices later are often different from PDA-like devices that are also cell phones. So, try it on a Treo, or a BlackBery or a Pocket PC. You'll get to use your favorite toolkits and languages (C++, Visual Studio, Java ME) and not be constrained by some of the restrictions on installing content on cellphones.
  • Drop us a line. We're not just a nameless group with an unread mailbox. Contact us, let us know what you're trying to do, and we'll do our honest best to see how we can help. I can't promise that any of us can wave a magic wand and all of a sudden make the decisions of dozens of people and months of planning go away overnight, but we have found good ways of finding workable approaches in the past and causing change over time.

I'm pretty sure I haven't addressed all of the comments, but I hope this helps explain some things. We're not out there to screw the developer over, get in the way or insist that you have to be GigantoCorp for us to talk to you. But we're in a different environment, with a different business reality, and even those who believe in the power of developers to have fresh ideas have to work within the rules sometimes to make a living.

Re:A reply from Sprint App. Developer Program (1)

modinrico (956893) | more than 8 years ago | (#14790748)

So has anyone come up with a J2me App to Sync Calendar from A900 to Outlook? Thats what I am interested in seeing.. I mean we can push whatever we want over correct so why wouldn't we be able to sync the calendar somehow?
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...