v1.6.1 loads much slower and stalls.

Hello Adam,
I am hoping you may be able to assist with this issue.
Since updating to v1.6.x DomoPad has been loading very slowly. Sometimes I think my device has frozen but it hasn't. I didn't have any loading concerns with v1.5.x
At first I had tweaked the app to open to a particular CP but that really made the app come to a crawl. The app now will simply open to the dashboard which is fine.
I have cleared the cache, and fixed permissions but the result has been the same.

Any tips or suggestions to get DomoPad back to its glory?

T.I.A.

Since updating to v1.6.x DomoPad has been loading very slowly. Sometimes I think my device has frozen but it hasn't. I didn't have any loading concerns with v1.5.x
At first I had tweaked the app to open to a particular CP but that really made the app come to a crawl. The app now will simply open to the dashboard which is fine.
I have cleared the cache, and fixed permissions but the result has been the same.

Hmm, nobody else has complained (yet?)... The selection of what screen to start first should not have any significant effect on the initial startup, though a control page certainly will take longer than the Dashboard (which will be the shortest startup).

Can you describe what you are seeing when it appears to free? I mean, nothing on screen, you see a plain white screen, etc.?

Hello Adam,
Thanks for the response! I stand corrected as there was nothing wrong with DomoPad.
The issue was the result of using another app called "Amplify" to turn off some battery greedy Google Play Service wakelocks.

Would you mind sharing which DomoPad wakelocks are tied to Google Play Services wakelock?
I would actually like to turn off as many wakelocks that are associated with Google Play Services once and for all. From trying different ROMs and Kernels so much of the time Google Play Services is usually at the top of the battery drain issues.

Thanks,

I am pretty sure there are only two processes that require a wake lock in the application:

1. Push Notification Received -- this should be a very short lock, just long enough to post to the shade and save it to the device. None of the notifications will generate further downloads of data or anything, so I doubt this is an issue.

2. Indigo Update (w/ Location) -- if you have the application set to update Indigo with its current status then it makes a web request to post the information; this should generally be quick but of course the device CPU will remain non-Dozed while the request completes. If you have it checked to update Indigo with location then, of course, the wakelock becomes far more intensive as the current location is requested and must wait for location services to return.

I don't see the push notifications having any issues on performance ever in real-life situations as it is only ever initiated by an incoming push notification. The status updater will execute every ~15 minutes. It turns itself off if the device notifies it of a low battery (I believe this is governed by the Battery Saver settings in terms of when this occurs, but I am just listening for the system to tell me). That hasn't had any measurable impact on my battery BUT my GPS also locks extremely quickly. If your device takes a while to lock (e.g. older Samsung phones could take several seconds, or possibly devices without assisted GPS) then of course the impact could be a bit heavier.

I haven't looked into it much, but I think Android O is going to changes some things up for receiving location information in the background. Not sure the impact yet, if any.

Adam

Thanks for the tech support Adam!