API for Single-Instance Common App with Branding Overrides #79

Open
howardk opened this Issue Jan 20, 2012 · 5 comments

Comments

Projects
None yet
3 participants

howardk commented Jan 20, 2012

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.

Collaborator

ebollens commented Jan 20, 2012

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 commented Jan 20, 2012

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.

Collaborator

ebollens commented Jan 20, 2012

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.

@ghost ghost assigned ebollens Jan 20, 2012

Contributor

Trott commented Jan 20, 2012

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

Collaborator

ebollens commented Jan 25, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment