I have several years of swing experience but I have recently started to play with android API. I have noticed one significant difference in terms of how Flyweight pattern is implemented. In JList you generally create an instance of a ListCellRenderer and return a swing component from getListCellRendererComponent method. Android has also a very similar mechanism. You extend BaseAdapter and return a View from getView method. In java how many different swing component instances you will return is directly determined by your getListCellRendererComponent. But in Android, framework manages a cache of View components and makes an instance available to you as a parameter to your getView method. And you have to return a new instance for every different row in current view pane. To achieve this you by checking whether convertView parameter supplied to your getView implementation is null, if it is null you create a new instance, if not you reuse supplied converView instance. If you return the same instance (as in the swing) android’s getView method will not work correctly. Swing’s implementation seems more lightweight in terms of memory. Same things could be said for editable state of rows. Same comparison is also valid for JTable of Swing and GridView of Android.