Redesign of android App

[pmithrandir]

Hello,

I'm using the android app with Garmin, and so far, it's working ok by night.

But, I have the feeling that the app is not showing the right information to answer user or developer needs.

As a user, I don't really care how the system detects a seizure, I just want to know when it's happening. Meaning that all graphs are from my point of view not useful.
Normal user will only

• setup the tool
• let it run in background task until there is a seizure or a warning
• mute seizure
• qualify seizure alarm / warning. (real, test, false alarm...)
• The best detection algo possible
• some visualization about the last seizure / success rate, etc...
• tips to calibrate the threshold after some usage. (custom recommandation for power, heart value, etc..)

As a developer, I believe that what we need is:

• as many qualified seizure / warning as we can get
• maximum data sharing in order to feed the machine learning
• debugging view, that will globally contain our current main view.

I don't think the current design of the application allow us to maximize the 2 usages.

Do you agree with my understanding ?
If yes, what would be the next step to go there ?

Regards,
Pierre

[jones139]

I'd be quite happy to implement another main screen - it is easy to make the user interface selectable in settings (at the moment you can select between the original main screen and the new one with the swipeable graph screens) - It should not be possible to disrupt the actual seizure detection function by trying different user interface designs, so these changes are much more relaxing to make.

But I am not a UI designer (as you can tell :)), but if someone would like to design one, I'm happy to implement it.

[jones139]

I am wondering if it is nearly time to do something more radical with the Android App. We do not have automated tests for it, which makes doing changes very difficult and time consuming because we have to persuade ourselves that we have not broken anything - then release it for beta testers for a while to see if there are any phone-specific issues to flush out.

Ideally we would have an automated test suite that we can run on any new version to make us pretty confident that everything that used to work still works, which would speed up development. Now we could do this by starting to design and then write some java tests and get them working on the current version so we can run them on future versions. The issue is that this is very tedious so I am unlikely to ever get around to doing it......

The other option is to develop tests in parallel with a major re-write of the app - essentially do the re-write using test driven development. There are a few options for this:

1. Translate the app into modern java - this is essentially what @AroonPro has done with the draft V5...but although it is working well for his AndroidWear implementation it is not working for me, so needs a lot of un-picking.
2. Switch to Kotlin - there are two advangages to this - we can do the UI using the Jetpack Compose framework which seems quite easy (avoids having a separate XML description of the UI screens - it is all done in code; also Kotlin has a 'Coroutines' concept which is a neater way of doing background tasks - and the app has a lot of those. Again a couple of years ago @AroonPro suggested this but I was not keen on a major re-write because of the difficulty doing testing - so we would want to develop tests in parallel.
3. Switch to a multi-platform framework (Flutter or Apache Cordova) - when I first wrote the app I considered PhoneGap but it could not do the hardware interfacing that I needed so I did not use it - but now that @Farmer-Eds-Shed has demonstrated using BLE heart rate monitors with Cordova, I can see it would be possible now - and this would give us the option of providing IOS support which a surprising number of people ask for.

I don't really know what to do - all of these are major undertakings, so I am going to do some work on detection algorithms first, which might mean some minor updates to the Android App - but maybe over winter we could look at this?

[AroonPro]

One thing, what in v5 in difference has is the package of SdData. It has been a real challenge for me to match my watch app to the phone app. One of the reasons is the Camel versus CAPITAL writing of Hr or HR mHr versus mHR and all the Hr related variables. I have done a program wide replace of mHR to mHr, in turn for all of the Hr variables is flattened out. Also one other project wide replacement has been done. Which I Will later provide. Because of the mHr and mHR, some of the inner SdData public variables are double present. It has also the master branch as of date just before my last push of v5. Interesting it is where the break of Garmin is hiding. That as the code of the master branch is pulled in. Diffing is not easy to spot the whole picture. Remote conference call multi teer coding would be a great idea, however needs careful planning. @jones139 flowcharts and following documentation in fat, sat and other review

May help

[pmithrandir]

Hi,

I think we should first describe what the app is supposed to do. That would give us the amount of work needed, and maybe some priorities.

Today, I think it's doing too much on some part, not enough on others.

From my understanding we really need 4 parts:

• A report section to enrich the data (to have more data in order to improve the algo)
• a driver per device that help to connect to all sort of devices and proxify the connection to a generic core.
• A calculation mechanism to execute algorithm against generic data
• a module to send data to OSD API

All display that we have currently could be sent to a developer page behind the scene. (I don't think users really care about power, heart beat, etc... They want to know if it's ok, warning or seizure)

That being said, if I had to sort the different approach, I would say that:

• My 1st guess was to prioritize multi-platform frameworks, but I ended up thinking on how difficult it is to maintain a software on different system (My team did it in my previous job). IOS comes with a lot of pain point (auto killing app in background is not a small one) and the ecosystem is very locked in the end. We might have many difficulties and a need to test on these specific, and expensive, devices. Knowing that you can find android device for 50€ 2nd hand, I would say it's good enough.
• If we would really want to support IOS, maybe a small companion app that only serve network source to warn in case of seizure. That would allow a watch + android app on patient side + ios app on carer side.
• With almost no graphical objectives, (we almost only need to display texts) I don't think the language used on Android matters a lot, but it's outside my main area of expertise.

@AroonPro Regarding your issues with SDApp, maybe we can find a way to uniform the different terminology, or use that "driver" idea to translate it to a generic format.

[jones139]

Thank you both for your thoughts. It is very helpful . I will draw up a table of features that are essential, nice to have and optional, then we can discuss that. Splitting into separate apps might be good as long as we can share settings etc. Renaming variables etc is not a problem. At all - just need a single pull request so it is easy to check it is harmless. Thanks! Graham

…

On Fri, 21 Jun 2024, 22:10 Pierre Bonneau, ***@***.***> wrote: Hi, I think we should first describe what the app is supposed to do. That would give us the amount of work needed, and maybe some priorities. Today, I think it's doing too much on some part, not enough on others. From my understanding we really need 4 parts: - A report section to enrich the data (to have more data in order to improve the algo) - a driver per device that help to connect to all sort of devices and proxify the connection to a generic core. - A calculation mechanism to execute algorithm against generic data - a module to send data to OSD API All display that we have currently could be sent to a developer page behind the scene. (I don't think users really care about power, heart beat, etc... They want to know if it's ok, warning or seizure) That being said, if I had to sort the different approach, I would say that: - My 1st guess was to prioritize multi-platform frameworks, but I ended up thinking on how difficult it is to maintain a software on different system (My team did it in my previous job). IOS comes with a lot of pain point (auto killing app in background is not a small one) and the ecosystem is very locked in the end. We might have many difficulties and a need to test on these specific, and expensive, devices. Knowing that you can find android device for 50€ 2nd hand, I would say it's good enough. - If we would really want to support IOS, maybe a small companion app that only serve network source to warn in case of seizure. That would allow a watch + android app on patient side + ios app on carer side. - With almost no graphical objectives, (we almost only need to display texts) I don't think the language used on Android matters a lot, but it's outside my main area of expertise. @AroonPro <https://github.com/AroonPro> Regarding your issues with SDApp, maybe we can find a way to uniform the different terminology, or use that "driver" idea to translate it to a generic format. — Reply to this email directly, view it on GitHub <#186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLSY6XUD2MCJ2SKOY3QHLZISJEHAVCNFSM6AAAAABHEOQSS6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNBTG44TK> . You are receiving this because you were mentioned.Message ID: <OpenSeizureDetector/Android_Pebble_SD/repo-discussions/186/comments/9843795 @github.com>

[Farmer-Eds-Shed]

If going the total redesign route, I'd second the simplified UI for most users with a night themed color scheme, the current UI is probably a little intimidating for non techies. Perhaps default to basic UI with an advanced option too, you could display heart rate and maybe just a few bars to show excessive movements like an old school graphic equalizer.

Cordova or Flutter could really improve cross platform compatibility but @pmithrandir is right getting applications to run in background on IOS is painful, there are some workarounds that people use but they may get the app refused from the store and manually installing apps is not really an option. You also need a mac to be able to build for IOS, probably not that big of an issue but just something else to keep in mind.