You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by lookman sanni <lo...@gmail.com> on 2009/05/19 02:23:37 UTC

Weekly progress - GSOC09

Week 3

The following has taken place between the 11th and the 17th of May 2009
*All services are now consumed…*

Android Store progressServices side:

I’ve finally found a way posting and parsing the atom feeds exchanged
between the android client and the web store using android’s native
DefaultHttpClient, http client methods (HttpPost, HttpGet, HttpDelete), and
the SAX API. The atom feed is then considered like a simple XML stream.
The following methods have been implemented for the ShoppingCartProxy class:

   - addItem()
   - clearCartContent()
   - getItems()
   - removeItem()

And a new package named services.atom.xml has been created with the
following classes:

   - AtomXML wth the following static methods:
      - getItems()
      - performDelete()
      - postItem()
   - CartItemHandler which is used to parse the atom feed.UI side

   I spent couple of days tweaking android to create a custom layout for the
   catalog and the shopping cart’s ListViews in vain. In fact, i was trying to
   make it look like what’s on the picture below so that only the buttons will
   be clickable. I finally ends with nothing, and i think, i’m finally going to
   make each ListView row directly clickable, but with a small imageview at its
   right side (red cross for the shopping cart, and green plus for the
   catalog). I guess it’ll look on that way a little bit prettier than now.


   [image: custom_layout]


   Porting Tuscany’s module onto android

   I’ve been quickly briefed on the retrotranslator, and his feature of
   converting Tuscany’s module to get working on android. Sounds very amazing
   how it may automatically handles apis android doesn’t support natively, and
   am already looking forward getting deeper into it. Well, *how does it
   work? Is there any location for the source code?* I guess i’ll have to
   learn a lot from Oscar about that!!
   Seems like another alternative will be to rewrite each of the extensions,
   or should i say adapt each module’s source code to the android platform and
   limit non supported API imports. In that case, it will be interesting to
   build a priority list of the extensions to be ported, and after importing
   each one, implementing a use case to illustrate it or an adaptation of any
   existing use case already provided for desktop environment.
   I’ll be analyzing both ways till the end of May, and according to the
   constraints i’ll choose with the community’s help a way dealing with all
   this.




-- 
Best Regards

Lookman SANNI
http://blog.lookouster.org
MSBI Intern at Umanis Tours Services;

Re: Weekly progress - GSOC09

Posted by Oscar Castañeda <oc...@apache.org>.
Hi Lookman,

As suggested on the thread for your weekly (2) update, please consider
making steps for things you would like me to test. If no steps are required
then a brief description, and possibly sources for further information,
might be useful (to me or anyone wanting to test and/or reproduce).

With regards to porting SCA to Android, please see comments inline below.

Way to go on the community bonding period! I think you made substantial
progress and got up to speed with your project. Now we have the official
start of GSoC coming up this Thursday May 23rd. So, congrats and keep up the
cool stuff!!

On Tue, May 19, 2009 at 2:23 AM, lookman sanni <lo...@gmail.com> wrote:

> Week 3
>
> The following has taken place between the 11th and the 17th of May 2009
> *All services are now consumed…*
>
> Android Store progressServices side:
>
> I’ve finally found a way posting and parsing the atom feeds exchanged
> between the android client and the web store using android’s native
> DefaultHttpClient, http client methods (HttpPost, HttpGet, HttpDelete), and
> the SAX API. The atom feed is then considered like a simple XML stream.
> The following methods have been implemented for the ShoppingCartProxy
> class:
>
>    - addItem()
>    - clearCartContent()
>    - getItems()
>    - removeItem()
>
> And a new package named services.atom.xml has been created with the
> following classes:
>
>    - AtomXML wth the following static methods:
>       - getItems()
>       - performDelete()
>       - postItem()
>    - CartItemHandler which is used to parse the atom feed.UI side
>
>    I spent couple of days tweaking android to create a custom layout for
>    the catalog and the shopping cart’s ListViews in vain. In fact, i was trying
>    to make it look like what’s on the picture below so that only the buttons
>    will be clickable. I finally ends with nothing, and i think, i’m finally
>    going to make each ListView row directly clickable, but with a small
>    imageview at its right side (red cross for the shopping cart, and green plus
>    for the catalog). I guess it’ll look on that way a little bit prettier than
>    now.
>
>
>    [image: custom_layout]
>
>
>    Porting Tuscany’s module onto android
>
>    I’ve been quickly briefed on the retrotranslator, and his feature of
>    converting Tuscany’s module to get working on android. Sounds very amazing
>    how it may automatically handles apis android doesn’t support natively, and
>    am already looking forward getting deeper into it. Well, *how does it
>    work? Is there any location for the source code?* I guess i’ll have to
>    learn a lot from Oscar about that!!
>
> Retrotranslator is documented in [1], which also includes the link to
download the tool. I'm not sure if sources are available, but in case they
are not we might be able to get them from the author, Taras Puchko. Taras
was very helpful last year on my project, and so you might want to consider
contacting him through the Android developer mailing list. Of course, I'm
also happy to help with any retrotranslator'ing, and so we can discuss if
needed, before seeking help elsewhere.

[1] http://retrotranslator.sourceforge.net/

>
>
>    Seems like another alternative will be to rewrite each of the
>    extensions, or should i say adapt each module’s source code to the android
>    platform and limit non supported API imports. In that case, it will be
>    interesting to build a priority list of the extensions to be ported, and
>    after importing each one, implementing a use case to illustrate it or an
>    adaptation of any existing use case already provided for desktop
>    environment.
>    I’ll be analyzing both ways till the end of May, and according to the
>    constraints i’ll choose with the community’s help a way dealing with all
>    this.
>
>
> This was also suggested last year. Despite significant help from Adriano, I
could not get the modules completely running on Android. Every time there
was some API or non-supported feature that got in the way. However, that may
no longer be the case now, especially since Android is now fully open-source
and new versions have been released. I encourage you to analyze this
alternative, and choose the one you find to be most promising.


>
>
> --
> Best Regards
>
> Lookman SANNI
> http://blog.lookouster.org
> MSBI Intern at Umanis Tours Services;
>



-- 
best,
-oscar

Oscar Castañeda
http://people.apache.org/~ocastaneda<http://people.apache.org/%7Eocastaneda>