Stage 4

Running Tuscany Calculator on Android

As said in my previous post, i finally abandonned the idea of tweaking dalvik’s java API, and faced direcly the root problem, which is the dx utility. I performed a quick tweak to it’s main script, and comment the section where javax, and java subpackages are blocked. Up now to debug!!

Blocking issues due to android platform

  • Thread.currentThread().getClassLoader() is frequently called in Tuscany’s code, and unfortunately it always return null on android. To fix this, i had to pass dalvik classLoader from the client side to all places in Tuscany’s modules where classLoader is recquired.
  • ClassLoader.getResources() doesn’t work neither under android. Dalvik’s pathClassLoader may be a solution. But as we’re working on a lightweight system, it’ll surely be heavy to open stream on about a forty services files (needed to run calculator). Instead, i just set up system properties so that each service name will represent a system property and it’s implementation class would be the property’s value. This will involve no code refactoring on tuscany’s modules as for resolving services, system properties are firstly checked. The properties’ list and their corresponding values can be found here
  • org.w3c.Node implementation under android doesn’t contain getTextContent method. I replaced all calls to it by getNodeValue(). Same thigng for Node.lookupPrefix() which becomes Node.getPrefix().

Current state

Definitions.xml loading’s step is performed successfuly. An implementation has been coded to handle APK files : “The  APKContributionProcessor” working somehow like the existings JAR and Folder Contribution processors. I’ve also added apk to Contribution package types. For now, the APKContributionProcessor is a bit “wobbly”, but I think when the calculator-android will be running and all constraints mastered, i’ll think of a way modelling all this properly.

  • APK structure: An archive uncompressable with any archiver, which contain all resources attached to the sources, and a classes.dex file resulting from the dexification of all java sources.


Long term: perspectives


Instead of continuing with the current host-android or host-embedded ( i don’t know yet what’s exactly inside), i suggest we rewrite it like an android application that’ll setup needed system properties on a world readable way ( to make it available to any other android application), and bootstrap at build time resources files into a given directory on the android system. These resources files will be needed in addition to system properties as we need to provide a description of all services (classname, servicename, url).

The Calculator-android project
The one existing is targeting an older version of android sdk. I’ve just recreated a new project, by importing services sources from the sample calculator.

List of needed tuscany’s modules for running calculator-android

assembly-xml
assembly-xsd
binding-sca
binding-sca-xml
contribution
contribution-impl
contribution-java
contribution-namespace
contribution-xml
core
core-databinding
core-spi
databinding
databinding-jaxb
definitions
definitions-xml
endpoint
extensibility
implementation-java
implementation-java-runtime
implementation-java-xml
implementation-node
interface
interface-java
interface-java-jaxws
interface-java-xml
monitor
node-api
node-impl
policy
policy-xml
policy-xml-ws
sca-api
sca-api-extension
workspace
workspace-impl
workspace-xml
xsd