Thursday, August 21, 2014

Running Android apps for development purposes

The next major version of ProjExec is going to support mobile devices, and in particular Android. This means that the developer needs a way to test the application while developing, and the sales guys need a demo environment.
As probably everyone, we started with the emulator bundled with the Android SDK. It has several advantages:

  1. It comes out of the box with the Android SDK, for free
  2. It is heavily configurable, so you can choose from a list of existing devices to emulate, or create a custom one
  3. It can emulate several hardware architectures, including ARM and x86
  4. It behaves like a real device, including the side buttons

If this emulator is technically working, it is actually barely usable in the best case. Most of the time, it is slow as hell... The recent Intel HMAX, now bundled with the SDK, makes it faster because it natively runs x86 code. But still, if it makes the experience better, it executes slowly.

Fine. To get a better experience, I bought a real device. A 10" quad core cheap tablet from Amazon. I got a very good deal for it and, at that time, Android 4.2 was perfectly fine for development purposes. I've been pretty happy with it, once I passed the configuration steps. Forgot to say, you need to install a USB driver on your development PC to communicate with the tablet. And none is offered by Matricom, or other cheap manufacturer. I finally found a generic one that barely works: it does not see the tablet as a USB disk, but the Android Debug Bridge (adb) sees it properly. Good for dev purposes.

Now came Android 4.4, aka KitKat. I wouldn't normally look to upgrade, but this time is different. Its browser component is now based on Chrome. This is a game changer for developers because this component can  be remote debugged from another machine, directly from Chrome. See: Remote debugging on Android with Chrome. Wahoo, this works very well for hybrid apps using Apache Cordova. That's make a KitKat based device really indispensable! But wait, my cheap tablet runs 4.2, with no update in the pipe. It suddenly became obsolete. I haven't opened it for 2 months now. If one knows how to upgrade it with a generic version of KitKat, please let me know. Else, it will finish in the cemetery of obsolete devices, or in the hands of a kid in the neighborhood. By the way, I *hate* the way android devices get OS upgrades. Google should learn from Microsoft, as I don't need to change my PC when I want to update Windows. But this is another debate.

Alright. Before I spend more bucks buying a recent KitKat based device, I investigated alternate solutions.

One of them is provided by a French company called Geny Motion. It is another emulator, based on Oracle's VirtualBox. It is much faster than the emulator from the SDK, with a lot of devices being emulated. Plus, it emulates many sensors. But it has a cost that can be seen as prohibitive (>$400 per developer, per year). Hum, I might buy a few licenses over time. But this can be complex if you hire free lancers. Not sure how the licensing model would work. Google should acquire them and get their emulator integrated into the SDK, similarly to what they did with Instanciations' WindowBuilder. That would really help the Android community.

A recent announcement also caught my attention: the port of Android 4.4 to x86 is now officially available. In short, you can run Android as your main desktop PC OS. This is fun, but I don't see why I would do that on my machines. Except if it can run on a PC, then it can be also installed in a virtual environment Couldn't wait to try it on VMWare. I found many blog posts or videos telling the steps. It took me less than 30 mins to get it downloaded, installed, configured and running. It can be even faster if you run VirtualBox and download the preconfigured image (eeepc). And it is blazing fast. It feels faster than any real tablet I tried so far, even the latest 12.2" from Samsung. This is just brillant! There are still missing bits, like the availability of VMWare tools for Android, but this is sugar. Someone will certainly find out how the FreeBSD ones can be installed.

Back to my development use case. Once the VM is running, you can configure the developer options the same way you would do it on a regular device. And the you can remote access it by simply running one adb command. This is well explained here.

It does not fully replace the SDK emulator, or GenyMotion, as it doesn't provide a phone like experience, but it is great for core development and demo.

Let me know if you have the same experience, or have any trick to share. I can start with a few:
- If it goes to sleep, press the 'esc' key for more than a second to awake it (see: wake up). But better to configure the display to never go to sleep, in the Android Settings.
- The 'Power Off' button can be displayed by dragging the top right bar down (where the time is).
- Changing permanently the default resolution is done with a few edits, detailed here (easy!)
- Configure a fixed ip for you device, that makes adb easier to use

Enjoy Android development!

Thursday, August 14, 2014

Connecting to the IBM social platform from a Domino Agent

We recently worked on a project that involved IBM Domino and IBM Connections. The idea was to 'replicate' some of the Connections data into an NSF, so users can access these data offline from the Notes client. Actually, the synchronization between Connections and the NSF happens on a Domino server, and the Notes clients are using the regular Notes replication capability to get the data down. So far, it sounds simple.

To access Connections data, we obviously wanted to use the IBM Social Business Toolkit SDK. I said obviously because I was at the origin of this SDK, during my time at IBM :-). It really makes things simpler, by handling all the plumbing for you.

Now, the Connections/NSF synchronization task should be triggered on a scheduled basis. For this, Domino offers at least 3 options:

  • Use an agent
    This seems the obvious answer, although it is *not* the most performing one, as the classes are loaded every time the agent is executed, then discarded. On the other hand, it takes less than a second to get it bootstrapped. For a task that just happens from time to time, this is not a big deal.
    The other issue is with the SBT SDK, as it has never been run in an agent. At least by IBM. And it failed when I tried it.
  • Use an Eclipse job within the HTTP server
    We explained this technique in a video. It is relatively simple to code, as it uses all the XPages capabilities (managed beans for the endpoints...)
    But it requires some extra permissions that should be set within the global java security files, or bypassed through a custom plug-in. I implemented a version this way, but I found it to complex to install for this basic project.
  • Use DOTS
    Another great OpenNTF Project from my friend David. But the installation complexity is even worse than the Eclipse job. Moreover, even though parts of the project are now in Domino 9, this is not supported by IBM. I anticipated an extra effort to justify this choice, so I decided to not go this route.

Ok, I finally decided to go back to the agent option, and fix what should be fixed in the SDK. That was actually simple. See:

With that fix in, here are the steps to call a Connections API from an agent:

1- Create a Java agent in Designer.
No kinding...

2- Import the SDK libraries into the agent
Import the Java archives to get something similar to this:
Note that I used an older version of the SDK But I would advise you to use the most recent one.

3- Code your agent
If you already used the SDK prior to this, you might know that it uses some 'Endpoint' defined as managed beans. But managed beans do not exist in agent.
Fortunately, the SDK provides you other ways to define these endpoints, including extension points. But, in my case, to make it as simple as possible, I just created one programmatically:
    BasicEndpoint e = new ConnectionsBasicEndpoint();
    // For HTTPS access
Other endpoints types (oauth...) can be created the exact same way. In this example, I'm using basic authentication, with the URL, user name & password are stored in a configuration document.
Note the use of setForceTrustSSLCertificate. This allows the SDK to call HTTPS URLs without having to install the SSL certificates in the Domino server. Not fully secure, but this is ok for development or within a known intranet environment.
Then you can create the service your need with the desired endpoint as a parameter:
    BasicEndpoint e = ...;
    CommunityService cs = new CommunityService(e);
    CommunityList communities =  cs.getPublicCommunities()

For more information on the available services and API, have a look at the Playground. It contains many examples of working code.

4- Make sure that your agent can execute restricted operations (http calls in this case) and that it is signed with a user with the appropriate rights in the server security document.

To get the whole story in, I also bundled the code into an OSGi plug-in and called it directly from XPages, in the HTTP task. That made it far easier to develop and debug, particularly with the Domino Debug plugin, again from David.

If you also want to access the SDK from an XPages, then you should install the OSGi plug-ins, following the standard procedure. The jar files in the agents are not visible from XPages.