Java Swing vs. Android App

Disclaimer

-  The views expressed in this presentation are my personal
views.

-  Any opinions, comments, solutions or other commentary
expressed by me are based on my experience.

-  This presentation is presented for educational purposes
and is therefore supplementary and not to be considered
exhaustive.

Swing vs. Android - Johnny Hujol - CEJUG Fortaleza, Brasil - 2011/12/09

Building
Swing vs. Android
Applications
By Johnny Hujol

Who am I

-  A French leaving in Boston.
-  Software Engineer for a US pharmaceuticals company.

-  10+ years in Biotech/Pharmaceuticals sector developing
scientific applications.
-  10+ years in Java.
-  1+ year in Android.

-  Co-published book on Java called
‘Java for Bioinformatics and Biomedical Applications’.

•  10+ years kitesurfing 
•  4th time in Taiba, Ceara, Brasil.

Agenda

-  History

-  Swing Application

-  Android Application

-  Development Environment

-  Comparison

-  Building Applications

-  Conclusion


History

-  1995: Oak (Java) was released for Sun machines.

-  1996: Java 1 initial release.

-  1998: Swing part of JDK 1.2.

-  September 23, 2008: Android 1.0.

-  July 28, 2011: JSE 7.0.

-  October 2011: Android 4.0 (Ice Cream Sandwich).


Swing App


Swing App - Anatomy

-  JFrame, JButton, custom Java classes, events,
exceptions, etc.

-  Implement algorithms, business rules, etc.

-  Connect to some storage to deal with data i.e. database,
web service, file system, memory, etc.

-  Might have multiple background tasks running.

-  Offline or online app.

-  Goal: help people to do things better.

Swing App - Life Cycle

-  Main() method as starting point of program.


Swing App – Multi-Threaded

-  A Swing application is multi-threaded by nature.

-  Single thread model for Event Dispatching Thread (EDT).

-  Importance of (EDT) for UI responsiveness.

-  EventQueue.invokeLater(Runnable).

-  SwingWorker doInBackground() and done().



-  Do heavy work in the background.

-  More fine and advanced control with java.util.concurrent
package.

-  Executors to do background works to keep UI responsive.

-  FutureTask (java.util.concurrent).


Swing App - More

-  Exception handling policy based on requirements.

-  Custom exceptions.

-  Asynchronous messaging mechanism with java.awt.event
i.e. event classes and listener classes.

-  System events i.e. MouseEvent, KeyboardEvent, screen,
etc.

-  Semantic events i.e. ActionEvent, TextEvent, etc.

-  Events are always fired in the EDT.

Swing App – And More

-  Internationalization.

-  2D/3D/OpenGL, Media APIs, etc…

-  Debugging tools.

-  Logging, Tests, Profiling APIs.

-  Compilers, JVMs.

-  Encryption.

-  More…

Android Application


Android App - Anatomy

-  Activity, TextView, custom Java classes, exceptions, etc.

-  Implement algorithms, business rules, etc.

-  Connect to some storage to deal with data i.e. database,
web service, file system, SD card, etc.

-  Might have multiple background tasks running.

-  Offline or online app.

-  Goal: help people to do things better.


Android App - Components

-  Activity = UI.

-  Service = background tasks.

-  Content Provider: sharing data uniformly from multiple
apps.

-  Broadcast receiver = big announcer across components or
apps i.e. a broader event mechanism.


Android App – Life Cycle

-  Components Life Cycle well defined.

-  Activity (UI) starts with onCreate() in UI thread.

-  Visible lifetime between onStart() and onStop().

-  Foreground lifetime between onResume() and onPause().


Android App – Activity


Android App - Multi-Threaded

-  Single thread model for UI toolkit.

-  The Andoid UI toolkit is not thread-safe.

-  Do not block the UI thread.

-  Do not access the Android UI toolkit outside the UI
thread.



-  Activity.runOnUiThread(Runnable)

-  View.post(Runnable)

-  View.postDelayed(Runnable, long)



-  AsyncTask similar to SwingWorker.

-  Package java.util.concurrent for Executors, etc.


Android App - More

-  Exception handling policy based on requirements.

-  Custom exceptions.

-  Separation of layout from UI logic with XML.

-  Notifications with Toast, Status Bar and Progress.

-  Listeners.

-  Sensor APIs for GPS, camera, telephony, accelerometer,
etc.


Android App – And More

-  Internalionalization.

-  2D/3D, OpenGL, etc.

-  Database, SD card, FS access.

-  Configuration for multiple device specs.

-  Encryption.

-  And More…


Questions so far?


Development Environment

-  I use IntelliJ IDEA for Swing and Android apps.

-  Ant.

-  Android command line to build initial Android project.

-  Adb for interacting with USB plugged devices.

-  XML layout profiler with Hierarchy Viewer.

-  Android project libraries to share between apps.



-  LogCat.

-  Junit for testing, logging APIs.

-  Monkey and monkeyrunner.

-  Emulator.

-  SensorSimulator.

-  AndroidScreencast.


Comparison – Life Cycle

-  Life Cycle for Android is well defined.

-  All Android activities changes through states the same
way.

-  Save/restore state in the foreground lifetime onResume()
and onPause().

-  Important to release resources and kill background tasks
when going on onPause().

-  Save state in onPause() needs to execute quickly.


Comparison – Life Cycle

-  Cannot ‘quit’ an Android application.

-  Allow fast switching to Android apps.

-  Users use many apps back and forth.

-  Similar to opening lots of apps on computer when
working.


Comparison – Multi-Threaded

-  Transfer knowledge of Swing multi-threaded apps.

-  Less frequent cases on Android apps than Swing apps.

-  Simpler Android apps = less synchronization.

-  New methods runOnUiThread, AsyncTack (SwingWorker).

-  Cancelling policy more important on Android apps.

-  Does user allow background services.


Comparison – Storage

-  API for local Database (DB) like SQLLite.

-  API for Web Services like Amazon S3.

-  File System (FS) on device or remote.

-  Harder to test web services on the emulator.


Comparison – Storage

-  Internal storage with Context class.

-  External storage i.e. SD card.


Comparison – Device Resources

-  Battery is the most precious resource on Android devices.

-  Do not write intensive computation in the background.

-  Screen size very small with 2 mode landscape & portrait.

-  Memory because no ‘quit’ manage the listeners i.e. like
GPS location manager, etc.


Comparison – Device Resources

-  Code impact on memory.

-  Extends listener instead of creating inner class.

-  Use primitive int instead of Enum class = less memory.


Comparison – Network

-  Checking availability.


Comparison – Development Cycle

-  Emulator might not be consistent to real device.

-  Test directly on device more than emulator.

-  Faster release because less features.

-  Simpler application architecture on Android.

-  Send logging info to network.

-  Once deployed on production harder to debug.


Comparison – Sensors

-  Native support on Android devices.

-  Available on Swing through integration.

-  Can have different specs depending on device.

-  Getting easier with WiFi-Direct, Bluetooth, etc.

-  Location based application more natural on Android.


Building Apps

-  Mobile nature of Android apps.

-  New mobile paradigms to manipulate UI.

-  Swing will adopt mobile paradigms.

-  Android devices, computers and the cloud.

-  Component model of Android apps.

-  Similarity between 2 platforms.


Building Apps - Architecture

-  Importance of separation of UI, business logic and storage
in design of an app.

-  Can reuse non-UI logic from Swing i.e. Data Access
Object, etc.

-  Easier to build an Android app from a multi-tier Swing
apps, no need to test business logic again.

-  Allow offline vs. online mode.

-  Develop and reuse libraries.


Building Apps - Software Engineering

-  Get your users involved.

-  Deploy often.

-  Continuously testing the system.

-  Design Patterns.

-  Design for reusability and maintenance.

-  Network back-end for intensive computation tasks.

-  Use primitive int in Android apps.

Building Apps - Assurance Quality

-  Mock, Unit Test, MonkeyTest (Android), etc.

-  Code static analysis.

-  Use code reviews.

-  Performance on memory with profiler.

-  Multi-threaded apps easier on Android.

-  Use logging API.


Conclusion

-  Easy transition from Swing to/from Android.

-  Faster to develop Android app.

-  Well defined Life Cycle of Android app.

-  Keep a design of apps simple.

-  Allow offline and online mode for apps.

-  Design apps more in a mobile way.

-  Cloud based applications.

Questions & Answers


References

•  Android
–  http://developer.android.com

•  Screencast
–  http://code.google.com/p/androidscreencast/

•  SensorSimulator
–  http://code.google.com/p/openintents/wiki/SensorSimulator

•  Android Way on Multitasking
-  http://developer.android.com/resources/articles/multitasking-android-way.html


Java Swing vs. Android App

More Related Content

Similar to Java Swing vs. Android App (20)

Recently uploaded (20)

Java Swing vs. Android App