API for Single-Instance Common App with Branding Overrides

[howardk]

With mobile web apps using the framework are being done in a distributed fashion, it is desirable to be able to re-use an existing app (e.g., campus directory), but be able to override the branding (e.g., header, footer, CSS class to ) and link back label (e.g., Return to UCLA Mobile) and destination URL. To prevent hijacking, there will need to some controls added (e.g., common domain, approved IP, etc.).

Adding this ability as part of the core MWF will give developers a common framework to provide this functionality instead of each app coming up with its own implementation.

FYI - this request is based on a conversation between Howard Kim, Ed Sakabu and Rose Rocchio at UCLA.

[ebollens]

What sort of method are you thinking of for reuse? Downloading a copy of the code and running it form your server or injecting your own branding (header, footer, CSS classes, etc.) directly into the hosted copy when a user arrives from a particular location?

[howardk]

Direct injection of a hosted copy. The advantage of this method is that the app could be written in any language (e.g., PHP, .NET, Java) and still re-used.

[ebollens]

I agree with the concept. However, the actual injection implementation will be a bit tricky, especially if we want to provide a toolkit to do it across multiple language systems - PHP will be a start, and the prototype will be a one-off of either the directory or MWRS. I'll make this a target for Q2 of this year, at least for a prototype.

[Trott]

In the UCSF repo, I've added an isNative() method in the JS libraries and an is_native() method in the PHP libraries for this sort of thing. If desired, I can merge it into feature/native which will then be merged into 1.3.

The approach I took does not, as it is currently written, allow for overriding based on URL parameters, etc. Instead, it sniffs the user agent for an indication that it's an MWF native container. So it will work automatically if you use the framework's native app code to build your native app, at least as a starting point.

Adding in stuff so that URL parameters or whatever can be used to override the results should be relatively easy. It would basically be done the way we do classification overrides right now, just with perhaps additional stuff to prevent hijacking, like you said. I imagine a same-origin policy would be sufficient as a default.

The isNative() JS function is in https://github.com/Trott/mwf/blob/ucsf/master/root/assets/js/core/useragent.src.js.

The is_native() PHP function is in https://github.com/Trott/mwf/blob/ucsf/master/root/assets/lib/classification.class.php.

The cookie that the PHP function depends on is written by https://github.com/Trott/mwf/blob/ucsf/master/root/assets/js/core/classification.src.js.

The user agent string in the iOS container is set on line 29 of https://github.com/Trott/mwf/blob/ucsf/master/root/assets/js/core/classification.src.js. (Yes, I hardcoded the version. Shame on me. That should be refactored into the appropriate plist or whatever the convention is in iOS.)

The user agent string in the Android container is set on line 63 of https://github.com/Trott/mwf/blob/ucsf/master/auxiliary/native/android/src/edu/ucsf/m/MWFWebViewActivity.java. (Same comment about hardcoding the value.)

[ebollens]

Rich, I think this is a different issue than you're describing a fix for here.

[rrocchio]

Closing this issue as this system has long since been deprecated.