| if you have ___ in iOS | then you want ___ in Android | to |
|---|---|---|
| UIViewController | Activity | subclass to present a screen/form/page to the user |
| ViewDidLoad() | OnCreate() | setup the UI |
| Add() or AddSubview() | SetContentView() | use in ViewDidLoad/OnCreate to 'attach' UI to display |
| ViewWillAppear() | OnResume() | load/re-load data that might change and bind to UI |
| UITableView | ListView | visual control that presents a scrolling list |
| UITableViewSource | Adapter | subclass to broker the display of a data collection to the UI |
| GetCell() | GetView() | to build the layout(UI) for each cell/row, including re-using cells/views for performance |
| RowSelected() | ItemClick EventHandler | perform an action when a row is touched |
| RowsInSection | Count | tell the table/list how many rows to cater for |
UITableViewSource has been implemented as an nested class to resemble the iOS pattern of implementing the equivalent Obj-C protocols on the ViewController - this pattern makes no sense in Android so the classes are separate.tableView=new UITableView();AddSubview (tableView);) whereas MonoDroid loads layout XML files SetContentView(Resource.Layout.Speakers);. This can happen in both ViewDidLoad/OnCreate and GetCell/GetView where UI controls must be created and presented to the user.TableViewSource handles a touch for a specific row (NSIndexPath); MonoDroid implements the ItemClick EventHandler<ItemEventArgs> on the ListView for a given GetRow(e.Position).TableViewSource/SpeakersAdapter) of the 'broker' class to pass the actual business object collection for display. This pattern lets the data be filtered/sorted/whatever before being passed in for display.refreshSpeakers() from ViewDidLoad/OnResume is kinda redundant in this example since the list never changes - but in other spots (eg the Favorites screen) you would want to refresh the list each time because it may have changed.UINavigationController stack and your RowSelected creates a new ViewController object (passing whatever parameters you need) and calls NavigationController.PushViewController(). The ViewController instances in the navigation stack are 'stateful' and it is really easy to pass business objects around as parameters.var intent = new Intent();
intent.SetClass(this, typeof(SpeakerActivity));
intent.PutExtra("Name", speaker.Name);
StartActivity(intent);
conf.xml format that is the shared data structure for both platforms.
ConceptDevelopment.Kelvin code is also shared (different sizes in each aren't relevant for now).Main.cs::DeserializeConferenceFile, LoadWhatsOn and MonoTouch's AppDelegate.cs::FinishedLaunching both contain "very similar" code in the form of the conf.xml deserializer and parser. In MonoTouch it's 70 lines and in MonoDroid it's 307 lines. The MonoTouch version is heavily assisted by the Linq/MonoTouch.Dialog code in HomeController (another 150 lines or so) which explains part of the difference... but what is shared is the deserialization logic and a number of Linq statements that help parse it for display. These would be harded to shift into a common library due to the dependency on MonoTouch.Dialog - but there was definitely an efficiency gain by having the code already written and tested on one platform before porting to the other. I'll adjust both by the same 'average' LOC count to try and reflect the 'copy/paste but modify' efficiency gain.| Mono-for-Android | MonoTouch (iOS) | |
|---|---|---|
| Code | 375 lines | 827 lines |
| 'markup' | 14 AXML | 1 XIB |
| Views | 7 Activities | 9 ViewControllers |
| DataSources | 6 Adapters | 5 TableViewSource |
UITabBarController takes more code to setup than OnCreateOptionsMenu.SQLite implementation of saving Favorites is more verbose than the XML-serialized-file solution used on Android.
