tesi di laurea Developing Google Android Mobile Clients for Web Services: a Case Study Anno Accademico 2007/2008 relatore Ch.mo prof. Stefano Russo correlatore Ing. Marcello Cinque candidato Vito Daniele Cuccaro Matr. 885/83
Main issue Is the new Google Android platform mature for developing mobile clients for Web Services? Goal of the Thesis Evaluating the Android platform through a case study (porting of a J2ME client for accessing Wireless Sensor Networks). Contributions Pros and Cons of Android for WS mobile clients. Fitting and Testing of the KSOAP solution for WS on Android. Proposal of a new Android-specific design pattern (AVA) for translating the popular MVC pattern.
Background: Web Services The most common implementation of SOA Operational Model Key benefits: Accessible by anyone, anywhere and from any device B2B and EAI support Dynamic location and invocation of services Interoperability among heterogeneous applications Standard protocols and data exchange format Core Standards XML and ebxml WSDL and UDDI SOAP, the de facto standard for invoking Web Services
Background: The Google Android Mobile Platform A software stack for mobile devices including OS, middleware and key applications Key features: Developed within OHA Open source under Apache license Laying on a Linux 2.6 Kernel Applications written in Java Has its own APIs (as well as some of Java) Uses its own VM (Dalvik) Software Stack
Developing an Android Application Main components: Activity Service Broadcast Receiver Content Provider Other key concepts: Intent Intent Filter Notification Manifest XML-defined GUI Application Lifecycle Toolbox: Eclipse (or NetBeans) plugin Full-featured SDK with Debug Monitor Device Emulator Online Doc and Support R.java
Android and Web Services: state of the art No native solutions available yet (SOAP APIs for WS invocation) Main Developers proposals Homemade solution: HTTP connection + manual XML parsing (SAX) kxml-rpc (lightweight solution) KSOAP KSOAP A popular open-source mobile-oriented oriented SOAP implementation Basically a client library for invoking web services Tested on Java-based devices Now in version 2 (1 is deprecated)
Case Study: the ICAAS framework for accessing WSN Software architecture for accessing Wireless Sensor Networks developed at Mobilab within the REMOAM project (by CINI and Strago s.r.l.) The Architecture Non standard implementation of the OGC Sensor Web Enablement specifications Key features: Interoperable & Configurable Extensible Requests optimization (Caching and Filtering) ROA and SOA access
ICAAS Web Services for SOA access: Notification Service Observation Service Collection Service Alert Service Planning Service ICAASMobile: a J2ME test client SOA access to ICAAS through WS Real Time monitoring of WSN Session management Tested with a WSN simulator Technology note: Apache Axis (a Java-based SOAP implementation) used for WS deployment
Case Study: Porting ICAASMobile from J2ME to Android A typical porting process Assessing Migration Feasibility 1. All functions of the original client are achievable on Android (doubts were raised about invoking Web Services) Understanding Initial Application Deciding Target Development Tools 2. Reverse Engineering of ICAASMobile to get SRS and software architecture 3. Eclipse with Android SDK plugin Validating Original Design Plan Deciding about Porting Strategies 4. Decision to keep the same architecture and code base 5. ++ approach: add one function at a time and make it work before going on
Invoking Web Services in Android: the KSOAP2 solution Advantages: Reliable (tested on other mobile platforms) Easy to use Facilitates porting (the original application uses KSOAP1) Disadvantages: Introduces overhead on constrained devices Some effort is needed to port a client from KSOAP1 to KSOAP2 Motivations for the choice: Reusing the original business logic as much as possible Relying on a widely tested solution Implementation Stub restructuring needed The thread responsible for WS invocation (through the stub) can be reused
Porting the MVC Pattern to Android: the AVA solution Model-View-Controller Separating GUI from Business Logic and Data Access Adapter-View-Activity Main issues: Android Views are not Java- coded but xml-defined Who is the Controller? Who is the Model? Answers Activity builds View from xml Activity acts as Controller Adapter plays Model s role Contribution: a reusable design pattern for Android
DroidICAASMobile: a Conceptual Model AVA-based GUI change dataset KSOAP-based WS invocation change dataset Adapter creates notifydatasetchanged Thread creates creates response View user inputs Activity Stub update setcontentview uses invokes response user inputs builds Layout.xml --------- ------- KSOAP Web Services
DroidICAASMobile: example of use
Critical Considerations about the Android Experience Average learning curve (probably slightly steeper than J2ME) Advantages over other mobile platforms: xml-defined GUIs, open philosophy and full portability (at least in principle) Conclusions The KSOAP solution for invoking WS is working on Android Porting from J2ME is possible reusing most of the code The AVA pattern is a good option for designing Android GUIs Future Works Improvement of the developed client (under both functional and graphic aspect) and testing on real Android devices Testing of other solutions for Web Services (e.g. kxml-rpc)