Mobile Development

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

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

Darwino Environment (Cont’d)

• Contain important status information like connectivity state– .hasConnection()– .getConnectionMode()– .switchToMode(…) or .switchToLocal()/.switchToRemote()

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

Darwino Environment (Cont’d)

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

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

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 displaythis.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);

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)

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

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

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

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

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

Thank you for your attention!