search

UniversalDevicesInc / UD-Mobile-iOS

Issue-only repository for tracking issues related to the UD Mobile iOS App
6 stars 0 forks source link

UDM App Navigation Unresponsive - No Known Causality #9

Closed BitArtOnLine closed 3 years ago

BitArtOnLine commented 3 years ago

UDM app had been running on iPhone for about 30 hours. Opened app, it displayed the main folders (programs, devices, etc.). Attempted to open Devices folder, but folder did not open. Repeated touching of the folder appeared to do nothing, but did notice a subtle blinking of the folder bar in the list. Touching all other folders in the list elicited a similar lack of response. Suspended, and closed app (different inactive states in IOS). Restarted, but no change in behavior. Continued to repeatedly touch the list in various locations to see if it was a regional, or functional failure. Eventually managed to get s single response - the touched folder opened and populated subitems. The New page, however, was unresponsive. My guess would be the View thread, or View Controller event receiver in some sort of disconnected status, or even race condition.

BitArtOnLine commented 3 years ago

(Additional Info) After encountering app loss of functionality, iPhone was shutdown and restarted. App remained in unresponsive state (so persistent). The only way to restore original functional operation was to completely uninstall UDM and reinstall.

JavierRefuerzo commented 3 years ago

Hi,

I have looked through the Android code base and I am now very confident the multiple 200 bug firmware I mentioned in PM is not caught, I'm sure there is a combination of both issues. However, we will have to wait until this is caught in app or firmware is upgraded to 5.3.2. as this bug will cause many issues within app. I'll see what can be done ASAP, however we have another project that requires all of our attention at the moment.

BitArtOnLine commented 3 years ago

Planning update to 5.3 this week, time permitting.

Reporting this behavior because app was stable and had been operating for 20+ hours. Opened after ~=4 hrs inactivity and it was unresponsive. It impressed me because had to completely uninstall app before it regained functionality. If you are doing mallocs, it could be a garbage collection issue, where a pointer/etc. is freed before it should be.

Please fix at your own pace. I am testing, not expecting a finished product.

JavierRefuerzo commented 3 years ago

Thanks, I'll look into it. I had a few ANR myself with but were followed with a crash.

BitArtOnLine commented 3 years ago

This is a repeatable condition: App working fine; It sits idle for a few hours (suspended); Open app; Whatever list is being displayed (home, Devices/Scenes/etc.), operates sluggishly. It resists scrolling, will not free-wheel (continue to scroll with momentum movement), and even jumps back up the list. Touching any folder does not convey the action/event to the dismay handler logic. Repeatedly trying to open a folder eventually causes app to crash. This erroneous state can be "cursed" by scrolling the currently displayed list to the bottom (no matter how this is resisted by app), then scrolling the list back to the top. This may have to be repeated one or two times. The app regains full functionality when the free-wheeling function begins to operate again. After that folders can be opened as normal. Guessing that this a bug handling returning from the suspended state, re-establishing the list array pointers/connecting view to view model events/callbacks (however you implemented). Scrolling the list all the way down and back, seems to re-establish the correct view list array structure to view-model controller linkages.

JavierRefuerzo commented 3 years ago

Sorry for the delay, I could not reproduce crash on my devices but have fixed the issue causing the app run slowly on startup (too many calls to refresh). The app will now only refresh when new values are available for a given query. Please let me know if this is fixed in 0.0.7

BitArtOnLine commented 3 years ago

This fix is very helpful. Presently the app becomes unusable for up to 1.5 min after opening, so this update will cure that. I see it vividly since I have so many nodes in the ISY.

You can try to replicate the crash by navigating during the initial status update period, when (whatever you have discovered), causes the sluggish response.

Looking forward to ver x.7. Thanks

On Mar 9, 2021, at 4:22 PM, Javi @.***> wrote:

 Sorry for the delay, I could not reproduce crash on my devices but have fixed the issue causing the app run slowly on startup (too many calls to refresh). The app will now only refresh when new values are available for a given query. Please let me know if this is fixed in 0.0.7

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

BitArtOnLine commented 3 years ago

The responsiveness now is great. I haven't tried to replicate crash issue (think it may be fixed too since app operating in orderly manner).

Status does not show up on a viewed page when it is opened. After a period of time status does seem to appear. Can you explain how or when status is updated for pages?

JavierRefuerzo commented 3 years ago

Is this related to issue #13 ? or is this for the home list? Node status is cleared when the app is closed, it will then add individual status as received from the ISY subscription. On my local network (about 150 nodes, 500 status values) it takes about 7 seconds, remote on a good connection is about 9 seconds, both times for all node status. This is much slower than Android (3 seconds, and 5 seconds) but due to no native SQL support in swift it is a limitation we will have to accept.

BitArtOnLine commented 3 years ago

Yeah, think so - just read 13. Can you selectively refresh mode statuses on the current/displayed page?

When you check the crash issue and are satisfied, you can close issue 9. Seems to be fixed.

On Mar 10, 2021, at 12:54 PM, Javi @.***> wrote:

 Is this related to issue #13 ? or is this for the home list? Node status is cleared when the app is closed, it will then add individual status as received from the ISY subscription. On my local network (about 150 nodes, 500 status values) it takes about 7 seconds, remote on a good connection is about 9 seconds, both times for all node status. This is much slower than Android (3 seconds, and 5 seconds) but due to no native SQL support in swift it is a limitation we will have to accept.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

JavierRefuerzo commented 3 years ago

Closing as this appears to be fixed with limiting refresh.