J2ME and GPRS Connections

Posted by & filed under , , .

I liked from the beginning the idea of mobile and embedded programming so I spent a lot of time on mobile and embedded programming (see the mobile section on my website). More specifically, I spent a lot of time doing J2ME stuff.

Recently, as a lot of you might know, there is a new API released by JCP for J2ME webservices. I was looking at this and it occured to me that with the cost of GPRS connections falling down so much lately it’s quite likely that in the near future we might be able to discard some of the J2ME packages as I envisage slowly but surely a lot of mobile applications moving onto a web-based mobile app approach. If the GPRS connection speed goes up, who would stop us from having virtual devices (e.g. virtual hard drives) mounted via some webservices-enabled protocol where you can store anything that might be produced by a mobile app? And that would eliminate the possibility of having your mobile stolen while some sensitive data is written on it.

For instance, how many people write nowadays single desktop applications? There is a limited niche for those kinds from what I’ve seen as most of the (serious) apps nowadays use (at least) a client-server approach. So who would consider in 2 years time for example writing stand-alone mobile apps? (I guess we will have to rule out the gaming companies 🙂 )

One Response to “J2ME and GPRS Connections”

  1. liviu.tudor

    Actually, the more I think about it, the more I realise that once can go one step further: who would need in the future to write mobile applications? The screen size keeps increasing in the mobile market and mobile browsers are nearly just as good as the likes of Firefox and MSIE. (The one I use on my Sony Ericsson for instance supports Java, JavaScript, flash, cookies and so on.)
    So maybe the mobile platforms are dying after all, making room for mobile-enabled web-based applications (and I’m DEFINITELY not talking about WAP, which is just rubbish)?

Leave a Reply

Your email address will not be published.