I'm tempted to comment a bunch on the Yahoo! Go smartphone app with its secret J2ME porting layer. But I just don't have enough of the business context around the project to draw solid conclusions. So I'll spare you the half-bakery and instead share something that you can use.
If you're building a mobile productivity app, think realistically about who your principal user personas are. If your user is on a Windows Mobile phone, a Blackberry, or a Symbian-based smartphone, don't even think about writing a J2ME app. Just don't. If you haven't been down this road, you're probably thinking, "Of course I wouldn't do that.. why do think I would?"
Here's why, sooner or later, you're going to be tempted to do it. And if you're not, another project stakeholder will, and you're going to have to talk him or her out of it. The argument is going to go like this:
- The J2ME / MIDP platform offers a lot of functionality (graphics, networking, threading, PIM integration)
- The vast majority of phones support J2ME, even ones that also offer an OS-level API, like Symbian or Windows Mobile
- Therefore, if an app is built on J2ME/MIDP, it will have an enormously larger potential market size in terms of device compatibility. Like an order of magnitude (or more) larger. And, heck, it's easier to write one app than a whole pile of them, right?
The problem is not that you're going to be have to do a lot of adaptation, since no two J2ME implementations do the same thing. Although it's something to keep in mind.
The real problem is that if your customer is a smartphone user, the J2ME app is going to stink. It will be clunky, trouble-prone, and will not match the level of user experience that the user is accustomed to on their device. Compared to the native apps on the device, yours will be the "weird" one that somehow just doesn't work quite right. (Incidentally, this is exactly how Yahoo! Go looks next to the couple dozen native Windows apps on my Blackjack.) So just when you think you've got a killer app figured out for mobile, you're guaranteeing it won't be.
And you're not really going to attract those hundreds of millions of J2ME-capable feature-phone-users because they weren't your target in the first place. Not to mention, those users generally don't understand how to install apps on their devices, don't have unlimited data plans, and don't understand how incremental data charges work on their plan, so they are terrified of the cost of using networked apps.
Bottom line: it sounds cliche, but know your market and build what they want to use. Build a Blackberry app for your Blackberry users and a Windows app for your Windows users. It's easier than building hacked-up J2ME apps. It's enormously easier to test and support, because those operating system APIs you're using are actually tested and supported (unlike J2ME). And if you're secretly nervous that there aren't enough customers on these platforms to support your business plan, admit it now and make some adjustments before you write a line of code.
6 comments:
Does this mean the mobile world is ready for a better cross-platform dev env? Not sure that building an app for every platform under the sun is that sustainable, is it?
Thoughts on how to cut down on the work?
You make a few rather huge assumptions there :)
It's rare, outside of enterprise apps for a known limited set of devices, to know you *only* want to target smartphone users. Even rarer I think to know you only want to target WinMob users, or just Symbian (actually, you mean S60 and UIQ as separate entities here, very different platforms).
Successful mobile apps target the mass market, because you never know what your potential users will have. They work because they address a need which would be even more painful without the phone. Not everyone will adopt them, but plenty of non-smartphone users might (smartphones are a tiny category worldwide).
You are right to suggest that apps will need some adaptation to work exactly like the native UI - however poor that may be, it is what the user expects so it must be done. But doing this in Java is trivial compared to the kind of effort required to manage separate codebases for S60 (remember, they've made breaking changes over the years so that's really 2-3 platforms), UIQ, WinMob, Android etc. So either you target your app to a small %age of users - really small, for native OS dev - or you go for everyone with a bit of adaptation logic. Having done this for years, I'd go for the latter every time.
I have to return to my initial assumption though - this app, to be successful, must be fulfilling a user need that is significantly harder to satisfy without the phone. As long as the experience is slick and works as the user expects they can live with slight variations from the standard look and feel (I'm wholly against the LCDUI forms which tend to be implemented badly). Witness the growing popularity of desktop apps to throw off the basic window shapes of the native OS and have curved edges, semi transparency, etc - WinAmp, Quicktime, etc. If the core UI widgets work the same then different AND attractive is not a negative.
Yahoo Go is in a slightly more awkward category, which is also one most app developers won't encounter much. It aims to reproduce some of the messaging etc functionality of the phone, and here better native integration is more important. But this is in the minority.
You should definitely check this out if you need to get some info about spying on Cell Phone Without Installing Software. I had such experience and it was really useful
Nice to see you fellas! I work and study at the same time for the last four years of my life. Time is constantly not enough, but it is necessary to do my essays. I have found a good solution - it is the best professional online https://paramountessays.com/college-term-paper writing company. You can order assignments at any time you need to. They are always online and the prices are super low at all learner's subjects.
Take a peek on this website simple way to hack a phone
Hire a hacker online
Post a Comment