farkam135 / GoIV

https://www.reddit.com/r/goiv
Other
372 stars 138 forks source link

Design about a plugin system #460

Open Blaisorblade opened 8 years ago

Blaisorblade commented 8 years ago

Lots of features have been requested that don't "belong with" GoIV but would make sense to have together. We could think about some way to enable optional features so they don't impact people not using them. This was last brought up for #457, but I think the gym helper could be a better application.

We could support plugins by sending intents, but we'd have to scan more info anyway and starting a plugin could be cumbersome. Also, starting a separate activity would probably have overhead.

Alternatively, plugins could simply be code in our repo and APK, but that is enabled only if requested by the user, and that is otherwise modularized. An example for me are IITC plugins (http://iitc.jonatkins.com/?page=desktop).

Having all the code in our repo also has a social scaling problem (all development would have to coordinate), but that's something we can solve separately.

nahojjjen commented 8 years ago

Are there enough plugin ideas / interest in plugins for a design specific for plugins?

Blaisorblade commented 8 years ago

That's a good question. Ideas mentioned included, beyond #457, also the gym helper and movesets. But I agree we might want to collect more.

There was also a thread on Reddit, with tons more ideas: https://www.reddit.com/r/GoIV/comments/510bug/looking_for_community_thoughts_on_an_app_based_on/ I confess I haven't looked closely at the prototype (https://github.com/GoOverlay/GoOverlay), pinging @waterfoul. I've looked again at the post, and my main question for me is "would the plugin interaction create additional annoyances for the user".

For instance, @sarav proposed using a share dialog to share scanned info with other plugins by showing a share-like dialog (or something), which sounded a bit cumbersome to me. I think @waterfoul plan was to have something more integrated, but I'm not sure what's possible.

sarav commented 8 years ago

I think having the "plugin" code as part of GoIV defeats the advantages and purposes of a plugin. It's not just about bloat or memory. Allow plugins also opens up people to develop features without have to actually coordinate with us. Think Tasker and Tasker Plugins.

We should be able to figure out a way to allow some plugin to add UI components without having to share the code base.

waterfoul commented 8 years ago

Hey, sadly life happened so I haven't had time to track back to the GoOverlay project. Basically the idea was to move all of the screen scraping bits to a single apps and move all of the logic bits (like calculating arc positions and IVs) to a secondary app.

The big disadvantage is that people have to install multiple apps just to make anything work (think tasker or xposed). To combat this I was planning on making a way to roll a plugin and the base together into a single app using a script. That way plugin developers have the option of releasing an all-in-one option for people who don't need multiple plugins.

I was also planning on allowing the user to fine tune how much battery they wanted to burn on the overlays by adjusting the scan frequency (possibly also making it a button). I'd recommend people go look at the code, there really isn't all that much. You can also look at the bug tracker on that project for some of my ideas.

sarav commented 8 years ago

@waterfoul I did some major battery improvements. So, if you eventually do continue the work, remember to pull it in.