Has been quite a long time in entering anything in here - will be updating more regularly with coding issues.

 Since my last entry, I had been involved in writing a pretty extensive iOS 7 app for my job. This took about a year+, and I should have been writing all of my findings from that here as well, but - (whew) - that was a job. :)

This app was an XMPP-based communication app for hospital employees (nurses) to receive/interact/user alarms and alerts much more efficiently and smarter. It is now been taken over by another group, but was invaluable experience.

I had worked on iOS apps before - but not with this intensity or scrutiny to do right, and I learned a great deal more about Obj-C and the environment then I could before just on my own. Really grateful for that.

No reason going back and re-hashing my notes on that, so will just continue on what is coming up and what I work on, having a place to come back for notes.

This will include all of the Java 8 conversion that I have been working on, as well as updates to GlassFish (4), and AngularJS updates.

We are still using pre-release AngularJS for most of our stuff, but it still works great and gets the job done.

That will be changing, and will be converting/upgrading to the latest release (1.3) - totally stoked on that. And with all of the updates from Java 6 -> 8, many more on that as well.

:)

Enabling Sites in Mountain Lion

Seems Mountain Lion removed the default paths to enable the 'Sites' directory for web access in Mountain Lion (10.8). They still included Apache - so easy enough to bring back to norm. Create a configuration file with your username as the filename such as:

/etc/apache2/users/rweeks.conf

File contents:

<Directory "/Users/rweeks/Sites/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Then simply restart apache and the dir will be restored:

% sudo apachectl restart

Upgrading to angular 1.0.0 - compiler

I have been working on upgrading all of our client side libraries and such that were developed using angular (latest was 0.10.5) to the FCS release coming up (using the latest builds -1.0.0-rc3 as of this post).

There have been some massive changes since 0.10.5, so will be putting some of the updates here as reference.

One of the things that has changed is the initialization/bootstrapping of an angular app.

The majority of our angular based apps are loaded via xhr from OSGi bundles that are serving the content (statically via html streams) and being injected into existing UI framework.

Before this push, we were able to do something similar to:

$('#myContainer').load(url, function(responseText, textStatus, XMLHttpRequest) {
    ...
    angular.compile($('#myContainer'))().$apply();
    ...
});

This has changed now and can be accomplished a couple of ways.

A little background - to be explained in further as they are developed - is that the new upgrade introduces "modules" that are defined to encapsulate how an application should be bootstrapped, configured, and what services can be added.

So say if we have defined a module for the app called 'interfaceSettings':

var interfaceSettingsModule = angular.module('interfaceSettings' ['interfaceApp.services', 'interfaceApp.filters', 'interfaceApp.directives']);

(This is defining an angular module named 'interfaceSettings' that is also injecting the modules 'interfaceApp.services', 'interfaceApp.filters', interfaceApp.directives', which were defined previously).

So, for automatic bootstrapping, we can define our app directly in the element that is the root element of the app:

<div ng-app="interfaceSettings" id="ng-app" ng-controller="...">...</div>

The ng-app directive tells angular that this is the root of the application, and to use the module defined as 'interfaceSettings'.

You will also notice a repeated 'ng-app' call in the 'id' tag. This is to allow IE 7/8 to recognize this as well, since there are some issues with earlier releases not recognizing the app call (just dreaming of the day when don't have to do so much crap just because of IE shortcomings. They should have to do community service forever for releasing the normal junk they usually do. sigh....)

We can also still manually bootstrap it by taking the root element:

angular.bootstrap($('#interface_myContainer_container'),['interfaceSettings']);

Which will take the root element and compile it, using the module(s) indicated in the array.

This actually gives us some great flexibility in definitions, but will also allow us to just load in external apps and embed anywhere inside the existing framework.

To allow us to do this automatic bootstrapping though, we have to make sure to load in the angular lib inside the main framework. Before, the reference to the library was loaded with each loaded app.

A near future goal is to have the ability to define different elements of the web-based GUI based on OSGi bundles and angular as well, so this change to include the library by default is a good one anyway.

Auto install of Java on Ubuntu

We recently had an issue on our appliances for builds that was causing a problem when it came time to install Java via apt-get on Ubuntu.

Found this gem that should save a lot of time:

sudo sh -c ‘echo sun-java6-jre shared/accepted-sun-dlj-v1-1 select true | /usr/bin/debconf-set-selections’;

sudo apt-get install —yes sun-java6-jre;

http://www.davidpashley.com/blog/debian/java-license

Change in 'angular.compile()'

In our app we load in partial GUI's via OSGi bundles that angular then compiles/bootstraps after the pull from the bundle via calls similar to:

$('#eiAuditUI').load(eiAuditURL, function(responseText, textStatus, XMLHttpRequest) {
    if (textStatus == 'error') {
        $('#eiAuditUI').html('Unable to contact the Audit Tool.
');
    } else {
        angular.compile($('#eiAuditUI'))();
    }
});
$('#eiAuditUI').show();

This was with angular up to 0.10.3. As of 0.10.4, needed to apply '$apply()' to the compiled element, since angular.compile does not call $apply on the linked scope.

Being that we are bootstrapping the partial being pulled in itself, we need to now append the calls to compile from:

angular.compile($('#eiAuditUI'))();

to:

angular.compile($('#eiAuditUI'))().$apply();

What this was causing was that when the scope was called/compiled, the rendering didn't happen as was previously, unless some even happened, such as starting to fill out a form or moving a select list.

With the above change - everything back to normal.

angular select list options

Angular allows filling in of selection lists via different data structures, but can be a bit confusing as to how to build them sometimes.

I have had to make certain data structures available as angular services to our developers, making the calls as simple as possible.

Say we have a straight JSON object such as:

{
  "33":"Bed",
  "44":"Call",
  "66":"Emergency"
}

I take this call from an $xhr request:

getDatasets: function(ctrl) {
  $xhr("GET", CURRENT_DATASETS_URL,
    function (code, response) {
      processDatasets(ctrl, code, response);
    },
    function (code, response) {
      processDatasets(ctrl, code, {});
      showError("Unable to load ...");
    }
)};

and inside 'processDatasets()' method - manipulate data structure so turns out such as:

self.datasetsArray = [
  {label:"Bed",value:33},
  {label:"Call",value:44},
  {label:"Emergency",value:66}
]

We can render a select list easily with:

<select name="dataset" ng:model="form.dataset" required 
        ng:options="ds.value as ds.label for ds in datasetsArray">
</select>

Giving us the labels and values needed.

Another challenge for this came up as wanting to utilize groups for values as well. For example, a structure coming in from a service call would come back as:

{
  "MainMenu":  {"Menu Item 1": 5},
  "AlertMenu": {"Alert Item 1": 9, 
                "Alert Item 2": 2, 
                "Alert Item 3": 7, 
                "Alert Item 4": 23
  },
  "TrackMenu": {"Track Item 1": 55, 
                "Track Item 2": 1, 
                "Track Item 3": 8, 
                "Track Item 4": 6, 
                "Track Item 5": 10, 
                "Track Item 6": 3
  }
}

Manipulating this structure in our callback from the service (like above), we create an array such as:

var menuGroups = [
  {group:"MainMenu", label:"Menu Item 1", value:5},
  {group:"AlertMenu", label:"Alert Item 1", value:9},
  {group:"AlertMenu", label:"Alert Item 2", value:2},
  ...
  {group:"TrackMenu", label:"Track Item 1", value:55},
  {group:"TrackMenu", label:"Track Item 1", value:1},
  ...
]

We can now use this to create a select menu with the 'optgroup' already in place:

<select name="menuPage" ng:model="form.menuPage" ng:format="number" required 
        ng:options="mp.value as mp.label group by mp.group for mp in menuGroups">
  <option></option>
</select>

** Updated for changes in form processing with angular 0.10.3+.

Love of angular

Over the past few months (18+ months now) I have been working on a project that has become pretty involved, being a hybrid Java EE/OSGi app, with a lot of javascript and "trickery" involved.

One of the core goals of this project was to have a central "Core" app that would be the persistence layer, with the ability to create pluggable interfaces that could interact with this layer.

The "Core" layer also houses an Admin Console, which an admin uses to setup and administer these interfaces, so that they can communicate properly.

The legacy app of this involved a combination of Ruby On Rails to house the entire admin console and send information via JMS to the standalone interfaces that were each running in their own space.

When an interface was to be created, that involved not only writing the java code for the interface itself, but much code to be written in the ruby side of the app to support this, including the GUI that would be specific to the interface in question.

With the new architecture, we wanted to make sure that when interfaces are built, that they be completely self contained, so if there were updates needed, only the interface bundle itself would need to be deployed, not any of the surrounding parts.

A huge challenge to me was not only setting up the framework to handle the communications between these interfaces and the core app, but the GUI piece was proving to be an immense challenge.

Then came 'angular'.

I had been following it for a while. One of the guys on my team at Sun (Igor!) had went to work for Google, and I saw this library he was working on - and started messing around with it.

It is an *incredible* library for building client side apps.

Creating a resources bundle that housed the angular library and our custom libraries that the interface bundles could rely on (via manual registration of them via the OSGi HttpService), we were able to make the persistence of the interface data straight JSON objects (which the core app doesn't care about - only cares about saving the data itself), and have that pulled back and manipulated via angular binding.

I will be following up with some of the details of the work that was done, which could be a valuable reference.

I couldn't be happier with how this library has helped in this transition, and made it possible to build the beginnings of a rich SDK for interface developers to use.