Multiple settings/conditions per plugin
I would really like to rebrand a few of my plugins and include more functionality but I'm limited to just one setting and one condition per plugin. Could we get that restriction lifted for the next version?
For example, my "WiFi IP Address" plugin could become my "WiFi Plugin" where I could add additional WiFi related settings.
skylarsutton
shared this idea
After reviewing all of the possible implications, we have decided to support multiple conditions and/or multiple settings within a single plug-in package. This already works for all versions of Locale. We’re still in the process of updating the developer documentation with this new information.
5 comments
-
skylarsutton
commented
Just a follow up. I can confirm this functionality is working... the "Locale SD Card" plugin contains two conditions for a single receiver and appears to be functioning with no issues.
-
AdminCarter
(Admin, two forty four a.m.)
commented
It works.
You can't have two BroadcastReceivers for the same Intent action though, because Locale wouldn't know which receiver was associated with which Activity.
So a single ACTION_FIRE broadcast receiver will get the Intents from all the EDIT_SETTING Activities. Its up to the EDIT_SETTING Activity to put enough information into the EXTRA_BUNDLE for the ACTION_FIRE receiver to differentiate between the different plug-ins.
-
skylarsutton
commented
Are you sure that it works for all versions? Last time I tested I received a warning that two plugins with the same package name were found so it dropped/ignored the second plugin.
Just sanity checking.
-
skylarsutton
commented
I don't understand what you were driving at with the following points:
* Backwards compatibility? Plugin descriptions would simply need to state "Requires Locale 1.x"... it's not much different from apps that include a "Requires Android 2.x" in the description. Also to your point about how/if other plug-in hosts choose to implement this... should that really be Locale's concern? The plug-in API version could be advanced and it's up to each host how/if/when they implement. This would be a feature that sets Locale apart.
* Memory Leak? In general, I don't understand what you were driving at here. Are you saying some third party wrote crappy code and now you have to clean up the mess? If so, you could handle it by killing the faulty setting/condition rather than the faulty APK.
Re-branding the plugin and using a single UI screen is an option... but one I will not pursue as I think it leads to an awful user experience. I prototyped something out and it was simply confusing and overly elaborate.
One of the reasons I prefer Locale over Tasker is that the condition/setting model is very easy to understand and use... my 65 year old Dad picked it up in less than a day. The proper user experience would be unique settings for: WiFi (IP Address), WiFi (Proxy), WiFi (On/Off), WiFi (Gateway)... as opposed to "Advanced WiFI".
I can accomplish that by publishing many unique applications, but it leads to a fragmented plugin market and takes away from the value to the end user. A single purchase of a "plugin package" is much more likely to be accepted by consumers.
-
AdminCarter
(Admin, two forty four a.m.)
commented
The plug-in API officially supports a both single condition and a single setting within the same APK.
In terms of multiple settings or multiple conditions within a package, this works in the current version of Locale but is not documented, recommended, or supported. Technically, this is a bug rather than a feature.
The Locale plug-in API specification is published under an open-source license. There are hundreds of plug-ins, as well as a few other apps that implement hosting plug-ins. Supporting multiple settings (or multiple conditions) within a single APK creates backwards compatibility and cross compatibility issues with other plug-in hosts.
Certain plug-in conditions also contain a memory leak (there's no leak within Locale), but supporting only a single condition per APK allows us to fix that memory leak in a future Locale update. :)
Could you rebrand the plug-in, keeping the existing package and Activity name but simply expand the functionality exposed by the single plug-in Activity?
