If you an apps developer, and you want to launch an app in Europe, which do you pick today, i.e. which is closest to critical mass or has the greatest potential to achieve that?

what do we have out there…Symbian Series 60/70/80/UIQ, MS Smartphone/Pocket PC, Palm, J2ME, Brew…others I’m sure.

I’ve noticed that when people show me apps they have developed, they are usually Symbian Series 60 or J2ME but I’ve got no basis for saying that they are the most popular or even which is the greater of the 2.

Presuming resources are limited, which do you do to get greatest coverage?

Doesn’t … [ William Volk ] [ 11-Jun-05 4:29am ] [ edit ]Java allow you to write the app and run it on any platform? That’s what the kind man from Sun told me.

[ Ajit Jaokar ] [ 11-Jun-05 4:57am ] [ edit ]

write once run anywhere is for the textbooks

I always find it amusing but Sun dont make that into a claim nowadays(at least for mobile)

But then they also famoulsly said ‘We are the dot in the dot-com’ ..

Another claim I have not heard for a long time!

My point is … [ William Volk ] [ 11-Jun-05 5:16am ] [ edit ]

No easy solutions. If you can do it effectively with SMS, go for it.

Java’s advantage is a richer applications and more rapid response.

I think the incompatibility issues will help Flash gain share.

Sounds familiar doesn’t it?

flash .. interesting .. [ Ajit Jaokar ] [ 11-Jun-05 5:25am ] [ edit ]

Do you think something like bitflash ?

write once develop on mobile? [ Paul Buckley ] [ 11-Jun-05 8:15am ] [ edit ]so I’m no J2ME developer (can you tell ) but I had at least hoped that if you were a Java developer and had say experience in a server environment, that moving into the mobile world should be fairly straight forward.

Now there should be LOADS of Java developers around so in my mind that should make J2ME quite a desirable platform? There are IDEs out there, like Netbeans Mobility that make it really simple…dont they?

How about flash/bitflash – is this already loaded onto some handsets? Any applications already launched using this?

rgds,

Paul

j2me flash etc .. [ Ajit Jaokar ] [ 11-Jun-05 8:24am ] [ edit ]

the problem with J2ME is not the technology but the fragmentation at an implementation level. To be fair Sun does not control all of it(operators do). Thus, you could write a game once but porting it to many different operator platforms, gaming sites etc is a major hassle. In fact, porting alone is a BIG business(mostly outsourced to the likes of India)

flash .. I am not sure .. william suggested this .. so keen to hear from him

bitflash has been around for a while but has competitors

Test Test [ Richard Spence ] [ 11-Jun-05 8:58am ] [ edit ]

I would echo Ajits comments .. it is tough development environment but as Tom Hume may well add “if it was easy then everyone would be doing it”

It makes you chukkle really when you remember having to worry about four or five browser implementations back in the late 90′s now we have to have a WURFL.

See http://wurfl.sourceforge.net/backgroundinfo.php

Coverage [ Tom Weiss ] [ 11-Jun-05 9:30am ] [ edit ]

There are 100s of millions of Java and Brew handsets in the market but only 10s of millions of Symbian handsets.

However, native Symbian apps to me tend to have a better user experience so it’s a difficult call for me in terms of which way to go. There is a good chance that Flash will become the standardised platform for user interface development which would be a great step forward but of course there will still need to be lower level code to work closely with the network.

t.

Tom Weiss

It’s Deja-Vu All Over Again [ William Volk ] [ 11-Jun-05 12:52pm ] [ edit ]In 2000 I founded a ASP (Application Services Provider) now known as ZipProof. Java applet used for content proofing (markup) of simple ads and print jobs.

In 2001 we actually exhibited in Sun’s booth at the old Internet World show. The programmer had to spend the night before the show changing the applet so it would run on the Solaris version of Netscape.

Back to the present. I don’t see why there can’t be a certification process and a test suite for the J2ME implimentations.

The ‘sandbox’ model of Midlets make them an ideal mobile programming platform, but that advantage is lost when we find ourselves having to create different versions for even handsets in the Series 60 family. (For example the famous 6600 won’t support signed-midlet issue).

Since Sun now can say that Java represents the clear leader in installed platforms, why wouldn’t they want to make a start at tackling these issues.

As to Flash-lite … if only it was Flash 5 compliant.

Question: What is the scripting language for bitflash?

Flash vs Java vs SMS vs WAP vs Everything else [ Tom Hume ] [ 11-Jun-05 1:25pm ] [ edit ]I’m a big fan of Flash, Macromedia are a client of ours and I think it could be an excellent way of doing mobile apps… but there are problems with running mobile flash on restricted devices, just as there are with phones. It may be way better visually, but under the hood it’s still a virtual machine running in a very limited environment.

I suspect that once we start seeing a groundswell of mobile Flash apps (there have been a few commercial launches but mostly they’re proof-of-concepts), it’ll be apparent that going down the Flash route doesn’t let you magically avoid all the problems that on-phone development raises. Right now it feels like we’re comparing the gritty reality of Java development with what Flash *promises* to deliver… which isn’t a fair comparison.

The rule I can see with all this stuff is the better-distributed the platform, the less capable it is. So the relatively minor development platforms (e.g. Symbian – which is massively successful but still minor compared to say WAP or SMS) are best for doing apps targeting specific niche markets.

IMHO Java is just at the point where it’s starting to be everywhere. There are lots of problems developing cross-handset Java apps, and you need to be pragmatic: targeting, say, the top 75% of the market and working with operators or other delivery partners to identify what handset the top 75% are using.

There already is a certification process for all Java specification developed through the JCP.

This is defined by the Reference Implementation (RI) and Technology Compatibility Kit (TCK) which is required for each JSR. The RI is code that implements the spec, and the TCK is the test suite.

J2ME is no different.CLDC is JSR139 and MIDP is JSR 118 for example. The RIs ad TCKs are both there on the home pages.

So what went wrong. Did the handset manufacturers just sort of forget to certify and confirm to the spec, purposely ignored it or ??

rgds,

Paul

This must be … [ William Volk ] [ 11-Jun-05 2:16pm ] [ edit ]A definitiion of certification that I was previously unaware of.

I’ve posted on this before, there are major incompatabilities even within a family of handsets. What’s more some of the manufactuers won’t even support developers or provide documentation on the extensions … for example camera phone operation.

Plus event if you can write-once run-anywhere, you often don’t want to.

For instance, a game might work radically differently on a portrait-sized screen to how it will work on a square screen. Levels for a platform game might have to be redesigned for smaller (or larger) screen sizes. You might want to stick to underlying conventions of the handset (e.g. on motorolas the left softkey tends to cancel, on nokias it confirms).

Differences in J2ME implementations are a big problem, that’s true – and developer sort is poor (but I suspect that like healthcare spending or network operator customer care, it’s impossible to ever spend enough and get it right).

But the underlying issue is that creating a unified platform for apps which runs on a huge range of mass-market, limited devices is *really hard to do*. And if you look at where we are now wrt the handset as a platform for applications, and where we were 5 years ago… there’s been a hell of a lot of progress.

But if you could write a app to the spec, no extensions, and be assured it would run resonably well across MIDP platforms … it would be a good start.

Right now there’s a huge opportunity for Adobe (Macromedia) to do it right. It will be interesting.

mobile devices RADE.. [ Nick Meese ] [ 11-Jun-05 3:03pm ] [ edit ]

Diff tools for different apps – standalone apps on devices can be achieved with Java apps. When it comes to client server apps on devices – There are some interesting tools out there from www.Momote.com. Sat Forms (used to be Intellisync RADE but now belongs to Thacker technologies) is very good for Palm and PPC – build the app and target the device or OS (no Symbian or Java). www.appforge.com claim to support palm, ppc, smartphone, PC and Symbian devices and permutations of lack of local filtering hinders some palm developers for the time being.

Nick Meese ….Informed mobility

REBOL [ Alex Kerr ] [ 12-Jun-05 5:39pm ] [ edit ]

I don’t know if many in the mobile space are familiar with the REBOL (www.rebol.com) platform/language or have tried it, but I believe REBOL running on mobile would be an absolutely ideal marriage made in heaven, to put it mildly It has all the characteristics that offer the solution we all wish J2ME was on mobile, and more. Briefly – very small, powerful platform; very easy to program; makes everything from advanced network enabled apps to whizz-bang graphics and GUI’s child’s play; extremely small apps, truly write once, run anywhere.

It’s available on many desktop and server platforms, but not yet on mobile. I’m trying to convince them to change this

Yes… [ William Volk ] [ 12-Jun-05 7:10pm ] [ edit ]

I know the REBOL folks from my Amiga days (I was a co-founder of Aegis Development) tell Carl I said hello. Very clever stuff.

There are a lot of REALLY TINY languages that could have been better choices than J2ME. Heck J2ME should have been better than J2ME.

In the late 1980′s/early 1990′s we had a Scheme-like OOP scripting language who’s kernal was about 20kb in size (compiled C code). Totally “sandbox-ed” we used it on adventure games and multimedia titles. Started as a way of porting HyperCard titles to the PC.

Measure how many J2ME instructions are being executed per second on a typical phone. It’s a SOBERING number.

Well… [ Alex Kerr ] [ 13-Jun-05 1:03am ] [ edit ]

My thoughts were along the lines of we clearly need some sort of solution to the J2ME fragmentation problem, something that encompasses as many of the existing handsets out there as possible many of which won’t get upgraded for months or a year or two, something simple and elegant that sat on top of and/or beside J2ME on the handset (given that you can’t replace it) and smoothed over all the inconsistencies and offered a completely level playing field again.

REBOL’s done it on the PC in a technically very elegant way. I guess my question is why can’t it be done on mobile? Is it feasible? I’d like someone to pursue it until we get a definite no, because the alternative is to keep plugging away at all the parties over the coming months and years to get J2ME defragmented (as it were) and then wait for it to slowly permeate the existing user base out there via the standard phone upgrade cycle. I’d say this is a process that would take several years realistically? In the meantime developers and users suffer the consequences of the existing situation.

And yes, if not REBOL then something that fits the bill. Yes the whole stack would be technically inelegant (phone hardware, phone OS, J2ME, REBOL, user app), and yes it could be faster if you didn’t have all the layers, but a phone’s not a server or a workstation, and most have not-half-bad CPUs these days, and how fast does a phone have to be? I think the rewards more than compensate for the tradeoffs, until J2ME gets consistent across the market. Oh, and it would be optional and free for users, just as REBOL runtime is now – if the user wants the app they download and install once the REBOL runtime, then run the app. If they don’t want the app, no worries, no one’s forcing it on them. That way REBOL (or whatever) becomes your abstraction layer for your app to smooth over the inconsistencies (ignoring all it’s other advantages for a moment).

Alternatively, someone writes an abstraction layer as a J2ME app that offers the standard J2ME APIs as it’s APIs, thus effectively becoming invisible but removing all the J2ME inconsistencies across handsets. Now there’s a market opportunity!

Off topic – Amiga gets my vote as greatest digital device ever made. Those were the days

It’s not about the lingo… [ Tom Hume ] [ 13-Jun-05 3:07pm ] [ edit ]

I suspect that it’s not really an issue of which language you go for. If you have tens of different manufacturers implementing a standard, each on tens of devices over a 5-year period you’re going to get inconsistencies and problems, whatever.

William: yes, Macromedia have an opportunity here, but from what I’ve heard on various lists the same old memory-shortage etc. problems rear their heads. They’re doing what’s fundamentally the same thing: implementing a virtual machine on top of lots of different sorts of restrictive hardware. Now, if it’s just MM implementing this then there’s a better hope for consistency between implementations (and consistent QA of these implementations)… but I’m not sure how one company will manage to deploy across every handset out there.

Sun should build compatibility test suites so phones can be ‘certified’ as compliant. There could be a sticker etc to tell users that their phone could run these standard apps ..

The rule would be that an app written to these specs would run on these phones unmodifed. It might not take advantage of everything, but it would be a way of supporting many handsets quickly.

As I mentioned before, we were faced with the same problems with CD-ROM drivers in the late 1980′s, we (Activision) actually created a test suite that we shipped with product and sent to vendors to get everyone in line. Within a year, the issues were resolved.

I suspect that Macromedia will only focus on the high end of the market. I don’t expect a Series 40 version of Flash lite.

No hope for REBOL unless it gets into the native code of the phone. Running on top of Java would be a bad idea, the JVM’s are quite slow, and with some of the memory restrictions (i.e. 56kb for a JAR on Chinese Series 40 Nokias) you just can’t do it.

It would be easy to use the Symbian kit to build a Series 60 REBOL, but looking at the REBOL site I see that haven’t gotten to OS-X yet.

Certification [ Tom Hume ] [ 13-Jun-05 8:54pm ] [ edit ]

I presume there is some certification required before a handset can advertise itself as Java-compatible or use the Java logo… but yep, certification would be good – presuming that Sun had the bandwidth to do it (how many Java handsets get released nowadays anyway) etc.

If Macromedia only go after the high end of the market, then there’s still a good few years where Java is the only option for the low-end…. i.e. we have to learn to live with it.

Sophisticated information services using Flash Lite have characterized the first wave of innovation using Flash Lite. But Flash Lite extends readily to the critical task of developing dynamic, highly customizable user interfaces. The animated graphical user interface simplifies complex search operations, eliminating the need to navigate through a series of hierarchical text menus.

• We estimate that at least 15 million DoCoMo subscribers (approximately 35% of total i-mode subscribers) will have Flash-Lite-enabled phones by year-end 2004.

• More than 60% of the 4,400 official i-mode sites are based on Flash Lite.

• Approximately 20% of the (88,000:wja) unofficial commercial i-mode sites are Flash-enabled.

that’s sad [ Paul Buckley ] [ 14-Jun-05 8:53am ] [ edit ]hmmm, that’s very sad William, a) that the problem even exists at all and b), that in the 6 month when that was discussed, nothing apparently has changed.

rgds,

Paul

Open standards and monoliths. [ Tom Hume ] [ 14-Jun-05 9:01am ] [ edit ]Walter: is it coincidence that the markets which seem to enjoy fewer problems of compatibility amongst handsets are the ones which tend most towards being monolithic?

I-mode: specified and tightly controlled by DoCoMo, who specify and QA handsets and content services. BREW: a similar situation, run by Qualcomm.

Perhaps these problems are a natural consequence of our preference for open standards; that interoperability problems arise from this.

No, I will lay the blame at the MIDP spec and the lack of testing suites. This is basic stuff.

The intial MIDP spec basically was an invitation to fragmentation. As an example the keypress issue alone was handled badly, with no standardization of game control inputs (software).

The BREW folks do complain about some fragmentation as well, but obviously having one vendor (as with Flash Lite) enforces better standards compliance.

I just am amazed that Sun doesn’t treat this as a major issue. To have the majority of a market and to be aware of this and not launch at least a series of test suites seems incredable to me.

so let’s raise the issue at JavaOne [ Paul Buckley ] [ 14-Jun-05 8:01pm ] [ edit ]JavaOne is coming up soon. Richard Dallaway is attending and has offered to raise any issues (demonstrable bugs) we could suggest with the J2ME team.

So let’s give him some ammunition! Minimal code test cases which can be independently reproduced would be ideal.

rgds,

Paul

Two examples for you… [ William Volk ] [ 15-Jun-05 12:22am ] [ edit ]1. Character array out of bounds exceptions behave differently on different phones. According to the J2ME standard, the String.substring(int beginIndex, int endIndex) method throws an IndexOutOfBoundsException “if the begin index is negative, or end index is larger than the length of this String object, or beginIndex is larger than endIndex.” This works in practice on the Nokia 3650. However, on the Motorola i95cl the IndexOutOfBoundsException is thrown when beginIndex is EQUAL TO OR LARGER than endIndex. This does not conform the standard and causes code to run differently on the two phones.

2. HTTP I/O issues. Standard Java tricks such as closing an http connection to force a timeout don’t work on most devices. You have to monitor I/O processes to kill threads when they freeze.

I am also pretty disappointed that my array example isn’t ‘good’ enough for them. That’s a ‘winning’ attitude for sure.

Do they WANT to repeat their browser experence on the handset?

AMAZING.

Tom, you’re right [ Walter Adamson ] [ 17-Jun-05 5:40am ] [ edit ]That’s one of the benefits that DoCoMo sells other carriers on when promoting i-mode. And it makes a developer’s life more simple.

The control of the handset standards and the publication of what each handset and its series or level supports is a key to reducing development and testing costs. However even within this i-mode partnership it is not entirely straightforward and different levels of compatibility and features can be time consuming for developers trying to work out their greatest spread of deployment across the i-mode alliance.

It’s a good system, but not necessarily the only one, for example a more rigorous “compatibility lab” approach might be a good alternative, so that the standards are set by a carrier but without forcing or influencing or choosing handset makers. Each maker is free to compete and offer their handsets as long as they meet the compatibility standard, and the carrier would provide resources in the “compatibility lab” to help the handset makers.

The benefit of this approach is that the costs should be less, for everyone, both the carrier and the handset provider. For example the handset provider can make a globally optimal commercial and technical decision about handsets in relation to the compatibility requirement, and build that into their global handset strategies. This is in contrast to the DoCoMo model where the handset makers have to make locally optimal decisions, that is on a local node (i-mode) rather than a global optimal.

The sub-optimal nature of the local decision-making is evident in the fact that Nokia and Motorola have no DoCoMo i-mode presence, or rather have had none up to now but have been enticed to enter the fray by DoCoMo investing in their handset development in order to compensate for the sub-optimal decision to supply i-mode. DoCoMo has decided that the cost of enticing them in is going to pay off by forcing down the price of handsets from their other i-mode handset providers in the local market, whose prices in turn have been pushed up by having to conform to the i-mode requirements. It’s an interesting circle, or more than interesting it is somewhat deadly to the local manufacturers like Sanyo who are losing money hand over fist.

Also to blame for this intense pressure on DoCoMo over pricing is the absurd and destructive practice of handset subsidies. These all came about because carriers are hooked and incapable of selling anything except technology and features and iron. When life became just plain too hard for the so-called marketing and the sales groups, when they had to think about NON-priced based competition, and no longer selling iron, they closed ranks and came up with masterpieces like handset subsidies and bundling. These are even more deadly sins, which just paper over the fundamental issues in the short-term. They look great for the first 2 or 3 years, and by then the carriers have dug themselves into an even bigger hole which requires even more radical solutions.

But of course none of these people are stupid. They know. They just can’t give up – these pseudo-cost-based methods are drugs, and the top-line that they bring is also tied to the annual bonus. Because they know is why carriers like DoCoMo are in grave fear of new entrants in Japan like eAccess/eMobile. eMobile is going to follow the compatabilty lab approach – an open market with best global optimum prices from handset makers. No subsidies. On paper eMobile is a feeble small competitor, with very modest subscriber goals, not enough to threaten DoCoMo – on paper. But in fact this attack on the structure of the industry and the previous lazy habits and the hole that the sales people have dug for their companies is hugely significant, and threatening for the telcos hooked on the old models.

And don’t forget, the people behind eMobile are the same people who founded KDDI, who is eating DoCoMo’s lunch every day in Japan. KDDI has taken control of the innovation branding and the youth market, and DoCoMo is in severe catch-up mode, especially while having to convert subscribers from their 2G MOVA network to the 3G FOMA network without them switching to KDDI-au. So guess what – more handset subsidies!

A key outcome of eMobile’s strategy is that it is going to have very competitive (maybe even low!) handset prices and a wide range of handsets to offer – on day one. And subsidies, if any, will be an internal choice of the handset providers. Such decisions will hit the handset makers bottom line, not eMobile’s. This is a flying start to a mobile business, in contrast to some of the slow launches around the world due to high handset prices and limited choice. The compatibility lab will ensure some degree of acceptable user experience, as well as network compatibility.

So coming right back to your question, the i-mode alliance model is the most successful of its kind to date in providing developers with a group of assured handset standards. But it is not necessarily the only model that will work effectively, and watch out for eMobile in 2006 as a test of an alternative.

- Walter

www.imodestrategy.com

www.digitalinvestor.com.au

Another approach [ William Volk ] [ 17-Jun-05 4:46pm ] [ edit ]

Would be to have a 3rd party act as a certification lab for handset companies that wanted a “seal of approval.” These handsets would have access to a larger application pool as apps written to a standard would run on them unmodified.

From the trenches… Maybe UK operators are “gettng it at last” [ Simon Cavill ] [ 17-Jun-05 10:57pm ] [ edit ]As someone who has done a lot of mobile handset development work, I have found the biggest handicap is actually testing applications across a wide range of different handsets. In the past, most operators were extremely unhelpful in this area although we have found Orange UK to be very proactive in this space. We joined their developer scheme sometime ago and attended their developer training event in France last year which was extremely helpful in getting in from of the right people at Orange.

More importantaly they provide access to their labs were you can turn up with an application and test it on every handset they ship at one go. This means you can build and test apps on most of the current handsets on sale across the Uk and most of Europe as many operators share the same devices. I think they deserve a lot of kudos for doing this and will hopefully reap the rewards from increased WAP/GPRS traffic as well as download revenues. I wish other operators would take a note out of their book….

Simon

DoJa enables games developers to create… [ Walter Adamson ] [ 21-Jun-05 8:30am ] [ edit ](O2’s i-mode chief architect, Jag Minhas)… claims that building an i-mode version of an existing HTML site can take as little as 10 minutes. Crucially he also praised the i-mode version of Java for handsets which is known as DoJa.

He reckons DoJa enables games developers to create one version of a game than runs on all i-mode handsets. By contrast some games available on O2’s existing WAP portal [Active] have no fewer than 60 different variants.

I know lot of messages are being exchanged and lot of experts speaking on the topic. Although I am not an expert but as a person who has been marketing for a company which has a focus on mobile devlopment applications also here are my comments.

The key to choosing your platform is what you want to develop and the deployment strategy on the wireless platfrom. There are various options avaliable

(a) SMS – for low commplexty low data entry applications. SMS development does not need much of technical knowledge from the developer communicaty as there are lot of ready msde toold which will easily plug in to an existing solution. But deployment becomes achallenge some times as you would have to run behnd the operators to get the shot code to run the application. However if you are talking about Enterprise based application it could be done using simple GSM Modems.

(b) J2ME- Although most of the mobilephone and PDAs can run j2me Application you would need to do minor rework on the application to suit it to a particular devices like Palm, symbian, pcoket pc etc . becasue of multiple reasons like VMs being used, Screen size etc.. But the rework involved is less. limitation al the native APIs and functionality of the devices might not be readily avalaible to j2me . Easy to deploy as there is no operator dependency

(c) Device specific/platfrom specific tools like metrowerks for symbain or appforge etc. This tools are good if you plan to reap full advantage of a specific device or platfrom. for example if you plan to make a application which take advantage of the mutli language capability of symbian or Camera functionality etc. it is alway better to do the programming on specific platfroms rather than using the generic platfroms.

I can throw some more light and also open to tlak to you more if you need more inputs from my end