Hi, I will try to summarize the modifications I've done on SCA to run on Android so far.
As I aforementioned, most dynamic instantiations were being done on host-embedded module. However, there was another modules which were also using the dynamic instantiation and I had to modify too. For example, the extensibility module, where I had to add the string lines directly on the code as they couldn't be read from the file. OK, so far so good. But I have found another limitations. But before to explain it, let me explain how android deals with the app resources: On the android app project, there is a folder called res, which can only contain certain folders: xml, raw, strings, etc (I don´t remember the other, but they are predefined). And these folders can only contain files that are named only with letters, digits and the '_' character. Yes, the resource structure is very limited, but there is a reason. Each file is packed and compressed into a single file, then when the android app is compiled it auto generates a class named R, which has static subclasses named with the name of each folder contained on the res folder. Each subclass has static int fields that points to the beginning of each file in the compressed file. Example: res/raw/filename is converted to R.raw.filename So, as each int field has the name of each file, the file names should only be composed of those characters described above. Then, no ".xml", ".composite", ".xsd" is supported, as they all contains the '.' character on their names. Each folder name describes how the android converter will compress the files contained in it, for example, the files contained in the "xml" folder are compressed to a special binary xml format and etc. The only folder that do not have the files compressed is the "raw" folder. Every running app on Android is called context, which is an instance of a class that extends the Context class. In the same package this class is defined, the R class is also defined. To access the files that are pointed by the R class, the context instance is needed: contextInstance.getRescources().openRawResource(R.raw.filename) SCA works with resources practically only using the URI/URL. However, there is no way to access this resources using an URL object, because there is no defined protocol to access this files. Trying to get the calculator sample running on Android, I placed the calculator.composite file in the raw folder. I had also to remove the '.' character from the file name, so I renamed it to "calculator_composite". So, to access the files pointed by the R class, I "implemented" a new protocol, called "dex" (how the Android app file is called, equivalent to Java jar files ). The dex protocol is defined as: dex://<context_package>/<resource_folder>/<file_name> <context_package> = package where the app context and R class are located <resource_folder> = folder where the file is located <file_name> = the file name Valid example1: dex://calculator.android/raw/calculator.composite Valid example2: dex://calculator.android/raw/ Valid example3: dex://calculator.android/ PS: the implemented protocol replaces the last '.' character when trying to access the file...the '.' character is accepted, though the SCA Android version would be compatible with the SCA Java version that searches for files which ends with ".composite" and not with "_composite" I implemented some classes to support this protocol, they are located at [1]: DexURLStreamHandlerFactory.java<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/DexURLStreamHandlerFactory.java>: the instance of this class is set as the app URLStreamHandlerFactory when the SCADomain is loaded. This class creates the DEXURLStreamHandler and allows the dex protocol to be a valid protocol. DexURLStreamHandler.java<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/DexURLStreamHandler.java>: Create a DEXURLConnection from a dex URL object. DexURLConnection.java<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/DexURLConnection.java>: Provides the access to a file described on the dex URL. DexResource.java<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/DexResource.java>: Provides some util methods for dex resources. For example, from a dex URL, which describes a folder, it is possible to retrieve all the files in this folder. ContextRegistry.java<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/ContextRegistry.java>: as a context reference is needed to access the resources, when invoking SCADomain.newInstance(Context, String), the SCADomain register the Context object in the ContextRegistry and unregister when the SCADomain.close() is involked. This way, when URLConnection tries to access the file stream, it uses the context object registered in the ContextRegistry. Each context is registered in a map by its package name. With the dex protocol implemented, I could access the "calculator.composite" file in my app resource: SCADomain.newInstance(contextReference, "dex://calculator.android/raw/calculator.composite") I was getting another exceptions when the SCA tries to access the STAX classes. It was happening because the Android SDK do not include some standard java classes. So, as the missing classes were not so complex classes, I copied them from JDK source to [2]. This classes have CDDL license, does anybody know if it is compatible with ASL license? ================================= Getting it "running" It is not really running(I will explain below), but I will describe how to config the eclipse workspace to work with the code I have uploaded on [3]. 1- download the modified code from [3] and install them 2- download the SCA modules from [4]. I'm working with an old revision, the 643746, I recommend to checkout this revision too, I haven´t tested the modified code with earlier revisions. 3- on the folder you download the SCA modules, run: mvn clean install -Dtest=no mvn -Peclipse eclipse:eclipse -Dtest=no 4- download the Android SDK and the eclipse plugin at [5] 5- open the eclipse and create a new workspace, do not forget to set the M2_REPO variable on it. 6- import the projects included in the files you've download from [3] 7- import the SCA module projects (exclude the saxon module) 8- There should be a lot of errors some modules, include the Android library on them, it should fix the problem If everything goes fine (and if I have described everything correctly), when you run the calculator-android project as an "Android application" you should get an exception, that was generated initially by a NPE thrown by org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider constructor. This is caused because the latest Android SDK does not support the Reflection API yet. So, the SCA cannot check the @Reference annotations (I commented the code which tries to read the annotations, so when the execution reach this constructor it throws the NPE). However, the Android developers say the next SDK release will support the Reflection api, they do not tell when it will be released, they just say it will be soon :S This is the summarize what I have done on running SCA on Android so far. Suggestions/contributions will be appreciated : ) I expect I have explained everything correctly. Sorry for my bad english, I'm almost sleeping on the keyboard :o Any questions/doubts about what I have written here, just let know ; ) Kind Regards, Adriano Crestani [1] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/org/apache/tuscany/sca/android/ [2] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/javax/xml/ [3] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/android-jdk-classes/src/javax/xml/> [4] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules [5] http://code.google.com/android/download_list.html On Thu, Mar 20, 2008 at 9:43 PM, Adriano Crestani < [EMAIL PROTECTED]> wrote: > I have started to change the SCA code. > > Initially, the objects instantiated dynamically were not being > instantiated, because info about which class to instantiate is extract from > some text files contained in SCA modules' jars. Unfortunately, when Android > converter converts the SCA modules' jars to .dex files, it ignores the > non-class files, and they are not included. It happens because Android has a > very specific way to store the app resources, which is completely different > from Java. > > Though, as Luciano suggested, I started to modify these dynamic > instantiation for static. It's working for now : ). All these modifications > were made only on host-embedded module code, which I have copied into [1] > and renamed to host-android. > > Also, one of those static instantiated classes was trying to access the > javax.naming.InitialContext in its constructor, but it's not supported by > Android and I commented the code. As this class belonged to SCA core module, > I also copied this module into the mobile-android sandbox and renamed the > module to core-android. > > So, all the modifications made so far are in the [2]. > > Now, as I was expecting, I got some ClassNotFoundExceptions on SCA code > when it tries to use the Java XML API. It happens because Android implements > only a small part of this API. So, next step is try to adapt the SCA XML > access into Android way to access XML. Does anybody know some other XML API > that is javax.xml independent I could use instead of Android one? > > Suggestions? : ) > > Adriano Crestani > > [1] > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/host-android/ > [2] > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/host-android/> > > > > > On Mon, Mar 17, 2008 at 1:41 PM, Luciano Resende <[EMAIL PROTECTED]> > wrote: > > > I'd probably categorize the experiment we are doing now, as a learning > > experience to familiarize with the Mobile environment available in > > Google Android. For this, we have choosen to try running one of the > > simplest samples we had (calculator) in the Android JVM > > environment.... In the long run, the idea is to have a more > > light-weight "sca mobile core/runtime" available, similar to what we > > did for Web 2.0 (implementation-widget) and described by Mike below. > > > > But it's indeed good to discuss these items with the community, would > > be also good to have the community contributing requirements/scenarios > > for a Tuscany mobile story. And we are all open and welcoming any > > help. > > > > > > On Mon, Mar 17, 2008 at 8:22 AM, Mike Edwards > > <[EMAIL PROTECTED]> wrote: > > > Brandon Werner wrote: > > > > Can you explain the benefit of moving SCA/SDO over to the Android > > platform? > > > > I can understand wanting to have the ability to consume simple XML > > services > > > > and perhaps consume disconnected datagraphs, but I don't understand > > why the > > > > world wouldn't want a more light-weight way of doing that than > > ripping out > > > > something that was meant for the JEE / JSE. > > > > > > > > <snip> > > > Brandon, > > > > > > So you think that a device using the Andriod platform is likely to > > want > > > to use services and a service-oriented approach to building > > > applications. But you think that SCA is too "heavyweight"? Is that > > > simply a question of the size of the code involved (I note that the > > core > > > of Tuscany is quite small) or is the SCA approach too "heavyweight" > > in > > > some other sense? > > > > > > I wonder if you've taken a look a the implementation.widget > > exemplified > > > in the Tutorial demo code? This applies SCA principles to AJAX > > widgets > > > running in the browser - simplifying the connectivity a great deal > > (in > > > my opinion) and yet adding little overhead. > > > > > > In the longer run, we may want to look to do something similar for > > the > > > Android platforms, perhaps with Java rather than the more limited > > > JavaScript components. Starting with the current SCA package seems > > > reasonable to me - once we have experience with how that works, we > > will > > > have a better idea what needs to be changed and tailored for the > > Android > > > platform. > > > > > > > > > Yours, Mike. > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > Luciano Resende > > Apache Tuscany Committer > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > > http://lresende.blogspot.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
