feat(android): snackbar

[m1ga]

Adds the Android Snackbar

var win = Ti.UI.createWindow({});
var btn = Ti.UI.createButton({
	title: "show message"
});
btn.addEventListener("click", function() {
	snack.show();
});

var snack = Ti.UI.Android.createSnackbar({
	message: "Hello Snackbar!",
	length: Ti.UI.Android.Snackbar.LENGTH_INDEFINITE,
	action: "click me"
});
snack.addEventListener("click", function(e) {
	console.log(e.action);
});

win.add([btn, snack]);
win.open();

TODO

• add style properties
• code cleanup

[hansemannn]

We could try out a new concept here: Providing a polyfill / parity API for iOS using the Javascript bindings! Some existing examples can be found here. We would just need to follow the material design guidelines for iOS in terms of size, colors and actions. Happy to do that if interested. Then we could take it as a core API without issues. Otherwise, as discussed, we should publish it as a module.

[m1ga]

We could try out a new concept here: Providing a polyfill / parity API for iOS using the Javascript bindings! Some existing examples can be found here. We would just need to follow the material design guidelines for iOS in terms of size, colors and actions. Happy to do that if interested. Then we could take it as a core API without issues. Otherwise, as discussed, we should publish it as a module.

Interesting! I like that idea. Will look into that

[jquick-axway]

@hansemannn, @m1ga, regarding doing a "polyfill", a year ago I was working on the ability to allows Android/iOS to set up a JS class to derive from a native Ti.UI.View so that you can do exactly this with views. It would make Titanium's APIs available via ES6 classes and allow you to do a new on Titanium proxy classes in JavaScript. I started on the iOS, which can be seen in my 2nd commit in the following branch... although it may have conflicts now. Particularly in the KrollObject.m which has the most changes. https://github.com/jquick-axway/titanium_mobile/commits/TIMOB-28332

I definitely got it working on iOS. However, I did run into a bug with Apple's JavaScriptCore where deriving from a native class from the JS side caused the JS prototype not to be applied. V8 doesn't have this problem.

class MyView extends Ti.UI.View {
	constructor(properties) {
		const defaultProperties = {
			borderRadius: "20dp",
			borderColor: "red",
			borderWidth: "5dp",
			backgroundColor: "#dddddd",
		};
		properties = Object.assign(defaultProperties, properties);
		super(properties);

		// Work-around Apple JavaScriptCore bug.
		Object.setPrototypeOf(this, MyView.prototype);
	}
}

const window = new Ti.UI.Window({ backgroundColor: "white" });
const myView = new MyView({ width: "50%", height: "50%" });
window.add(myView);
window.open();

On Android, Titanium's proxies are already available via JS classes and you can already do a new, but there is 1 issue. In our common JS extensions, notice we override the Ti.UI.createListVew(), Ti.UI.createWindow(), and other similar methods. This old legacy code and doing a new Ti.UI.ListView() or new Ti.UI.Window() means bypassing that code. I haven't addressed that in my branch (this was about the time Axway said we were going to end-of-life the product), but the plan was to remove that JS code and move the implementation to the Java side.

Not sure if you're interested, but you're welcome to grabbing my iOS code changes if you're interested.

[hansemannn]

Thanks Josh! Really helpful! Looking at the current setup that we have already, it seems like it could also be done in the ti.kernel APIs, which would be most easy for now I think?

[jquick-axway]

If you want to extend from a Titanium proxy type, then my KrollObject.m changes are needed to expose it as a JS class and provide a prototype on iOS. As you know, our Ti.UI.View base class has a lot of properties/methods and you probably don't want to replicate it all in JS in the common/kernel. That's what my changes provide. But it's up to you guys. If you're nervous about making core changes like this, then I can understand.