Describes the Darwino framework for writing mobile applications, including advanced hybrids and pure native applications.

1. Mobile Development

2. Java Everywhere
• Android is pretty direct: Android apps are already written in Java
– Only a few considerations to worry about with Android’s runtime, par for the
course in Android development
• iOS is trickier: Java is not the native language, but tooling exists
– First tool: RoboVM
• Ended up at Microsoft, who axed it
• Open-source forks exist, but are at a disadvantage (no debugger)
– New solution: Multi-OS Engine
• Purchased and cultivated by Intel, then released fully as open source
• Very capable, actively developed

3. Darwino Environment
• For the most part, everything works just the same way
• DarwinoApplication
– DarwinoMobileApplication
• DarwinoIOSHybridApplication
• etc.
• Test DarwinoApplication.isMobile()
• DarwinoContext
– DarwinoMobileContext
• Generally, the top-level objects do what you need, but accessing the more-
specific kinds can be useful in cases

4. Darwino Environment (Cont’d)
• Contain important status information like connectivity state
– .hasConnection()
– .getConnectionMode()
– .switchToMode(…) or .switchToLocal()/.switchToRemote()

5. Darwino Environment (Cont’d)
• The environment is very analogous to the Notes client/Domino server split
• While the server is multi-user, the mobile client is single-user, but the APIs
are the same
• All normal services exist in mobile-friendly forms: HTTP client, logger,
scheduler, etc.
– I’d be wary about doing too much scheduling on mobile for battery reasons, but
it’s there
– In general, be wary to not overload a mobile device: if there are tons of bells and
whistles that only make sense to activate on a server, don’t run them on mobile

6. Darwino Environment (Cont’d)

7. Android
• In general, this is straightforward: Android apps are already Java, and have
the same considerations
• There’s a bit of an IDE problem: Darwino Studio uses Eclipse, while Google
moved to IntelliJ
• Fortunately, this is surmountable:
– Darwino Studio is not required for Darwino development: IntelliJ should work
fine
– For now, the ADT still works if you have it already
– Eclipse has Andmore, a new replacement for ADT, acting as a drop-in
replacement

8. iOS: Multi-OS Engine
• Compiles Java bytecode to native iOS applications
• Adds bindings for native iOS controls: UITableViewController, UIInput, and so
forth
• Allows for creating “as native as you like” iOS applications in Java
• More details later this morning

9. iOS: Multi-OS Engine (Cont’d)
CGRect tableViewBounds = CoreGraphics.CGRectMake(0.0, 64.0, 320, 416);
UITableView tableView = UITableView.alloc().initWithFrame(tableViewBounds);
tableView.setContentMode(UIViewContentMode.ScaleToFill);
setTableView(tableView);
// Add items to list where they will be retrieved when to display
this.newsViewController = NewsViewController.alloc().init();
String[] cat = NewsManifest.getCategoryLabels();
for (String element : cat) {
menuList.add(new MenuListItem(element));
}
createTopbar();
createToolbar();
tableView().registerClassForCellReuseIdentifier(
new org.moe.natj.objc.Class("UITableViewCell"),
MY_CELL_IDENTIFIER);

10. Desktop Applications
• Desktop apps use standard Java toolkits
• Darwino has particular support for SWT (Eclipse’s toolkit), providing a hybrid
app shell
– You could use others either in addition to or instead of SWT, though you may be
on the hook to replace some behaviors
• This has all the traits of mobile apps: shared web UI, offline data access,
native hooks
• We’re investigating tools to avoid the need for the JVM
– In the mean time, it’s possible to embed a JVM, at least on a Mac (the examples
have this configured in the pom.xml)

11. Hybrid vs. Native applications
• Two main routes for mobile development: “hybrid” and native
• “Hybrid” refers to an app that is primarily a web view containing an HTML
application, most often the same web UI used in a JEE server
• Truthfully, it’s a gradient: a primarily-web UI can call to and use native
components as desired
– Darwino does this by default: the settings screen uses native code and file
attachments use native file-open handlers

12. Hybrid Applications
• Hybrid apps use an embedded web server on the device
• The same services standard in Darwino and added custom in your code run
on-device without changes
• This method involved minimal work to get your application running offline
on mobile
– As long as the shared web UI is mobile-friendly, the standard hybrid shell will do
the heavy lifting for you
• If desired, the bridge to the native layer is extensible: you could add native
components to a hybrid app bit by bit

13. Native Applications
• Similar to normal native development, especially for Android
• There are still base Darwino services to extend, and the data layer and
settings can still exist “for free”
– Just hook into the commands in the same way as the starter applications
• At this point, all options are open: use existing native tools and layouts
• iOS involves a bit of extra indirection, but MOE makes that work, and is ever-
improving

14. Offline Access
• “Notes-like” offline access brought to mobile devices
• All logic remains the same when disconnected: documents are accessed in
the same way
• Replication can run on a schedule or manually
• Data can be encrypted on-device

15. Settings Screen
• Common Darwino settings used on mobile and desktop
• Will be extensible with custom settings in the future
• Covers server connections, local database encryption, and replication
schedules
• Internally, it is an abstract UI representation with a native face on each
platform
• In theory, this could be a good example of structuring a cross-platform native
UI
– I should really get on fleshing that aspect out

16. Thank you for your attention!