Add Event Trigger functionality

[willblaschko]

I've added some quick functionality into the base project that allows the Android version of the game to trigger String typed events that the Android app listens to and then can act on. This will allow things like:

• Interstitial Ad triggers
• Review Solicitation
• Social Sharing
• Etc.

I'm not 100% happy with overloading your JavascriptInterface, but no other really clean way occurred to me.

You could argue this is not core functionality, but I think it's a key piece of taking games to the next level (and I've seen a fair amount of feedback requesting this across different RPG Maker MV forums).

Happy to hear feedback or for you to make any changes required.

[felixjones]

I think after we tried the extensions idea I much prefer doing it this way. However, I don't think using the bootstrap boot JS interface is the best thing to do, there could be circumstances where the boot JS interface is not used: https://github.com/AltimitSystems/mv-android-client/blob/b482e8beb348ec85587bca867750c9183d6e409d/app/src/main/java/systems/altimit/rpgmakermv/WebPlayerActivity.java#L71

What I have been leaning towards in my head is the idea of simply having a JS interface called "Android" and bundling extended functionality such as this into that.

A message system is an okay solution, however it does involve the developer diving into Java - and avoiding needing developers to touch the Java is a goal of this project. I also think a simple string message might not be enough, perhaps we should be using Android Intents here and writing a JS wrapper for that.

The 3 example use cases you gave can be done in JavaScript and do not need any special behaviours in MV Android Client to perform (although I admit there are Android SDK features that would make Social Sharing much nicer).

What we should do is start an "Android" JS interface for MV developers to use and carefully integrate features into that. For example; Android Storage is a big one that we had with the extension system and I'd like to bring back at some point.

Also your commit removes the Altimit Community copyright notice in "webview_default_page", try not to make changes to files not related to your feature.

Lastly, I am thinking that tutorials for specific functionality should be separate markdown files that are linked from the ReadMe. Better yet, we could probably use the GitHub Wiki feature to do something more complete.

What are your thoughts?

[willblaschko]

What I have been leaning towards in my head is the idea of simply having a JS interface called "Android" and bundling extended functionality such as this into that.

That seemed like overkill for the single event solution I proposed, but I agree to separate it if there are multiple functions (especially if there are places where the Bootstrapper isn't called).

A message system is an okay solution, however it does involve the developer diving into Java - and avoiding needing developers to touch the Java is a goal of this project. I also think a simple string message might not be enough, perhaps we should be using Android Intents here and writing a JS wrapper for that.

Agreed for more advanced functionality. I actually started with showAdvertisement(TYPE) and a second function but since I had only three initial use cases, I condensed down to a single string event.

Brainstorming now:

• showAdvertisementInterstitial()
• solicitReview() (the review solicitation can be done inside the game, this function would send an Intent to open the game page in the Play store)
• solicitSocialShare() (same as above, except with a share intent)
• ...?

The 3 example use cases you gave can be done in JavaScript and do not need any special behaviours in MV Android Client to perform (although I admit there are Android SDK features that would make Social Sharing much nicer).

I think my use case may be different than most--I'm an Android developer with almost no understanding of game design and new to RPG Maker. I'd rather do most of this at the Android layer when it deals with device-native functionality. To keep the game itself as platform agnostic as possible.

For less experienced Android developers who want to implement this functionality, it's a lot easier to copy-paste some Android code (especially if we give a good template and all they need to do is swap in their Admob ID).

What we should do is start an "Android" JS interface for MV developers to use and carefully integrate features into that. For example; Android Storage is a big one that we had with the extension system and I'd like to bring back at some point.

Is there any concern with pollution/conflict with RPG Maker's JS? I didn't take a look at how good they are about wrapping their JS. If we use the "Android" namespace, we should be fine unless they add native functionality in the future.

Also your commit removes the Altimit Community copyright notice in "webview_default_page", try not to make changes to files not related to your feature.

Sorry, I pulled that out when playing around--good catch. I'll be more careful with my commits in the future.

Lastly, I am thinking that tutorials for specific functionality should be separate markdown files that are linked from the ReadMe. Better yet, we could probably use the GitHub Wiki feature to do something more complete.

Sounds good. Most repos have a high-level overview of functionality and then individual links to the specifics, that's probably a good approach if we expect more than a couple.

What are your thoughts?

I agree with all your points above--do you want to own creating the base Android JS interface and I can help flesh it out with individual functionality/examples?

[felixjones]

For now I don't have the time budget to work on MV Android Client, so if you don't mind receiving and iterating on feedback then you're welcome to implement the changes discussed here and I can review them and provide direction where necessary.

The plan for now should be implementing an Android JS interface as a separate class file, so Java developers can directly extend it as desired, and probably starting off with replacing the message system with an intent system - which would at some point involve a way to convert JS object parameters to Bundles for Intent putExtras (JS -> JSON -> Bundle). Java developers can then use Android Intents as normal, which could facilitate in avoiding the need to hard-modify existing code.

EDIT: To clarify, what I am describing is re-implementing your proposed message system with Intents to be more "Androidy" and flexible.

An Android JS interface may need some JS code to be ran to set up wrapper JS classes, such as an Intent implementation in JS, plus some of the conversion from JS to JSON would need to be done JS side so wrapping the actual JS interface functions may be necessary.