Rapid and Reliable Developing with HTML5 & GWT

Esta presentación aborda "qué herramientas elegir y el porqué para el desarrollo una aplicación RIA que ha de funcionar en todos los entornos (desktop, mobiles, tablets). Se basa en la última experiencia de mi empresa para desarrollar una aplicacion para redes sociales. Se habla de java, html5, gwt, mgwt, cordova, playn, nosql etc."

La presentación no está pensada para entrar en detalles técnicos sino para comprender cada elemento de la arquitectura.

Transcript

1. Rapid and Reliable Developing with HTML5 & GWT. Manuel Carrasco Moñino manolo@apache.org http://twitter.com/dodotis Madrid Java User Group 4th Apr 2013
2. About me • Apache James Project Member Committee • HUPA • GWT • Gquery & Gquery-plugins • GwtExporter • GwtUpload • Chronoscope • Jenkins • Performance plugin • Emma plugin • Linux • LXP a light and visual window manager based on icewm
3. Proposal I Move apps from Desktop to Browser: HTML5 + JS
4. RIA → Rich Internet App. Better User Experience: Simple Page Interface.
5. History 1998 - 2002 2002 - 2004 2004 - 2008 2009 - 2012 Some technology demonstrations: desktop.com. There are not commercial products First products developed by pioneers: Backbase, GI, JackBe, Laszlo Systems and Macromedia Boon of AJAX technologies. 2007: Adobe Flex becomes the dominant player in the RIA landscape Companies have a strategic commitment towards RIA and AJAX technologies.
6. Ria Options Browser Player Native XUL Xforms GWT XUL, Flash, WCF OpenLaszlo Java/Swing Xcode/C## Reduced maintenance, any location. Combined benefits of thin and rich client Intuitive UI Inmediate response Thin Client Rich Client HTML Windows, Mac, Android, iOS Web Rails Php
7. RIA: Classic Approach
8. Proposal II HTML5: Desktop, mobile, tablets.
9. Art Status
10. HTML5 & JavaScript is everywhere Mobiles have fast and modern Browser run-times
11. HTML5 / JS Develop Html5/Javascript Run Anywhere
12. RIA: Pure HTML5/JS
13. - JavaScript - Canvas, SVG - Multimedia - Storage: (LocalStorage, IdexedDb, WebSQL) - Local File Access - Ajax, Web Sockets - Mobile in mind Develop local apps: games, contacts, etc What is there in HTML-5?
14. Proposal III Use HTML5 in your mobile native apps: Apache cordova (a.k.a. Phonegap)
15. Apache Cordova (Phonegap) • A framework for mobile applications that allows developers to implement their projects using standard web technologies: HTML5, CSS3 and Javascript • It converts them into native applications for different mobile platforms with access to much of the native API.
16. PhoneGap targets Unique Code Base Multiple Targets
17. Architecture
18. Project Structure: Android My Application Phonegap Native Engine Phonegap Javascript Engine Eclipse, Java (Lnx, Win, Mac)
19. Project Structure: IOS My Application Phonegap Native Engine Phonegap Javascript Engine Xcode: Objetive C (Mac)
20. Project Structure: IOS My Application Phonegap Native Engine Phonegap Javascript Engine Xcode: Objetive C (Mac)
21. Proposal IV Use a high level language Java: GWT (Google Web Toolkit)
22. Develop in a High Level Language Compile to Javascript
23. Google Web Toolkit GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser
24. What is GWT? Is a full SDK. Not a Js Framework Not a Js Library Not a new language Not a Web Framework Java to Javascript Compiler, Linker, Optimizer and Obfuscator Produces one 'js' per browser (like c++ one 'exec' per processor)
25. Why Java? • A high level language allows that the developer doesn't get lost with low level details: DOM, Ajax, Cross-domain, Compression, Obfuscation, Dependencies, Browser tweaks, etc. • Huge Java ecosystem: IDE, Re-factoring, Debug, Code assist, Maven. • Metrics, TDD, CI, Reusing (libraries) • Patterns, Builders … • Type safe, syntax checking, reduce errors. • Separate code maintenance from the effectiveness of the executable. • Normally, the compiler would produce better js code than the code we could write by hand (less code, compressed, obfuscated, remove dead code, etc). • Developers know java
26. Java Server Side Java Client Side Java Code (IDE) GWT server libs RPC/RF GWT development Debug/Hosted/Test GWT Compiler JRE Emulation Browser libs Widgets Test Runner FF/IE/Ch-Plugin Java HTTP Server J-Byte Code 3ª Party Server libs Browser Any HTTP Server (php, ruby, ...) JavaScript. Bundles (css, sprite). 3ª Party Client libs Toolkit (SDK) JSON/XML/HTML/TXT RPC/RF JSON/XML/HTML/TXT GWT Eclipse Plugin Mobile
27. New with 2.5.0 • SuperDev Mode • Source Maps • Elemental • Size & Split optimitations • Closure compiler
28. How looks the code like ? public class Tw implements EntryPoint { public void onModuleLoad() { Label label = new Label("Hello world"); Button button = new Button("Click"); button.addClickHandler(new ClickHandler() { public void onClick(ClickEvent event) { Window.alert("Hello world"); } }); RootPanel.get().add(label); RootPanel.get().add(button); } }
29. Project Structure Browser: Java → JS Both: Java → [JS or BitCode] Server: Java → BitCode Assets: html, images, css
30. Performance Generates less code. It analyzes the code and includes only necessary for each browser. Implements own managers to prevent 'leaks'. Applications faster and with less tricks HTTP. Eliminates the use wrappers for native functionality of each browser version. Saving the time spent on debugging for each browser, you can spend more time on the application functionality. The development efficiency is the main advantage of GWT. JAVASCRIPT USER DEVELOPER
31. Summary • GWT does not do anything that can be done otherwise, but it makes the action much more productive. • GWT does not attempt to exhibit the virtues of Java, but recognize the pragmatism of existing tools • GWT does not want to forget about DOM, CSS, browser, etc, but abstractions allow writing more productive code than hand writing JS code. • Perhaps someday GWT could compile other languages(Xtend, Scala), or even process annotated JS. • GWT makes possible development of large scale web sites and it opens the possibility of creating new generation of applications reliably.
32. Proposal V: Bring GWT to Mobile
33. GWT
34. Libraries • GWT: Core, Compiler, tools, layout, MVP • GWT-Phonegap: Access mobile HW from your code. • MGWT: Widgets, Animations, Themes • GQUERY: fast CSS and DOM tweaks Make your app look native
35. Advantages: Java + Gwt + Cordova • Maintain just one code base. • Use one language for all. • Reuse libraries written in java instead of rewrite them in JS. • Develop using a browser instead of an emulator. • Realtime debug. • Unit testing. • Everything is open sourced
36. Proposal VI Use a common framework to create visual apps: PlayN
37. Angry Birds
38. Game problem
39. PlayN Cross-platform game abstraction library for writing games that compile to: - Desktop Java - HTML5 Browsers - Android - iOS - Flash - More?
40. API GAME: Java Code
41. Why Java - Java ecosystem - Familiar Tools and Libraries - Desktop has Java - Android is Java - GWT is Java
42. HW acceleration
43. The same code for all platforms
44. Proposal VII NoSQL Databases
45. What is NoSQL? • not built primarily on tables • do not use SQL for data manipulation • optimized for retrieval operations • reduced run-time flexibility • no relationships between elements • cannot necessarily give full ACID (Atomicity, Consistency, Isolation, Durability) guarantees • Optimized to scale horizontally
46. NoSQL Types • Document: key-document (couchdb, mongodb, jackrabbit) • Graph: elements interconnected (DB2) • KeyValue: not fixed datamodel (Cassandra, Dynamo, BigTable) • Others: actually each product has its own features (nosql is not a standard).
47. Solutions • BigTable: Google App Engine • Proprietary Query Language • MySQL like layer • Map-reduce • Document based: CouchDb • Ajax Service • Map-reduce • KeyValue: Cassandra • Map-reduce • API
48. Map-Reduce Parallelism: allows data distribution, increases performance, recovering from partial failures 1- The master divide a complex problem in small problems. 2- Gives them to workers which resolve them in parallel. 3- Finally all responses are reduced to generate the solution.
49. GAE • Google's cloud solution. • Runs its own runtime (Java or Python): so consider GAE restrictions and API. • Integration with Eclipse: really easy to start and deploy a project. • Free until your app starts consuming a lot of resources. • Easy to administrate (console) • 100% scalable. • Suitable for RIA (Ajax, GWT, PlayN ...)
50. CouchDB • Light weight database. Developed by Apache in Erlang. • Json oriented: documents are json, dialog is json. • Js map-reduce • HTTP service (not any proprietary protocol) • Replica/Cluster out-of-the-box • High performance and scalability • Web administration Panel • Ideal for Ajax apps • Java Api to access it in a JPA like way • Push to client mechanism
51. Real Case: Talkwheel
52. Talkwheel • Talkwheel provides social engagement across mobile and desktop for any brand or personality. • Its goal is to offer a easy and visual tool for conversations • About 3 million users using our products • A San Francisco based startup of 6 people.
53. SW Architecture CouchDB HTTP Ajax Java → JS HTML5
54. One CodeBase → Multiple Targets Desktop Embedded Tablets Mobile
55. Real project size SLOC Directory SLOC­by­Language (Sorted) 18067 tw­model java=17871,xml=128,perl=68 14541 tw­gwt java=12254,xml=2173,sh=114 3126 tw­playn­core java=3121,xml=5 12266 tw­admin java=10274,xml=1992 3731 tw­ios objc=3731 2708 tw­droid java=2708 Totals grouped by language (dominant language first): java: 46228 (84.92%) xml: 4298 (7.90%) objc: 3731 (6.85%) sh: 114 (0.21%) perl: 68 (0.12%) Total Physical Source Lines of Code (SLOC) = 54,439 Development Effort Estimate, Person­Years (Person­Months) = 2.77 (33.24) (effort model Person­Months = 0.5 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.92 (10.98) (schedule model Months = 2.9 * (person­months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 3.03 Total Estimated Cost to Develop = $ 374,202 (average salary = $56,286/year, overhead = 2.40).
56. Off topic: Contributing the Open Source
57. Become an opensource contributor • Checkout the code. • Play with it, test it, find bugs. • Open tickets reporting problems, asking for improvements. • Attach patches which fix bugs, add new features, improve performance, contribute to readability, etc. Don't forget unit Tests. • Subscribe to mailing lists, and participate asking and answering questions. • Committers will appreciate your work and will propose you to be part of the team. • Other way you can utilize is to propose new projects: Apache incubator, labs, GSOC, etc. Find a mentor or use mailing-lists for that.