Posts filed under 'MobileAjax'
The topic of Widgets standardisation will become a hot topic next year. We already haves so many different Widget framework based on browser (Google, Opera, NetVibes, WebWag), a few desktop based Frameworks (Yahoo!Widget and Dashboard), and now some emerging mobile widget framework (Widsets, and of course Mobidgets! 
) that it’s quite sure that we can not continue into the same direction.
In this post, I will try to provide a view on the landscape of widgets in terms of interoperability (between platform) and try to explore the common part between theses framework.
First, I’ve been to “Widgipedia“, and from their FAQ, they already support these 14 platforms: (this was more than I was expecting)
- Yahoo! Widgets (Windows)
- Yahoo! Widgets (Mac)
- Dashboard (Mac)
- Standalone Widgets (Windows);
- Standalone Widgets (Mac)
- Microsoft Vista Sidebar (Windows)
- Opera (Windows)
- Opera (Mac)
- Opera (Linux)
- DesktopX (Windows)
- Kapsules (Windows)
- Samurize (Windows)
- KlipFolio (Windows)
- AveDesk (Windows)
I assume that some of them are interoperable, especially between the mac/windows version, but it seems that it’s not always the case.
Also there are some missing components, like Netvibes, or WebWag which have their own framework, and probably Windows!Live? Flash is also a probable candidate for a Widget environment….
Mobile applications have also their own frameworks, for instance Widsets or Mobidgets
So what levels of interoperability do they have. For now, none of them are interoperables!. When you do a Google widget, than you have to recreate it for Yahoo!Widget for instance.
The positive view is to say it’s not so hard to convert a widget from one environment to the other….
Is there any hope that this will change in the near future. I am not an expert of each of these widgets framework, but we can identify two major things:
the “representation/descriptive part ” generally XML based
the scripting language used is JavaScript/ECMAScript…
That’s a good start, but then you face all the little details: where are stored the user preference, how to access to some utility function, is it CSS/HTML based, etc….
So what’s next? Three options:
- One of these framework become the de-facto standard, and all the others are either killed, or align to it….
- A standardisation body (W3C?) take the lead on it and try to solve the problem….
- Status quo, only a few widgets engines/framework are still alive and tools are created to “transcode” one widget into another?
None of this solution is perfect, but it will be interesting to see how this will evolve in the coming monthes, especially in regard of mobile who will bring new widgets framework, but who will be hardly compatible directly with other framework for many technical reasons….
I am sure that it will be an interesting topic to discuss in the upcoming “Widgets Live!” conference in SF! (which is the same day than this interesting mobile2.0 event, in SF too!)
And in the second part of this post, I will explore potential solution and direction for a common widget framework…Stay tuned.
Update: one the reader (Lindsey), pointed out this work on W3C about packaging deployment Web Application Packaging Format Requirement. This doc is a starting point, but contains a good table about various packaging format used between Google, Yahoo and others…
Read also this post from C.Enrique some monthes ago on the same topic….
Picture taken from the “hyalo-weather” widget….
Technorati Tags: widgets, mobilewidgets, standardisation
October 16th, 2006
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?
October 13th, 2006
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 is the only technology to create mobile mashups: (this is the same wrong statement than in the web): No, basically ALL technologies can be used to create mashup, to access to existing Web services:
- J2ME (and not need to use “JSR172″ to do this)
- Even Wap/Html/Xhtml can be used to create mashups…
- A few example of personal mobile mashups (done in “plain J2ME”)
- 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.
Technorati Tags: ajax, mobileajax, j2me, flashlite
September 27th, 2006
Let me introduce a company where I have some involvement as a technical advisor. This company is called Mobease, and their first product, still in beta, is called mobifindit! It’s a search engine for mobile phones that goes through offline and online content… MobileCrunch already has a positive review here. Mobifindit! will soon reach the 1.0 stage, but the company is working on a second important project named Mobidgets!
Mobidgets is a widgets engine for mobile phone. I will not describe all the features here, first because they are not yet frozen, but also to keep some excitement. I will do it in a later post. But Mobidgets is looking for alpha testers, people who are interested in creating widgets for mobile phones. So, to join the program, we prefer you to be a developer but there’s no need to be an expert! The only constraint is to have a Symbian S60 device 2nd Ed FP2 or FP3. If you are interested, go to Mobidgets.com
And here is a screen shot….Looks nice, no?
Update: a Java MIDP2.0 version is in the pipe too! The Symbian one was only a little bit more advanced than the J2me one. Of course, widgets will be compatible between the two versions, but Symbian provides some features not accessible through Java.
Technorati Tags: mobile, widgets, mobilewidgets, mobidgets
July 28th, 2006
This interview with Opera CEO gives some hints about Opera strategy in Widget space.
Opera is probably one of the players with the best positioning. Technically, they will benefit from their Opera platform, that contains already some important piece for a widget engine, the rendering engine, a script interpreter. Even better, their proxy technology that allows the transcending “on the fly” of widget from PC to Mobile is also a key benefit.
They also have on of the most deployed browser, so their strategy make sense.
Is this the ultimate solution for widget? I am not convinced, for different raison that I’ve already raised. A widget running on desktop and mobile will be different. Not only for size reason, but for usability reason: keyboard instead of mouse, other input functions, etc…. What will be the easiest path? To create very simple well adapted to different device, or try to create a single app adapted to all device?
I think that some widget could be easily adapted, a clock, or a weather widget are probably things that could be easily scaled to different platforms, but does a “phone book widget” on a mobile will be the same than a “phone book widget” on a PC?
Technorati Tags: j2me, javame, mobilewidgets, widgets
July 26th, 2006
This is a translation of an article that I wrote for a French blog, about “mobile widgets”. It’s a general introduction and description of the widget, and especially mobile widget concept:
So, what is a mobile widget:
A widget is generally speaking a small application, a little bit of code, that does one simple thing but does it well. The second important things about a widget, is that they can be combined together. The last one being the fact that usually, it’s fairly easy to develop a new widget (comparing to developing a full application).
To be able to run a Widget, you need a “Widget Engine”, which is the framework needed to run these micro applications. On the PC, the most popular is Konfabulator, and Dashboard on Mac OS-X. Web applications haves also their own widget, that can run within the browser, like clock, web counter, etc….These applications exists since a long time, it was called previously plugins, components, extensions, gadgets, but the real innovation is that it’s now in user hands: they can combine these widgets to create their own unique application. Typically, the user can choose to have CNN news, Paris weather, a Flicker photo stream, a clock, etc….
This approach fits particularly well on mobile world, where space on screen is limited, and where it’s not easy to switch between applications. Some companies like Widsets, Bluepulse, mFoundry, Bling and Opera have developed some widget engines. Not all of them haves the same approach, even if all of them recognize the filiations with Widget. Most of them are for the moment personal news /RSS reader (Widset) but extremely well done, others allows some interaction with the user (plusmo, mFoundry, etc…). All of these engines -except Opera widget – are for now available on top of J2me. The interest of widget is both for users and developers:
- For the user, he can create his own application buy choosing and customizing his widget set.
- For the developer, he can easily develop and deploy application for end user. Of course, not all application can fit into the widget description, but I believe that in the future, a good combination of Web/Ajax based application and Widget will fill 80% of the needs.
I recommend particularly two applications: Plusmo, which is in my mind on of the most interesting one but with a poor UI, and Widsets, which is the opposite: a great UI but the application itself is lacking of maturity. Of course, I am not any more objective as we (Webwag) also have a mobile widget engine.
I believe that Widget will be the equivalent of “Web2.0″ app for mobile: adapted to small screen size, solving in an elegant way the portability issue, providing real interest for the end user it’s certain that this kind of application will become more frequent in the future months.
Of course, there is still a lot of open question: does a “standard” wil emerge (see C.Enrique post
on this)? Can Desktop be reused on mobile? (I think that the question
is more “is there an interest to reuse desktop widget on mobile”).
If now widgets are in most of the case a way to access to some RSS content in an easy way, I believe that their scope will extend to integrate more interactivity with end user, and conquer more space on your phone sceen!
Technorati Tags: j2me, javame, mobilewidgets, widgets
July 5th, 2006
I’ve just played a little bit with the application, but on the emulator only, and here is my first feedback:
Basically, it’s a kind of RSS reader for mobile, where you select on the server side the feed you want to read. In that case, a feed is called a widget but does not provides any interactivity.
- The first level of UI is really well polished, and gives great hopes about the app.
- The web site is an high end Web2.0 site. From the Web, you can browse widgets, select one, configure it.
- When you have selected your widget set, just press update to update it on your mobile..
But:
- The application does not work on my mobile! (big problem for a mobile app). Still waiting from feedback from the Widset team, but it seems that it’s linked to the usage of TCP which is not open on all operators network, instead of plain old HTTP.
- The first level just show you the icons, gives very few feedback about “whats new”. The onlylinformation that seems to be displayed – and not on all feeds – is the number of new articles in the feed. Once the first “waooow” effect is gone about the UI, you realize that it’s not so user friendly: the button are big but does not carry so much information.
- The “preview” widget from the web is just a static one. In fact, it’s a picture provided with the widget set. It would have been interesting to have a “real” preview
- When digging in, the second level of UI is not very useable too. For instance, on the weather widget, you see a list of days, and you have to select that specific day to see a two line information about the weather…
- The widget can not be configured on the mobile. Needs to go on the web site! Even if I really l ike the Web site, I think that there is plenty of uses cases where you need to configure such app without any access to the web site, for instance, when you have changed your location and want another RSS feed.
- No picture is displayed when reading the feed, except for the Flickr one.
There is an “SDK” available, where you can change the look and feel of the feed: color, icon, etc…
Widset haves a good Web2.0 site, but an average RSS reader: no picture display, lack of browsing methods….
So if I have to compare the three on this race up to now, Plusmo, Widsets and Bluepulse, Plusmo is still ahead of the others….
Upadate: Thanks to some information coming from widsets guys (see the comments), I was finally able to configure my handset. I had to change the default Orange access point to another one – which is strange, as all the other app worked well. Anyway, it works, and I must say that UI is great on mobile. Does not change most of my remarks, but this put another level in the level of polished UI in J2ME….
Technorati Tags: mobilewidgets javame j2me plusmo widsets rss
June 9th, 2006
Google just released
recently his “Google Web Toolkit”:
Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translate your Java application to browser-compliant JavaScript and HTML.
So basically, it’s a toolkit that can be used to write Web2.0 application in
Java, and then translate it into some JavaScript+librairies.
It’s quite nice, writing client web applications in Java that execute in a
browser..Hey, but stop, this reminds me something: yes, the applet, and these
small pieces of Java running in a Web Browser? Yes, sounds very similar,
however, the Applet failed in their objective to be the technology for browser
application. Maybe it was too early and browser / pc capacity were not ready,
but also it suffered from a lack of interaction with the rest of the browsing
experience, while this is much better with Ajax2.0 app.
But basically, were are here: JavaScript/Ajax was just a technical way to solve
previous issue. Honestly, result is great from the end user point of view, but it’s
horrible from the engineering point of view. Writing complex Web2.0 app is a
nightmare, with a lot of different layers (Java, JavaScript, Ruby, Sql, HTML,
XML, etc…), translators, etc…
May be a message for the mobile community, could be also to learn from our
previous mistake, and make what was initially planned for web happened on
mobile: rich client app that can be downloaded and run within a browser, and
avoid this complex multiple layers.
We already have the technologies available on mobile (XML, J2ME, SVG, etc…)
we just need to tight them together in the right way.
I hope that this ideal scenario will happens (through JCP? 3GPP?) but I am
afraid that once again, the fight between standards, companies, etc… will
lead to a situation where nothing will really emerge, and we will leave again
in a world of translators, layers, and complexity…
May 19th, 2006
Does security will raise some complex issue for Ajax based app?
One of the benefits of Ajax is that the “application” does not reside on the client, but is downloaded each time you access to the server eventually with some caching mechanisms. This mean that transparently the application can evolve, include new features, etc…
One of the well know weakness of browser based app, is the fact that these application can not access to local resources of the device, like Bluetooth, address book, GPS, etc…
One of the possible (and probable) evolutions will be to provide some specific API to these applications to access to local resources. Fine, but this raises more the security problem: would you give an unlimited right to any browser app to access to your private data? Of course no, but then, how to manage this: by providing a certificate per session? But disabling access to this device?
For downloaded app, the solution as been solved by putting a certificate mechanism. This provides some advantage, as only the “trusted” application can be downloaded. The disadvantage is that it’s very costly, in
terms of money, time . But in all cases, this can not be applied directly to Ajax based app…
I have no clue on how this will be solved, I am just worried to this issue has not been addressed by promoters of the “full Ajax” solutions for mobile…
Technorati Tags: mobile ajax, mobileajax, ajax, javame, flashlite
Technorati Tags: mobile ajax, mobileajax, ajax, javame, flashlite
April 17th, 2006
There was several interesting discussion, about what is equivalent of “Web2.0″. Some call it “Mobile Web2.0″. My perception is that it will be more “Mobile 2.0″, as the mobile does not imply the same approach as Web. Why? There are fundamental differences now between mobile and web (and mostly from a tech point of view approach):
- User Interface on Mobile is Key: that’s one of the main difference between a PC and a mobile. On a PC, you have primary a keyboard, and a mouse. These are the two main input components, and a big screen to display user interface. On mobile, you have a very limited display, but much more input possibilities: audio, video, picture, movement, environment (Bluetooth), location, but very limited keyboard and mouse equivalent. So the best user experience will probably tightly link to the multimodal capacities of the phone.
- Mobile is more about synchronisation than browsing. The trend now, on the web, is to provide you most of the user experience from a browser. This happens for two reasons: most of the people are now connected with high speed connection, and the emergence of high quality web browser. On mobile, we do not have these two components: connection is not always cheap, not always available, and not
always fast. Browsers are very limited and not really full featured….
So what are the conclusions:
That Mobile2.0 will be in my view a smart mix between several components, able to
- connect to a server to update local content, or to update server content from local data (synchronisation)
- execute locally some complex task, mixing several inputs (local, web, etc…), and store this result locally (to be later synchronized)
From the end user perspective, this will be transparent (no need to care about installing an application). I think that technically speaking, it will be a combination of browsing based technology (typically XHTML) and some smart client like J2me, FlashLite, or just plain voice call or DTMF….
There won’t be any single technical answer to the frangmentation problem, as mobile is an innovative media, and then innovation generate fragmentation…
Technorati Tags: javame, mobile, mobile2.0, J2ME, mobileAjax
February 22nd, 2006
I am following Macromedia (and now Adobe) efforts in the mobile since several years, and FlashLite became more interesting recently. Not due to the introduction of FlashLite2.0, which I do not think is the key point, but due to the support -even partial- of SonyEricsson after Nokia.
That’s why, in this entry, I will try to analyze what could the key success factor (and of course, weaknesses) of FlashLite.
Strengths of FlashLite:
- Good development environment. The Flash authoring tool is a good tool for designer, and allows them to create quickly great animation, very hard to achieve in a non vector graphic based environment.
- Good graphical performance: easy development of UI, etc… A Flash Based UI is easy to do, with great features, fun feedback, especially for mobile phone. I usually do not like Flash based UI on the web, as designer tends to recreate their own metaphor, but one the mobile, there is still a lot of room for UI creativity.
- Proprietary technology. That’s the good side of being proprietary: you can do what you want, include feature without asking the community, making mistake, solve them, choose to support something, etc… very quickly. But there is a downside!
What could slow down or eventually kill FlashLite:
- Macromedia/Adobe just start to really experiment the issues of platform interoperability. For instance, reading the notes from FlashLite1.1 documentation , and from the experimentation I have on my phone, I have realized that even in the Flash world, things are not so easy…
- On most of the phone, player CAN NOT be updated! So if shipped with million of phones, then it will remains for some time. No nice screen asking you to update to FlashLitex.x if a feature is not present.. That’s the same problem with MIDP* Proprietary technology! And operators do not like this. If the choose Flash, and then it became a market request, than they are stuck with Macromedia.
- FlashLite, in my view, is still a Designer technology. I recently do another attempt to do something useful using FlashLite, and no doubt, development environment is still designer oriented, and not developer oriented. No doubt that’s a clear choice, and one of the strength of Flash, but this means also that this will restrict general usage of the technology. Learning curve will probably be bigger for developers.
- A success of SVG/J2me…SVG just manages the animation part, and the spirit is that J2ME manage the behaviour. On the paper good, but there are several issue: first, there is not yet a good environment development (like Flash) to enable this. Then, J2me app must be downloaded and installed. Then can not add downloaded code on the flight. This limits a lot the possibilities. I guess that something like a SVG+a scripting language (with a J2ME based interpreter) might solve the solution.
Don’t take me wrong. I think that 2006 will be a big year for Flash, and I will try to investigate more the technology, as it provide many great advantages today, compared to alternative.
My ideal whish is to see the emergence of a better “cross technology” compatibility/communication, between the major ones: JavaMe, which is the clear leader, FlashLite, a true challenger, and the new generation of mobile HTML (the Opera Mini trends, Mobile Ajax, etc….). This does not happens yet…..
Technorati Tags: FlashLite, JavaMe, J2me, Wireless, MobileAjax
February 1st, 2006
Just for fun, I have developped a small Widget to access to the XBoxLive Gamer Card. You can download the app, it contains the full Widget framework but with just this card, so not really optimized…
You can download it here, but notice…jsut tested it on K700, no guaranty about portability!
XBoxLive.jad
XBoxLive.jar
The widget is code around 45 lines, thanks to the rest of the framework….
Usage: start it, and select “Configuration” from the menu and put your tag, or a friends tag, and press ok….
Technorati Tags: XBoxLive, WirelessGame, MobileWidget, Widget
January 26th, 2006
If you follow my blog, you have probably seen that I’ve started to look at the concept of “Widget on Mobile”, Micro Widget (or Mobile Widget) with this: MicroWidgets is on the Way.
That’s why this BluePulse announce seemed to me quite interesting. The ideas seems to download “widget”, on your mobile, and get revenu from this. But after trying it, I’ve been a little bit disapointed. The so called widget seems to like more as Web pages. I did not take a look at the SDK yet, but seems to me more an attempt to surf on the Widget wave than a real innovative product. Yes, just like other said, I might be missing something but this is definitevly not Konfabulator for mobile phones.
One of the issue is that there is no caching between sessions, so you do have to reload each time the “pages”, and “pages” are not grouped together, so it really gives the feeling of a browser, without the features!
Regarding business model (which is from what I see not really in place, but planned), it seems subscription based par “channel”, similar to what others are doing (typically imode).
Technorati Tags: mobilewidget, ajax, javame, j2me, widget, microwidget
January 23rd, 2006
In this post: why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development, Ajit Jaokar explains his view on this topic.
And like Tom Hume in this paper, I disagree with most of his conclusion.
I am a big fan of Ajax (even if I think it’s totally over hyped), and I also personally think that it haves a great potential on mobile, but this kind of statement can only make me react….
His argument is based on the fact Ajax will solve the three following issues:
a) The problem of market fragmentation
b) Porting woes (specific to downloading applications like those built on J2ME)
c) Application distribution without ‘walls’
That’s true that market fragmentation is a big issue on mobile. But he did not give any clue why Ajax (so browser based application) will do better than J2me to solve market fragmentation.
The porting woes are also a real problem in mobile world. But this statement is totally false:
To make your [30] games available worldwide in five languages and on only 50 devices, you would need to create 7,500 different builds. At $2,500 per build, you would require a budget of nearly $19 million simply to handle porting.
First, this is totally wrong. Usually porting costs represent around 100% of the price of the game development (in the Java world, excluding different version like 2D/3D). It’s already incredibly huge, but way below this!
But can Ajax solve this issue? For instance, is Ajax used today to do games? Except very simple casual concept games, not really. And on PC there is usually one binary for a game (and one per platform, PC, Xbox, PS, etc…) . While on Ajax there are already several variant depending of the browser (IE,FireFox, etc…). So if Ajax fragmentation appears already on PC, how can it be better on mobile? Ajax developer will face the same issue of usability, screen size, bugs, etc…on numerous mobile platform. Just like J2ME: it’s easy to write a simple cross platform proof of concept. It’s much harder to have a real application running on all devices.
I predict for “Mobile Ajax” the same pattern than for other mobile technologies:
- first phase: the dream! (write once/run anywhere)
- second phase: the deception (it does not work as expected except on developer device)
- third phase: manual porting/adaptation for every different device
- fourth phase: maturity (a mix of automatic porting with process, devices knowledge and improvements of client )
It happened with Wap, it happens with Java, and it will happen with “MobileAjax”….
So:
- Ajax can not be used to do all the application (and especially not games)
- It will NOT SOLVE the fragmentation issue
Last argument was about application distribution: again, I have no clue why a browser based app would be more widely spread than a downloaded app? The issue is not how to get the application, but how to make it visible: deck placement, advertising, etc… Again, Ajax,J2ME, Brew, etc…issue remains the same…
And do not forget one things also very specific to mobile: even if it’s a very connected device, it’s not always connected to the internet. The difference between offline/online content (through preloaded things, download, caching mechanism, etc…) is much more important than on a desktop. That’s also partof the intelligence of the application, specific to mobile.
Another interesting comment, is why Google (the one who put Ajax in the spotlight) and Yahoo did not choose Ajax to do their mobile client? (if you’ve ever tried to run Google Map on OperaMini, you know why! ).
And may be there are more creative way to evolve. I really think that Ajax and J2ME offers a perfect mix of technology to create much more creative application, Ajax for the purely “web based” part, J2ME for the more “client based” approach… Again, the MobileWidget experiment is another example of attempt to use this mix between J2ME, XML/HTTP request, and a scripting language in a different way…
Update: see C. Enrique Ortiz ajax wireless javame
January 8th, 2006
I’ve just decided to start to work on something called “MicroWidget”. MicroWidget will be the equivalent for mobile of Widget, Gadget, or other inspiration source on the mobile….
Basically, it’s an XML based rendering engine with a tiny scriping language. I’ve used FScriptME as a basis for the scripting language. FScriptME is very limited, but it’s a good start. I’ve added some pseudo object oriented faciclities, like myText.data=”some text”, and some usefull xml parsing function.
As an example, here is the widget code for a Clock like widget:
The code is pretty short and can be easily understood. The only difficulty is the function “explode”, who create an array from a string.
Of course, there are plenty of other usefull function to retrive some xml data, to parse them, etc….
First result are really encouraging, but generate some interesting issue about interface design…
Technorati tags: JavaMe J2ME Ajax Widget Micro Widget
December 28th, 2005
I will go also through my little prediction for 2006. Most of them are based on my previous post, and yes, it’s Christmas break:
- Google will buy a Opera(if not already done): the “OS” of Google is the browser, so they need to provide one on platform who does not have one, or a good one. That’s why I predict that they will buy a browser company typically Opera. The interest of Opera for Google is that they also have a good mobile offering.
- But Google will move from the “Good side” to the “Evil Side”. Too powerfull, too big, too smart….
- The “big three”, Yahoo, Google and Microsoft will enters more strongly into mobiles. All will provides much better access to their service to everybody mobile.
- Location based service will increase, especially in North America, thanks to GPS enabled mobiles. In Europe, such mobile will start to appear
December 27th, 2005
2005 was probably the most exciting year since 2000 for the Web, thanks to the thousands of new projects, most of them based on the usage of AJAX to create a new and compelling user experience. One interesting question for me, involved in mobile, is what will be the impact of this revolution for mobiles?
Well, seems that the Ajax buzzword will be in all mouth in the coming months, and Opera is already surfing on this.
Thirst thing, is do we need Mobile Ajax?
I think that with the generalisation of data network (GPRS,EDGE or 3G), the services will be more and more interactive. But the current technologies are far from providing a compelling user experience on mobile. Wap (or even HTML) applications look like ’99 Web app (for the best ones). So I believe that looking at what’s happening on the web, many people will provide these improvements to mobile, and this will be an improvement.
And one side note: Google local for mobile IS NOT a Mobile Ajax application (just like J2MEMAp). It’s just a monolithic application created for mobile, which can not be updated, or changed OTA (unless you reload it). I guess that I should define what I think is mobile Aj
So what are the various technologies available, or do we need new ones?
A first answer is to say that we already have one technology that could fit to Ajax requirement: be able to execute locally a small program downloaded remotely to add interactivity in “web pages”. J2ME (oh, sorry Mr Sun, JavaME) seems to be perfect for this. It’s a small bytecode, cross platform, web oriented, etc… However, J2me (in fact CLDC) failed in one important topic: the inability to download OTA some new byte code. So an application, once downloaded, can not be easily changed, modified, etc…. And even worst, you can not jump from one app to the other: from a calendar to the address book for instance. So if you want to do something great, you need to create a -relatively- big monolithic J2ME application. And I do not speak of security issue (see below).
One the other hand, there are plenty of advantage to J2me, and this could be a good candidate for being the scripting language for mobile Ajax application, or the framework basis for this, but it needs to evolve a lot if he wants to achieve this level.
One option (the one used by Opera) is to write a browser in J2ME who contains some Ajax component. Honestly, I did not take a deep look at the opera mobile (the J2ME version) right now, but I doubt that the have a scripting engine in this version…And what will we have at the end: an interpreted VM being able to run interpreted scripting language… And I am sure the several other initiatives are one the way.
The alternative is not numerous. Flash lite could be a candidate, but the first issue is the deployment: very few handsets yet have it right now. But technically speaking (and here, I am not a FlashLite expert) it seems that many of the J2ME limitation does not exist anymore, especially the one concerning the limitation of an application to one single binary. And probably the first truly mobile Ajax experiment will come from here.
But whatever is the option, I except a lot of buzz on this, conference, announces, etc for the second half next year! So let’s be ready for the Ajax wave on the mobile,….
Technocrati Tags: J2ME JavaMe Ajax MobileAjaxFlashLite
December 4th, 2005
Next Posts
