07-04-2019, 03:47 PM
Terry,
Having an API would be wonderful in terms of the contributions MobileSheetsPro users could make to extending the application and even support automation (as you have described). The main difficulty is in figuring out how to handle this well in Android across all supported OS versions (as some are more restrictive than others). I haven't done a lot of research into implementing a plugin-based architecture with an Android application, and the little I've seen points to using services with AIDL. I'm not really sure how well that will fit in with the way MobileSheetsPro works, and my fear is that in trying to support something like that (which would be a considerable amount of work), it could have a negative impact on the application as a whole, as I could introduce bugs or performance issues. The question is how much the majority of users will benefit from being able to add plugins, because I would be spending a lot of time and effort working on that instead of other features which have also been requested. If plugins become commonplace, it also means that users could start encountering bugs and issues due to plugins, but they would come to me for support (greatly increasing the complexity of offering support, which is already a considerable time investment).
I also would need to see how easy it is to support plugins in a C# UWP application. From what I've seen so far (https://social.msdn.microsoft.com/Forums...=wpdevelop) it points to having to write code to support communication with external applications. So it seems to be similar to Android.
Perhaps if we clearly define what should be possible through IPC with an external application, it may be possible to add support for a more limited set of functions related solely to the database. It still would be a large effort I imagine, so I'm not sure where it will fit into the schedule priority wise. It really depends upon how much demand there is for something like this in order for it to be worked before other things that are commonly requested.
Thanks,
Mike
Having an API would be wonderful in terms of the contributions MobileSheetsPro users could make to extending the application and even support automation (as you have described). The main difficulty is in figuring out how to handle this well in Android across all supported OS versions (as some are more restrictive than others). I haven't done a lot of research into implementing a plugin-based architecture with an Android application, and the little I've seen points to using services with AIDL. I'm not really sure how well that will fit in with the way MobileSheetsPro works, and my fear is that in trying to support something like that (which would be a considerable amount of work), it could have a negative impact on the application as a whole, as I could introduce bugs or performance issues. The question is how much the majority of users will benefit from being able to add plugins, because I would be spending a lot of time and effort working on that instead of other features which have also been requested. If plugins become commonplace, it also means that users could start encountering bugs and issues due to plugins, but they would come to me for support (greatly increasing the complexity of offering support, which is already a considerable time investment).
I also would need to see how easy it is to support plugins in a C# UWP application. From what I've seen so far (https://social.msdn.microsoft.com/Forums...=wpdevelop) it points to having to write code to support communication with external applications. So it seems to be similar to Android.
Perhaps if we clearly define what should be possible through IPC with an external application, it may be possible to add support for a more limited set of functions related solely to the database. It still would be a large effort I imagine, so I'm not sure where it will fit into the schedule priority wise. It really depends upon how much demand there is for something like this in order for it to be worked before other things that are commonly requested.
Thanks,
Mike