Interested 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.
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….
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…
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….
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 : java, j2me, exen, in-fusio
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.
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!
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.
Register and create your webwag account
Add the widgets you like in your page
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.
“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)
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…
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…
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…
+
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.
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?
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…
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.
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…
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:
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 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….
One of the next buzzword these days is “Mobile Ajax“, as THE technology that will save mobile applications. This was especially true with the recent announce of “SoonR”, the first mobile enabled Ajax application. Looks good, but unfortunately, I have no Ajax enabled browser out of the thousands of handsets we have here at MobileScope….
But this generates some buzz, and as usual, some hype. So, in a “back to reality” attempt, I’ve tried to discuss a few myth of “mobile Ajax” here:
Mobile 2.0=Mobile Web2.0 (and Mobile Web2.0 = Ajax on mobile). Wrong, as this imply a choice of technologies. The good thing (or is it a bad thing?) with mobile, is that there is a huge choice of technologies. If mobile is connected, does not mean that it is connected only through browser.
Ajax applications will run the same on mobiles than on PC, and this will save us some porting costs. Wrong! Seems that the Write Once Run Anywhere myth is back!! It was actually already not achievable through technology designed for this, so I did not see how Ajax app (which is basically designed for one or two platform) will be able to address suddenly thousands of different platforms….. And all the existing so called mobile Ajax applications are ALREADY specific for mobile. The SoonR mobile version is not the same one than SoonR on PC….
Ajax applications are a way to by pass operators….There is
absolutely NO link between operators and this. Java, Flash, Symbian
applications can be acceded directly by end user as well as Ajax
applications (and with a bigger installed base). In fact, there is a
link: as an Ajax is an online application, it’s easiest for them to
block certain site if they want too….And no way to install it outside
the browser! The biggest issue is not the access, is the billing…Or
the business model. How to make end user pay for services in an easy
way….
I like Ajax as one of the technology that I could use to create a better experience, but as discussed in one of my previous post, I think that the complexity needed both in the browser and the application is unnecessary on mobile device, and we should take the mobile opportunity to solve some of the technical issue raised by Ajax on the web. There is also an interesting article from Dioan Hincliffe raising a few of the Ajax issues: Seven things that every software project needs to know about ajax. A few of his remarks:
Ajax applications are complex applications (even if they are doing simple things). This leads to this comment: “Good Ajax programmers are hard to find”
The browser model (of Ajax) haves some limitation: no way to access to some local resources of the handset…
The browser was never made for Ajax. In other way, ajax developer used the installed base of modern browser to create something unique.
Now, back to mobile….Should we try to duplicate current ajax complexity to mobile, with one model, or can we try to solve some of the issues of Ajax?
I am a strong believer of the last option. There are already three technologies that will play significant role in the future: J2me, FlashLite, and Ajax. Only one is really deployed now and it’s J2me. FlashLite is on the way and Ajax far from being a reality yet. But these three are complementary, and could work together in a perfect way, in a different and better model than on the web.
Two interesting news for today:
First, Flickr introduced some mapping feature for geotaged picture. You can see where these picture has been taken. Of course, visualisation is done through Yahoo Maps, which is less accurate (outside U.S.) than GoogleMap, but that’s a good start, and probably a big incentive for Yahoo to correct this soon.
Of course, this feature is nothing really new, but it’s nice to see in integrated. Note that “Pikeo” is an Orange project that intent to do the same kind of things, but not as smooth as I would expect it…
The bad side seems to be that you need to do an extra step, even if your photos are already geotagged. You need to “import” them (go to “organize”, then “map”). This step is probably not needed and useless.
The other issue seems that YahooMaps seems to contains a lot of errors, as you can see on this snapshot….
The other good news of the day is the announce that I am involved in the “mobup” project since some monthes now. Mobup is a free open source Flickr uploader. Now mobup haves some geotagging capacities: if you have a connected GPS to your mobile phone through bluetooth, Mobup will add Geotags to this. Of course, the geotagging picture capacities of J2memap are based on Mobup…
Many times I’ve browsed the web to find the “best” midlet to do testing, finding supported JSR, and so on. So here is a small list of resources I’ve found on this topic. So feel free to add unlisted things, so I will be happy to extend the list.
Calibrator
This one is doing a good job in many areas, testing all capacities of different JSR, RMS speed,video/audio capacities, etc…Results are send to a server, but this server side is really lacking of polishing. No organisation at all….That’s the only point to improve, but the midlet proven to be very useful. That’s my current favorite.
TastePhone Here also, a lot of different tests are made, including RMS speed, copy speed, etc… Results are available on the result pages, but it might be in French only
JBenchmark
On of the older, probably good for speed checking, but limited forother informations. Speed issue is only a small part of the problem. But good website to browser the results…
Note that there are others benchmark now, JBenchmark2 (for MIDP2.0 devices) and JBenchmark3D (for JSR184).
GrinderBench:
position themseves as an “industry benchmark” developed by EEMBC, but coming very late in the market, and focused only on speed benchmark.
FPCBench: Update: The author of FPCBench posted some info on the bench as a comment of this post. It seems that it’s more than just speed. Unfortunatly, my main concern with this bench is that the UI is not as simple as Calibrator (why a Calculator is needed in such program), and results seems to be send through SMS…
MicroCode: another project, not tested (thanks Wendong)
Other interesting resources:
I use frequently J2mepolish device database library, to quickly find if a handset support a specific JSR or not…. This database can be reused with j2mepolish to create specific build per device, or device family.
Interested 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.
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: 
Sun/
Many times I’ve browsed the web to find the “best” midlet to do testing, finding supported JSR, and so on. So here is a small list of resources I’ve found on this topic. So feel free to add unlisted things, so I will be happy to extend the list.