Category Archives: JavaME

Know all about your app: Flurry analytics

Flurry, an early developer of mobile mail client for J2me seems to be reborn as a great analytic tools. This tool is available for four platforms: J2ME, iPhone, Android and Blackberry.

I’ve tested the J2me and iPhone version, and it’s one of the best tool I’ve found so far. Before, I’ve used “mobileZoo” from Stephane, and do the job, but started to be slow.

Flurry follow the same principle: you get stats about your users, their mobile, where do they come from, but give you much more details:

  • session length,
  • http usage (number of requests, time spent/request, data downloaded and received)…
  • number of canvas displayed
  • etc…

One of the coolest feature, is the notion of “events”. You can track events within your app (with a maximum of 100 events).
In J2ME, adding events is dead simple: whe you upload your jar file, flurry introspect it and you can select which procedure you want to track. If your binary is obfuscated, you can send the mapping file generated by the obfuscator. And then, by miracle, all calls to a specfific function are send back to the server.

Here is an exemple of two events that I’ve added in the 8Motions app:

Want to know if this feature is used or not in your app? Want to know the user path within it, want to track error generated…All of this is possible quite easily.

What is missing: the good thing for J2ME is it’s not a library, but it’s also a bad thing. I can not regenerate a new binary without manual interaction with Flurry. I would like to see a lib, like the iPhone version, that could be embeeded n my J2me app during the build process. Also, this could be used to add more details to event reporting, like additional parameters (this s what is done in iPhone version).

But it’s a very good product, and I strongly recomment any serious developper to check Flurry !

What future for J2ME?

Waow, what a big year, with several new platforms (Androïd, iPhone, JavaFX) , the move of Symbian to OpenSource?

Everybody these days is talking only of OpenOS (which in fact are not so open, but anyway) and the reborn of mobile applications.

So what happens to j2me, which is still the most important technology to deploy applications onhundreds of millions of handsets

The good thing, thanks to the push of these OpenOS is that application are now seen as a viable alternative to browser only, and a viable revenue stream.

But J2me seems to be out of the race. Why:

  • Where’s the AppStore? Still none of the MIDP2 handset have a good equivalent of the AppStore, an easy to use discovery and download mechanism. And even worst, once downloaded, the application are usually hidden in one of the numerous sub menus of the phone. And there is NO WAY to create your own AppStore in J2me using standard API.

  • MIDP3 is too late: MIDP3 phones, which should have been an answer to many of the MIDP2 lacks (background processing, multitasking, improved UI, etc…) is late. No phone hit yet the market, and even, MIDP3 as a standard is already below the market. MIDP3 is two years too late.
  • Why JavaFX? Sun introduced JavaFX trying to compete with Adobe AIR, and Silverlight. Mistake.  As I already explained (“JavaFX, the missed opportunity of Sun“), they are not good at this. Why Sun did not invest instead to provide an embeed VM into iPhone for instance?
  • Fragmentation: one of the biggest historical issue of J2me. Something that new platform don’t have yet, due to their short life. But when we will have tenth of manufacturers doing Androïd phones, I guess that there will be fragmentation too.

So this seems to be a pessimistic article about J2me, especially regarding the fact that I invested so much in this technology (I’ve been in MIDP2 expert group, as well as MIDP3 one). Again, J2me is still the leading technlogy in terms of installed base, but in  term of usage and application, the gap is not as big. So the game is quite open, iPhone/Androïd deployment will increase this year, and I am sure that others technology will emerge.

Reblog this post [with Zemanta]

Webwag V2.0 mobile beta: the best mobile widget engine ever!

Ok, may be I am a little bit too enthousiate, but really, we are happy with our first realease of V2 Beta.

Features include:

  • A new dashboard, with a “grid layout”, with a cool reflection effect
  • A lot of otpimized function (I’ll go in details later on)

But also, plenty of cool widgets to play with:

  • Enhanced mail
  • Daily comics (Garfield, Dilbert, etc…)
  • Sudoku
  • Wikipedia
  • Google/MSN and Yahoo search
  • Traffic information

And of course, much more handset supports, including blackberries!

But some technical enhancement, interesting for all widget developers:

  • Enhanced “HTML renderer”
  • Much more JavaScript support: JSON creation and serialisation , Date object, etc… I
  • Introduction of some new cool high level objects:
  • TableElem, to easily display table within Widget
  • Container object…

It never been as easy to create mobile widgets, using JavaScript and other standard technologies (XML, HTML, Json,…)

So, I will share with you 20 invites for this new version, available here! be fast:

Mobile Widgets: a comprehensible tutorial

trans_tuto.jpgInterested in creating mobile widgets? Just check our latest tutorial on how to simply create and deploy mobile widgets using Webwga platform using standard and easy to learn technologies, like XML and JavaScript.

Yes, Webwag is since some monthes compliant with JavaScript (in fact a subset of JavaScript), but this make very easy for any Web developer who know a little bit XML/JavaScript to write great mobile widget.

The tutorial describe how to create a translator widget, using a web service and some Ajax techniques. And we’ve just opened the Developers corner on the forum, so support will be given to all our developers.

devicefragmentation.info

Discovered this website – devicefragmentation.info through Jason Delport’s Mobile Observation blog

Higly interesting paper on fragmentaitons issues, and on different way to solve them!
And like Jason, I like the way Dimath Rajapkse categorize the various technique used:

I think I’ve experimented all the techniques since I am in mobile industry, from the “old” manual multi, where I you had to do the porting “by hand”, to various multi method.
I personally think that the Derive-Multi are well adapted for one shot products, like Games, while the Single-Adapt are more adapted to long term product that require constant evolution, like Webwag for instance.

It’s also true that most of the developpeur combine some of this techniques .

But at the end of the day, dealing with JavaME is not the most complex issue. We now have to deal with JavaME+Androïd+Flash and now iPhone native and Silverlight! Waow, good time for porting companies….

Identificateurs Technorati : , ,

Androïd and the iPhone?

Would it make sense for Google to provide an Androïd version for the iPhone? Of course, not the complete stack, but just the development framework. Most of the people and especially developers don’t really care about the full stack, but about the interesting part which is of the development framework, as long as it’s well integrated with the rest of the phone.
I am not an Androïd expert, but it seems possible for me to adapt this on the iPhone.

Why:

  • It could be the first Androïd platform
  • It could provide an easy way to develop applications for the iPhone
  • This would solve one of the fragmentation issue

Why not:

  • Because Apple don’t want it?
  • Because Google don’t want it?
  • The google and Apple gadget are not the same. They both choosen different look and feel for the UI (which is understandable). So which one should we choose for an Androïd on IPhone?
  • It might be not possible to reach the same level of integration between the application framework and the core system.

This seems possible to me from the technical point of view. First, google could do it. If it’s not Google, some external developer could do it. Of course, we don’t have detailled spec of Google Dalik VM, but it’s not a big issue: we could use an open source JavaVM, and just run some plain Java Code with the Android Framework? It seems that people already started to work on standard VM  porting, with this VM porting on iPhone. A good first step, but Androïd on an iPhone could be the toy of 2008 for developprs…

Identificateurs Technorati : , ,

Webwag Mobile V1 announced

Might be already old news for some of you, but I’ve forgot to put it on my blog, so here it is: we have released Webwag V1 version. The official news is here: Webwag mobile V1 release, API is open!

Here is a non exhaustive list of new features you will find in this release . And we are heavily working on other improvment on other part (web and…?), that will be out very soon!

  • End user space
    • Faster: We increased start speed, network accesses, widgets opening by a factor from 5 to 10
    • Automagic widgets arrangement: Now widgets can be automatically arranged while you move them with no need for pixel adjustment (the old free mode remains availab
    • 140 handset models: We’ve grown the handsets compatibility from around 10 to 150 over many new brands. We’ll showcase some of them on this blog in the coming weeks
    • Parlez-vous Français? You’ll be happy to learn that Webwag mobile now detects your language and is available in French. Many other languages will come.
    • Link to original article in Blog posts: You can now view a mobile adapted version of the web site’s article page for any information (RSS) feed.
    • More room for Widgets. The bottom bar has been replaced by two elegant soft keys, giving even more room to widgets.
    • New widgets including eBay, French Traffic conditions (very useful these days), a new discovery from mobile…
    • Many many bug fixes…
  • Developers: A new shiny Javascript API is available at api.webwag.com that makes it easier than ever for any web and mobile developer to create widgets using a standard subset of Javascript, XML and other standard oriented tools.
  • Brands and content owners: Webwag mobile is a very addictive and simple way to create a positive relationship with end users by giving them a useful service linked to a brand or a specific content. You can contact us at partnerships@webwag.com for more information on how to mobilize and monetize your brand and content in the Webwag mobile ecosystem

So let’s talk a little bit about the developer part: yes, now the scripting languge is a subset of JavaScript. So need to learn a new language. So new, you can have an object orientation for the script, this will simplyfy some form, especially for callback, as function can be associated to objects:

var myObj=new Object();
myObj.showMe=function(){
alert("Hello World:");
}

myObj.showMe();
is now a valid code. So check the api.webwag.com for more info (and do not forget to register to have access).

We also added a lot of functionalities for developer, like the ability to create “form” for better input parameter.

We will prepare some tutorial and samples in the coming weeks….

Update: The http://api.webwag.com does not require anymore you to register…

Lua, Java and a little bit of history

Browsing the web I’ve discovered that LUA reached a popularity of 15 in tiobe rank. This is incredible, but also very interesting. Lua is a very simple but smart language that was designed to extend existing applications. Typically, to add scripting capacities in existing programs. This is a not a new idea, and a lot of technologies where available at that time, but most of them where not easy to implement.

The key differentiator of LUA was the integration simplicity. LUA is now very popular, but when I’ve first discovered it, it was not the case. I’ll do an “historical post” of what happened in the early days of In-Fusio regarding LUA, mobile, and Java.

In 1999, when we started In-Fusio, I’ve created the first connected game embedded in Mitsubishi device. At that time, the most advanced mobile game was snake (V1!) and we were delivering console quality game on mobile, but even more, we introduced connectivity with SMS. User was able to download new game levels each week through SMS….These games (BrainDrain, Push, Crazy Pet) also contained some hidden part, but obviously very hidden as not so many found them: there was the first 3D real time demo on a mobile phone, done using Vector Ball, a reminder of my early Amiga days


Some snapshots of Push, a Sokoban clone, embedded in Mitsubishi phones

But the issue was that the game where embedded, and not downloaded. User was not able to change his game. We started then to think to a way to download games.
Technically, it seems that it was possible, even with limited resources of the phone. We could expect around 16 to 32kb of available writeable flash memory for game. But due to security reasons and cross platform issues we needed to find either a scripting language, or a VM based engine.

So I started to evaluate the various technical solutions for this: from Python, Tcl/Tk, Java, JavaScript and of course Lua. Even Perl! I also looked at some alternative solution, mainly used in SetTopBox.

Rapidly , it appears that Python, Tcl/TK, JavaScript where really too heavy in terms of code size to fit into a mobile. Perl…no, definitvely not Perl for game!

So the remaining two where Java, and Lua. Remember, it was in 99 and MIDP was not yet even discussed. I’ve evaluated a couple of the “light java “implementation, like Waba, and another one that has been used in some lego engine.
But Lua looked great also, and was compliant with our requirement:

  • small footprint
  • easy integration
  • simple to understand and to use

I made a prototype of an integration with a “kind of” R-Type game on a Mitshubishi phone that worked well.But my godfeeling was that Java will be here for long time, and strategically speaking, it was better to follow the Java path. The KVM on Palm was also presented in JavaOne’99, the first JavaOne I’ve attended!
So we look deeper on the Java side, and found a nice JavaCard implementation by Schlumberger. It was really an amazing implementation, tailored for highly constrained JavaCard, so it could feet easily in mobile.
At that time we also discussed with Sun about Java licensing, but fee were really beyond expectations (Sun started by talking of a 10$ per handset license!). We decided to choose the VM implementation, a clean room implementation so no fee for Sun as long as we did not put any Java logo on the mobile. So we decided to use Java instead of LUA.

The first implementation took some time, but when we had the first real handsets, we had a big surprise: it was ssoooooo slow, and unusable for games! Was hard to go beyond a simple minesweeper game. So we decided two things:

  • improve the speed of the VM, by working with Schlumberger
  • create high level game API

So we created Sprite, Layer component, animation, etc…to speed up things, a complete game api. We also added a raycast engine that could be used to create 3D effects with processing power of mobile of that time. In fact, all the rendering and the animation was done natively, while Java was used more as a scripting engine. And that’s where the MIDP2 game API came. Here are a few snapshot of the first black and white created for the platform:


Some of the early Exen games….

The first prototype was demonstrated in September 2000. Even internally, the game developer team was not convinced with the ability to create arcade quality game on mobile. But the first game produced externally on this platform, by Kalisto, “Tinies Farter” (yes!) was a great and really playable arcade games, and gave us confidence in the ability to create more cool games.

With a launch early 2001 with D2 in Germany, closely followed by Orange in France, and more operators later on.
Since day one, the system has been conceived with an ecosystem for game developer, operators, and us, so we started to make revenue from day1, while it took years for J2me to reach maturity. We thought that we had a 6 to 12 month windows of opportunity with Exen, but it appears that the window was more 24 to 36 months, with a total deployment of more than 50 millions of handsets….Not bad for a small window of opportunity.

The story is not yet ended, but we will write this another time….
Identificateurs Technorati : , , ,

Webwag new look and mobile launch

Great news with the new look of the web site, and the official launch of the mobile version (in fact, since a couple of days, but we were too busy putting everything up to blog it!).

So, go and try webwag.com to experiment the new WebWab look. Flashy colors are avalaible, as well as more relaxing green or grey.

This is also the launch of the long awaited Webwag mobile version! >Now everybody with a recent J2me phone can experiment true mobile widgets.

Webwag mobile perspective

Just go to the website, register and open the small “phone” icon and follow the steps…

This is the first major milestone in the Webwag vision of the “Personnal Digital Hub”, allowing access to all your content from various devices, whatever are the technologies.

Mobile is only the first step, and you will see others in that direction.

The SDK will be released later on but we will select a few motivated developper if they want to experiment it earlier.
Widgets use an XML description for UI, and a simple scripting language for behavior. Every JavaScript developper will be familiar with these technologies in a few hours, even if more complex widgets require more work: we don’t deal with the same issues as in the browser world!

Webwag mobile Beta open: experiment true mobile widgets today!

Want to test the new Webwag mobile extension? Then go to http://beta.webwag.com and use your webwag account (or create one!).

There only are few handsets officially supported (N70, K750, K800, LG Chocolote, Sagem My800x) but should work on more handsets, just try it, and let us know the results.

  1. Register and create your webwag account
  2. Add the widgets you like in your page
  3. Add them into your “mobile screen”. To open your mobile screen, click on the “mobile” icon on the top left, or click on the “mobile” icon on the existing box.
  4. “save and install” will send you an installation SMS that you should receive within minutes with a link to download it on your mobile. On most of the handsets, the link will be selectable within the SMS. On some handsets (like the LG, Motorola) you can use this link from a specific menu from the SMS message.

If you have problems receiving the SMS, let us now

Feedback, issue, just email us at: feedback@webwag.com

Faq:

* Are all widgets available from Web and mobile?

No, only a subset of existing widgets are today available on mobile:

  • RSS
  • Flickr
  • Email
  • Note
  • Weather
  • Clock
  • Background

* Is it the same widget running on web wand mobile?

The widgets use the same data, but are different, because of size issue.

* But why not having just a web browser running these mobile widgets?

Because first, technically very few handset have the capacities to run complex widgets within browser, and also because we think that usage are different from web and mobile.

* Do you plan to support more handsets?

Of course, we are already working on this.

* Waow, sounds so cool, how can I participate and create my own widget?

The SDK is not yet public, but just email us and we will notify you when ready (feedback@webwag.com)

JavaFX : the missed opportunity from Sun

Sun officially launched today “JavaFX” (previously know as F3). It’s a scripting language that could be used to easily create rich content application for Java powered device.
This seems to be the Sun’s answer to Apollo and SilverLight, from Microsoft. Honestly, the answer is a little bit disapointing

  • One more language! The language itself, is nothing really fancy. No major killing feature, not as dynamic as Ruby for instance, and not close enough to other “standards” like Javascript or Java. So why create another language, while there are so many?
  • Integration, deployment: I take a look at the first sample and libraries. The library is something between 1 and 2 meg, on top of a standard JavaVM (JavaSE!). So, it’s huge. That’s one of the big weaknesses of Java today: the runtime is already so big, the installation so long, but worst, the starting time once everything has been installed.
  • Target: mobile. Sun claims that it’s a good candidate for mobile application. Of course, it’s the next battlefield. But honestly, JavaFX is way too big to fit on existing mass market devices or any existing J2me implementation, so it needs to be embedded natively probably. I do not beleive that JavaFX mobile will be a serious candidate in the next 18 months, too early.
  • Why not pushing further SVG? SVG is the current standard in vector graphics (and Flash is the de-facto standard). So why not push more SVG, by creating a better binding with SVG and Java, and/or Javascript?

So I do not believe that JavaFX will be big. It’s another missed opportunity from Sun to reinvent themselves. They had a widely deployed VM, that had the “network is the computer vision”, and now they desperately trying to follow on the RIA…Ajax is an intermediate technology, soit’s a fantastic opportunity to create something really new, Microsoft and Adobe are on the train, and Sun still trying to jump in…

Technorati Tags: , , , ,

Mobile Widgets: soon a reality!

Here are the first screenshots of the first result of the Mobease/Webwag acquisition: Webwag mobile, a full mobile widget engine….Beta just started on a small number of handsets, but more to come.
This engine haves mobile Ajax capacities, scripting, OTA update, and much more…..


I will soon write more about the technical details of the engines, as the API will be totally free and open, so developper can write real mobile and web widgets, that can be accessed from anywhere…

MobileWidgets are moving fast: Mobease acquired by Webwag!

 Seems that mobile widget is a really fast moving area. Our first product (MobiFindIt!, a mobile search engine) has just been launched, and our second one, mobidget is not yet public (but you won’t have to wait too much) and we are already acquired! The happy owner of Mobease is Webwag, one of the actor of the start page space…

+ mobeaselogo_final_smal_logo.png

We were discussing, and even working together since some time, the WOD (Widget On Demand) being one of the first result of this great collaboration.
 I’ll will take the role of WebWag CTO. It’s a really interesting space, as we are one of the few company with a strong experience both in mobile and in Web technologies, Ajax, Web2.0, etc… But there is an incredible amount of work to be done, both for improving the current platform and adding all our cool new innovations.
  Widget are now increasingly popular, mobile widget are on the same trends too, the launch of the iPhone increased a lot the visibility on this space. Technically speaking, there are a lot of challenges, both on web and mobile (Ajax and his challengers like Flash, RDA, Mobile Ajax, etc….) that show that there are a lot of open possibilities.
  But more than technology used to achieve this, widget and personnal page are in my view the best example of web and mobile integration, where user can access to the same data from various devices. The usage (of these devices) will be different, but they all provide an ubiquitous access to your personnal datas and area of interest.
As you guess, the integration of mobease technologies (Mobile Search, Mobile Widget) will provides a superior user experience when combined with the Web.

  I will also speak as a Webwag representent at the next Benchmark conference on the Web2.0 this Tuesday in Paris.

Technorati Tags: , , , , ,

powered by performancing firefox

Looking for J2ME developers

We are hiring some Embedded/J2ME developers at mobease. So if you are a talented mobile developer (J2me, Symbian), ideally with some experience, send us your resume. Job is located south west of France, in Bordeaux, but we are open to some remote development on a case by case basis…

We are also looking for Web/server side developers: you like to play with php, javascript, ruby?

More info on the Mobease jobs page.

Join the mobile widget revolution! :-)

Technorati Tags: , ,

Is Adobe Apollo better than Ajax? (applications back to desktop!)

 May be you’ve heard the buzz about the Apollo project from Adobe. Basically, it’s a desktop framework that allows the execution of  applications in a machine independant mode, and provide access to local ressources of the computer (mainly filesystem). The objective is to be able to use Web applications in a non connected mode (local) for various reseaons (speed, availability of network, etc…). This is also called RDA (Rich Desktop Application )

The first remark, is that it sounds very similar to the initial objective of Java, 10 years ago! A machine independant VM, internet oriented, etc… especially with automatic upgrade features that are now parts of JavaWebStart. I am always surprised by the way industry always “re-create” the same things again and again. The good thing is that each iteration is better than previous one, but now, after the “everything is on the browser”, we are back to “local applications”. Sun had the lead some years ago, but was totally unable to drive and support the market.

About the framework, himself, there is not yet so many information, but I am afraid that it’s just a good repackaging of a local Flash player with PDF and an HTML component…Nothing really exciting, but Adobe is very good at creating the right buzz  and as always, got great designers that create apps with the right waoow effect. The positive side is that Ajax/HTML are not really good technologies to build rich UI, they are just hacks, so it’s time to have something better. Not sure that Adobe will bring something better, but the fact is that there are not so many alternatives yet. Microsft is polishing is WPF framework (ok, not polishing but starting) so Adobe may have a timing advantage here.

But I have a few remarks:

- This is not standard. By developping an Apollo application, you rely on Adobe as the only provider of a technology. You can not provide your own Apollo implementation for specific devices, like mobile phones for instance. It’s a step back from the internet open standards.

- Full offline capacities won’t be for Ajax/HTML: I am quite sure that the offline capacities will only be available for Flash/Flex application. In other word, an existing Ajax/HTML based application won’t be able to run offline , or just as the equivalent of a “save as” mode, unless it will be rewritten. So do not expect to “port” your existing application now. It’s the best way to push you to adopt Flash/Flex.

- Is JavaScript/ActionScript the right language? JavaScript is a nice language, but is it adapted to develop full applications? Remember that in a RIA, most of the application logic will reside locally while now you can have part of this logic – especially the complex one – on the server side. So suddenly you will haves thousands if not more lines of code in pure JavaScript. Was already hard to manage on the internet, might be harder with RIA? ActionScript, which is ECMA based, seems more mature than pure JavaScript, but also incompatible….

My last remark (and linked to the first one) is that on mobile for once are not to far away. The availability of Ajax enabled browsers was limited (read non existant), so all rich applications are made using this kind of concept through J2ME, FlashLite, native, etc…and framework (like Mobease Widget one) are built on top of these technologies.

As I’ve previously explained, mobile is most of the time more about synchronisation than browsing (for mails, address, news, etc…) and such locally running app with connected capacities are the best answers.

That’s why Apollo go into the right direction even if there is still a lot of weaknesses in the approach, so let’s see how others react – Microsoft is doing WPF . Is there any attempt from the opensource community to propose something like this? OpenLaszlo? FireFox with XUL?

Note: during the preparation of this note, I’ve discovered “SideWinder“, which seems to be a project that attempt to build a framework for connected/non connected internet application. Seems highly interesting, but also not very mature as I was not able to run a single demo…

Technorati Tags: , , ,

J2me mobile development practices

It’s a long time that I am in the mobile industry, before J2me, and at a time where cell phone where not a mass market product!
I’ve followed the evolution of mobile development practices, especially in Java. So I agree partially with this article: The 10 principles of Assembly Java who gives good hint and tips for mobile development, but I also think that hopefully most of them will start to disappear slowly.
It’s a really strange industry, where on one hand people are talking of “MobileAjax” as the killer app, where the cost of one Ajax line is probably equivalent to the cost (in terms of CPU, memory used,battery) of a full Midp1.0 application, while other are strugling with putting everything in a single class to fit in constrained devices.

So the truth is as always, probably in between. These principles are mostly applicable if you want to deploy on older handsets (including MIDP1.0) or generally speaking phones older than 18 months, which is the biggest market in terms of installed base, but might not be the biggest one in terms of usage, but that’s another story.

MIDP is improving and got more memory, so I think that a few OO principles can be back. So I just compiled a few more advices, and I would be happy to discuss of them:

  • Use carefully inheritance, but use it. J2me is an object oriented language and framework. Using inheritance could save a lot of code and time. Use this time to optimize other things.
  • Reduce the number of classes to the minimum, but do not put everything in a single class; It’s better to have an elegant three classes design than a single classe optimized one. The benefit of the later will be killed by the complexity.
  • Avoid setter/getter unless it creates too much constraints. For instance, if accessing directly to a variable and changing it haves no side effect, keep it without accessor, but if you change it and then you need to change a second variable, do accessor.
  • Apply OO principle of high level classes, and “Assembly Java” on small granularity elements. A small granularity element is something that might be instancied (if it was OO) a lot of time in your program. For instance, do not create a 3D animation program with Objects like vertices, points, etc.. but keep things like World, or eventually Meshes as object.
  • Use preprocessing! This is usually considered as a bad thing from OO point of view (which I agree) but it’s a good way sometime to solve embedded problems in a good way. The issue is then that you need to have a complete chain that will support this. In other words, if you generate several different binaries, you must have an easy way to provide to the end user the right binary. That’s something well handled by big companies, but hard for freelancer. The ideal situation (but require a lot of work) is to have only two or three binaries, one for low end, one for mid end, and one for high end devices. Typically Opera Mini achieve this very well. One real issue, is to deal with various JSR. On some Java implementation, it’s not possible to include in your J2Me some classes (like bluetooth) even if you do not use them because these are part of the javax.xxx package. The only way to solve it is through preprocessing.

Other links on this topic:

Is still there any Java ME Programmer Thinking in Object?

About Object Programming
Technorati Tags: , , ,

Mobile2.0 event feedback

Unfortunatly, I was not able to attend to what seemed to be an interesting event. However, Mike Rowehl made partially an analysis of the event, but also had great comments about the various actors:
Mobile2.0 – Didn’t Quite do it

I really like these one:

  • Lots of people looking to publish new content for mobile were upset about the number of browsers and incompatible standards they needed to be familiar with in order to get anything up and online. However the
    people working in mobile for a while were pissed about anything that tried to plaster over all the differences they’ve spent years learning the ins and outs of and building up adaptations for.
  • People coming from the web world insist that the only real way to get mobile used is to make sure that mobile and the web integrate well, that there should be seamless blending of the web and mobile. People coming from places without fixed internet access yell and scream that we really need to stop shoving the web into their perfectly usable mobile only environment.
  • Mobile service providers list the myriad ways that people developing mobile applications and content can simply and easily put their content up online and start making money from it. People with mobile content and applications moan that none of the methods for publishing and monetizing their content and applications come anywhere near the simplicity they need, and they just can’t bear the margins provided.
  • Existing web publishers keep telling us that mobile is just too early to try to make money off of, don’t bother trying yet cause the ecosystem isn’t ready. However people with novel new applications (the ones that are most well positioned to respect the context of mobile implicitly) have no chance to bring their disruptive application to fruition because the only way to make money is to bolt on a crappy web experience as well.
  • People working on standards for the mobile web and application programming environments can list for you a complete alphabet soup of acronyms describing the millions of ways in which mobile application development will be better just a few months from now. People working on applications feel like the standardization efforts take way to long and don’t deliver anything that really makes their lives any easier.

Sorry for copying this more or less directly, but is it soooo true…

Technorati Tags: , ,

UI and the Fun factor…

Interesting document from Nokia about Visualization and graphic design for mobile. Not a revolution, but contains some cool tips.

A few examples:

  • The FUP maturity model: Features, Usability, Pleasure. Do not forget the Pleasure of using and app.
  • Deliver your promise: you cannot improve low quality app with just eye candy and visual attractivness…
  • Entertainment vs Enterprise type application and impact on design
  • FlashLite as a tool to prototype mobile UI: I totally agree, it’s one of the best tool to quickly test and geet feedback on innovative UI even if it’s not always the target technology.
  • etc…

Worth a read for all mobile developper/designers (and yes, In-Fusio has contributed to this nice doc!)
My remarks is that I hope that S60 Nokia UI designers will adopt this principles (especially the FUP on the Usability/Pleasure part!).

So what I like the most is this FUP concept: Features, Useability, Pleasure…Frequently, the balance is not well done in all of these. We have some great featured product, but not fun at use, or good looking one, but totally unseasable. It’s usually very hard to mix both, but some achieve to do it. A good exemple is this “discoapp” for Apple. It’s just a simple CD rom burner program, but the interface is not only very readable and clear, but fun too. A good example of well balanced mix, look at this video of what happens when a CD is being burned:

[QUICKTIME http://discoapp.com/blog/images/Curtain.mov 410 466] Through Small Surfaces.Technorati Tags: , , ,

OpenLaszlo for mobile….

Sun/Laszo announced this week that they will work jointly on a new project called “Orbit”:

“Orbit” is an exciting collaborative effort between Sun Microsystems and Laszlo Systems enabling OpenLaszlo applications to run on devices supporting the Javaâ„¢ Platform, Micro Edition (Java ME) application platform. This project will be delivered as part of the OpenLaszlo “Legals” multi-runtime effort, with first demos available before the end of 2006.

Laszlo sounds nice, it’s a framework based on XML/JavaScript that allows you to create and deploy Web application on different technologies: mainly Flash but soon DHTML (and now J2me?).

The promise seems a little bit big, so I excpect that exported application will have some limitation, but it is a nice idea to follow. Could this effort help to solve the “Widget fragmentation” issue?

MobileZoo: the definitive museum for mobile diversity

mobilezoo.biz logoMobileZoo is a part time project done by Stephane DeLuca, one of the members of the Advanced Technology Team here at In-Fusio.

One of the initial idea (I am just over simplifiying, as there are many ideas in the air here!) was the following: instead of creating specific benchmark to provide information about handsets, or to create your own code to gather this information and store it on your server, why not provide a service for this?
The ideas is to create a small library (less than 8kb) that can be easily embedded on most (if not all) J2me application. The library than gather the maximum of information about the handset and send them to a server.
This server then maintains a database about handset capacities, supported JSR, configuration, etc….
There are multiple benefits on this approach:

  • developer can easily find usage of his own application. Focus on the real added value of the app, and not on this plumbing
  • other developer haves access to consolidated statistics about handsets capacities
  • marketing people will also have a visibility of handset deployed per country…

So basically, it will use the combined power of several individual small applications (typically freeware like j2memap) to create the most complete handset database available…..

We’ve just trialled it since last week with J2memap, initially for SE phones (that’s why you will see much more SE than Nokia) and now for most of the handsets. The results are quite interesting:

  • First, the most used handset, is without any surprise, the SE K750. But just after is the K700, a quite old model know but still heavily enjoyed by many users.
  • Then, the W800i, W810, etc….


Of course, some Java Vending Machine haves some of this feature built in, but none of them offer such service for third party, and expose this detailed information about usage both for the application user, and for the community….

Technorati Tags: , , , , ,