Thomas Menguy

Capuchin: Sony Ericsson strikes back in the Application Environment...is it a strike? What does it mean for the development platforms fragmentation?

Capuchin: Sony Ericsson strikes back in the Application Environment...is it a strike? What does it mean for the development platforms fragmentation?

[SonyEricsson is promoting a new Application Environment mixing Java ME and Adobe Flash Lite: Capuchin. Blogger Thomas Menguy tries to describe it and evaluate what “yet a new” development platform means to the industry ].

Sony Ericsson had a nice webinar last Thursday, interesting held through Adobe E-Seminar:

“Flash Lite meets Java ME on Sony Ericsson phones with Project Capuchin”.

At least now we have some information about Capuchin, and I’ll sum it up for our beloved busy executives:

  • A technology that allows developers to make the UI using Flash Lite and code the business logic and access to the platform services with Java (ME).
  • A development environment with PC based tools (Adobe CS plugin for flash and Eclipse plugin for Java), simulators and a specific runtime embedded in SEMC phones.
  • The deployment is done using the well in place Java deployment environment (jar are used, same signature, etc).

Here is first a transcript of the capuchin webcast, then as a conclusion I’ll throw out my thoughts about this and its impact on the industry (if you are still there…).

Project Capuchin Web Cast transcript

Flash  Lite from an SEMC perspective Java ME from and SEMC perspective
Pros

  • Tools
  • Community
  • books, forums, tutorials
Pros

  • Wide platform access: JSR’s
  • Security: MIDP protection
  • Distribution infrastructure using JAR
  • Wide adoption language
Cons

  • Limited system services access
  • No security solution
  • Lack distribution channel
  • memory/cpu consumption
Cons

  • Lack of designer oriented tools
  • no rich UI framework
  • difficult to keep separation between presentation and service layer
  • Designers dependent on programmers in UI dev

 

 

Capuchin is about mixing those two worlds, and enforce UI designers and developers relationship.

Why the Capuchin name : it is a monkey like tamarin…the name of the Adobe Action Script VM.

Here is a high level architecture presentation of Capuchin:

7780@7778_abd3760e87945bde67034bb5ed3598e5

Flash content is embedded into a .jar and can be launched by some Java code, then, thanks to the Capuchin API the Flash Action Script can access the various JSR or any other Java class of the project.

 

Here is below how an accelerometer API may be available in the Flash Action Script of a Capuchin Application:

7784@7778_f937de229219b9d2683fe7a22a6a9321

The Capuchin API works both way: flash to java and java to flash.

What Capuchin is bringing:

Flash development:

  • Extend current limited APIs with the use of JSR
  • Secure Flash application
  • Deploy flash as java games, distribute Flash content through existing java distribution infrastructures

Java Development

  • Clear separation between business code and UI
  • Nice development tools
  • Professional UI tools

How to use Capuchin:

3 main ways to do:

  1. Packaging pure Flash Lite content using jar
  2. Java Midlet using Flash Lite for the UI layer
  3. Java Midlet using Flash Lite for PARTS OF THE UI

Adobe has a nice technology: mxp, format for packaging extensions. Capuchin use mxp to package the APIs that will be mapped into the Action Script.

7786@7778_79f373c414bd15832cf7ca14d9935a06

There is an Eclipse Capuchin Plugin to create those APIs declaration (see above) as they will be usable in the Action Script written in CS3. This tool outputs an XML file which will be used to output Java Classes for the java part to be implemented …. and Action Script classes to be used in CS3.

7788@7778_9d19ae88d89cbdca0b1f8e45adc86657

Everything is then packaged in a .mxp installation package. SEMC will provide some mxp already (Bluetooth , others…)

Demo time:

The webcast then featured a demo:

swf2jar :

Goal here was to show the tool to convert a swf to a jar, swf2jar: very useful for packaging because a flash game today…end up in the image folder when deployed in a SEMC phone :-)….

Calendar component:

Project Capuchin plugin for CS3, with mxp packages. The intent here was to show how to use Java services in a Flash Lite content

7790@7778_88874502177f3aa879cfe431cf6ff8ec

There are some “Platform components” in the library:  in the AS editor, it is possible to import for example the package com.sonyericsson.capuchin.calendar.Calendar

… to import the Platform classes,  so it is now possible to use the Calendar class as a normal Action Script, even if it is a Java Service.

 

One word about the toolchain future:

7792@7778_6d2f0256d465703e4a591673ceac864c

In gray: Not done today:

  • Flash Emulator will be connected to Eclipse to use java services directly and not only stubs
  • UI library: a flash widget library will be developed
  • Connect everything to the existing SEMC phone emulator
  • Work with adobe so that in device central, when a SEMC phone is selected the list of available mxp would be provided.

What will be published soon:

  • First phone : C905, compatible with capuchin APIs
  • Capuchin APIs,Java Classes
  • swf2jar tool
  • Capuchin API generator , eclipse plugin
  • mxp packages with source code
  • capuchin test and video tutorials
  • demos applications

=>check here http://developer.sonyericsson.com

(final: October)

SEMC Capuchin will be present at Adobe MAX in San Francisco and in Italy in December!

Some Q&A with no major questions…mine were not answered:

  • What is the implication of Adobe in this project?
  • What is the implication of Esmertec in this project?
  • Is there a roadmap to have Capuchin on other platform than SEMC ones?

 

Some points about this initiative:

 

  • SEMC has already done a large part of their applications in their feature phones in Java, and they have a strong Java commitment with Esmertec, so on SEMC phones Java is the preferred development method internally….and now with Capuchin, externally as nearly all the platform services are already available in Java.
  • With the point above, and knowing that some part of the SEMC feature phones themes are already in Flash, merging Flash Lite and Java was a natural choice for SEMC

 

  • Flash Lite choice is the only one possible for today mobile phones (CPU/Memory)…but is really not a complete and efficient UI application frameworks, it lacks …widgets! So SEMC plan to develop some new ones, hum wait, Adobe Flex is not about that? Bringing application development to Flash?

 

  • Not sure about the porting of such a technology on other platforms than SEMC … but from my knowledge only another one has made the Java choice: Google Android where all the platform services can be accessed through Java, but I don’t see any incentive for SEMC to port it to Android

 

Conclusion

So we have a new Application Environment, with its own SDK, that will certainly be only available on SEMC platforms….Capuchin one will complete this never ending list:

  • iPhone native/iPhone SDK
  • iPhone Web Apps
  • S60
  • Nokia Qt
  • UIQ (oups, RIP)
  • LIMO
  • Maemo
  • Motorolla WebUI
  • Android
  • J2ME (and all its flavors …)
  • Capuchin
  • Flash Lite
  • Flash/Flex/Air
  • Brew
  • WinMob
  • PalmOS
  • BlackBerry
  • …and so on…

 

Are we still talking about cross platform development? About consolidation and standardization?  NO

The industry is pushing the other way, and really this is NOT AN ISSUE.

Services and applications developers have learnt how to reuse code across platforms, how to architect their code and services so that it is easy to change only the presentation and the adaptation to the platform: after all developing a UI for a 800*480 screen and a 176*220 is just something completely different, and really not a big deal if your UI is uncorrelated from your services; Capuchin helps that, as many other technologies.

All those new Application Environments are bringing to Mobile Platforms  great core value for services deployment :

  • openness
  • great tools, ease of development
  • focus on user experience and UI
  • deployment/packaging/distribution strategies
  • security

And we don’t want a “one size fits all” environment, it is simply not true in an industry where the forms factors, capabilities and designs are so vastly different. Differentiation is key in this market, just open the platforms with nice and open development technologies, it is enough!

One big trend we can foresee also is that the platform vendors have no more software complex, and when you look at the list above, nearly all the initiative are coming from OEM, and not really from pure software companies (notable exceptions: Android and WinMob)….PC based paradigm seems soooo far away!

©2016 VisionMobile Ltd