|
Posted on the 24 June 2008, by Noon Silk
Following my PubCamp talk I thought I'd list the various issues that have hit me
when doing my work. In no particular order ...
But before that, just for fun, here is me on the piano providing entertainment after the sessions ended ...
Okay, now to work ...
Random Incompatibility
Hard to narrow this down but what I'm getting at is when your working on a client side application,
or even some form of "website" [wml, chtml, html, whatever] you will note that phones may not do
what they even claim to do. This can expose itself in a variety of forms. One may be, when checking
for a feature in Java on a MIDP 2.0/1.0 whatever phone, it may lie slightly about what it says it
supports, or at least not follow the standard mechanism for reporting said features.
Another case may be the various implementations of WML that will stop the phone from successfully
entering data into input fields on pages you create, etc.
This is, of course, not even covering the functionality you'll need to actually look for and adjust
specifically (i.e. not interactive SMS capability, etc).
Testing
Testing is a massive one. You can easily write something and say "okay let me test it". So you test
on your phone, and it works. Nice enough. But there are thousands of other phones you need to test on.
It's not like development for firefox, opera, ie, ie7, safari, and whatever else. Even in that world
there are at most 50, maybe, browser you'll want to test on for "unbelievably awesome" compatibility.
In the phone world; if you test on 50 phones you're only scratching the surface. You need to ask yourself
what sort of plans were those phones on, which provider were they with? Re-test every single phone again with
a different provider and see if the results are the same. They won't be.
So maybe you consider a program like "java verified"[1] (if you're writing j2me apps). Well, you'll need to
make sure they go through the intricacies of the various providers-differences and not just a "naked" phone.
You'll need to find a provider in your area and also pay through the nose, IIRC, to get started. Probably
out of range for the "hobbyist" or startup.
Best way to test, in my experience, is just to go out and find people and grab their phones and test. And document
like crazy. Create a knowledgebase of information to use when supporting your real customers. Hassle friends, make
new friends and get their phones, etc.
How to talk to yourself? Communication Channels
Probably if you have a mobile "app" you're going to want to talk to one of your servers and then back to
the client again [i.e. have them input a name or similar]. So you need to consider how, and what sort of
channels you open up, and the cost of them. SMS? SMS can actually get annoyingly expensive, depending on
your revenue model. "Internet" channels? GPRS 2G/3G. Well, these are very expensive, as we probably know,
if you aren't on a data plan. Sometimes they can come with the phones natively (Like the "3" network) but
even they are locked in their own "area" by default (will talk about this later).
Some of the newer phone sdks (Android for example) offer "custom" channels. Android talks about a "GTalk"
channel you can use to talk to other phones and presumably a server. But is this over wifi or regular
phone internet? Is it only available when wifi is available? does it switch over if it finds wifi? etc. These
sort of things with drastically affect the cost of using your service.
Open-ness of the platform
It's interesting to think about the platform you are going to develop for (maybe iPhone/Touch) and how open
they are in terms of what can get on there. You will find, with apple at least, you'll need to go through
an approval process to get a local client app installed. It's probably worth asking yourself; why even bother? Maybe
a basic website is suitable for these devices. Maybe not, it's up to you. But consider also that apple, at least
for now, are after some sort of revenue-share, and whether or not you're happy to give that up, consider even
how it would work! Would apple take x% of your overall profit when they are only 2% of the phones? Hope not. So that
suggests some scheme you implement to detect the source of income; and even that will be time-consuming. And I don't
even know if Apple would accept that model.
Blackberry always "seems" closed, but in reality; in my experience, it's just that the corporate installation has
them locked down. If you can talk the corporation that runs the device into opening it up, it should be possibly to
get installed on there, and get them out of the zones.
"WAP"
WAP/WML/cHTML If you don't know the difference between all of these, or why people call it "wap" then don't worry, neither
do I. Near as I can tell, WML is the "most" supported, i.e. lower-end phones and cHTML up to regular HTML as you get
into newer phones. Older phones do "try" and support regular websites via their own low-end browsers, but functionality is
strange and it mostly looks terrible, unless you've designed specifically for it.
Some things to look out for here are: support of cookies, support of hidden fields, support of SSL (if you care), and input-types.
On some phones (Treo) I've seen the thing be able to submit data in certain fields, but have other selections it makes completely
ignored. It looks as if it submits, but infact the data isn't sent to my server. It's quite strange.
International Numbers
Probably you'll want to go international with your website; I mean it's on the web. You're international with that, right? Well hang on.
Along with many other things, one little thing to think about with internationalisation is the phone numbers. If you want
to communicate with your customers, you'll need to get their number in international format. How? Maybe they sign up via
an SMS message in which case you get it. So that's a bit easier, but you'll still need work up a mapping strategy to get
their country from their phone number. You can't assume it based on the country that they happen to be in (their phone
could be romaing from another country).
If you want them to choose their country well that's fine enough on a website signup, but no a mobile site forget it. The list would
be too large. So work something else out. Perhaps let them write it in and you detect it yourself in some fashion.
Which Handsets?
Maybe this one belongs up the top, but it really is important that you have a nice long think about which markets you
are ruling out by not supporting various handsets. And, obviously, phones that don't even have data plans! As part of
your "mobile" development you will almost certainly want to interact with your system via normal SMS.
Delays
It's interesting to think about how important speed-of-response is to you. If somsone messages your system, how quickly
does it need to answer? Immediately? Be careful which SMS gateway provider you choose. Some, by no fault of their own,
deliver messages slower due to the Telco they choose to integrate with, or due to load on their services. It may be worth
paying a large premium in-order to ensure prompt delivery times.
Markets
So lets say you're going international, which countries are you looking at? US? For local apps? Forget it. Take a
read of this[3] to find out why.
Other countries are better though. Europe and Japan being the obvious ones. If you do go to Japan, however, obviously
you'll need to consider the associated issues of localising for another language.
Update Strategies
If you go for a local app, chances are one day you'll want to update it. Consider this. How will you achieve it? Will it be
difficult? Can you update yourself by creating a sort-of self-updating component? Maybe, but bear[2] in mind that you may need
to fight with local data storage problems, and other such things.
If you think your app may be "update-happy" you should really consider sticking to WAP-only, or using some sort of framework
that lets you perform updates*.
That'll do for now. Hope it's of use to someone :) I don't mean to disuade anyone from this area. Personally, I find it a lot of fun!
* Disclaimer: I kind of work with a guy that writes a framework like this. Note that I haven't
told you about it, so I'm not spamming you, hopefully, but if you know me you'll may also know about this
company, so I'm not trying to sneak in an ad for him, and I'm certainly not getting any money from
him even you did choose his system :)
[1] Java Verified
[2] Bear In Mind
[3] So, you want to deploy a J2ME app in the US?
mobile
|
comment(s) 5
|
