AAPS Client Limitations, thoughts

I am sure that I am bringing up a topic that has been discussed at great length - with many differing opinions and points of view. I apologize that I was not a party to previous discussions, and if these are limitations of developer time and effort or legal matters, then I apologize up front. My goal is to determine if I am missing anything in terms of the trade-offs between excellent DM management and safety when it comes to the AAPS client. BLUF - why are certain features are included in the client app and others excluded? I do not believe there are any technical hurdles that would prevent the AAPS client from both (A) displaying the same information as the master or (B) having the same functions and control as the master.

The use cases for AAPS client that I can think of are:

• Parent(s) managing a child (or anyone managing an insulin pump for another person for any reason)
• Backup phone in case of loss/damage?
• Remote monitoring by a 3rd party (in a read only situation?)

None of these situations would preclude the AAPS client mirroring exactly the function and display of the master in terms of safety - in fact very much the opposite. While the SMS features do allow remote commands, including bolus, I am not willing to use it in most scenarios because I do not have access to the information about why previous decisions have been made or any details of the calculations involved.

It appears that at least the following functions are not available in AAPS client:

• Bolus
• Preferences
• Loop Status/settings
• Pump settings, history and configuration
• SMB calculations and status
• Temporary Basal modification
• Maintenance (Settings export - clearly needs to be separate from the client app itself)

The one area that I believe there is reason for concern over is possible confusion between AAPS client and master on the same phone (controlling two different people), however there a lot of options for mitigating that risk - additional authentication (2FA as used in SMS), notifications and/or confirmation. Authentication/verification to enable full control should be implemented over feature removal in the client.

I am diabetic and I have a 5 year old daughter with T1DM, and I cannot possibly state how grateful I am for the existence of this project and the example it sets. I have spent a great deal of time and money on phones, remoting software, rooting, bypassing security features, etc. so that I have full control and visibility - and yet it all fails with poor signal as not enough bandwidth to successfully remote. Stating the obvious, my daughter is not in a position to be aware of or make any decisions regarding her insulin pump, and I am struggling to think of a scenario where someone is capable of making insulin pump decisions and at the same time has someone else viewing/controlling their insulin pump via the AAPS client. I appreciate any insight.

I truly want to thank all the devs of this this excellent capability. I'm not strong at java, capable with python/C/x86 assembly, but certainly willing to contribute.

This is a broad discussion of AAPS client limitations, listing bolus, preferences, loop status, pump settings, SMB status, temporary basal changes, and maintenance. Start by reviewing the client implementation and the prior discussions referenced in the issue; no file, test, entry point, or concrete acceptance criteria is provided, so the intended scope and definition of done remain unresolved.