Haiku Faster access to favorite buttons

jharrell

Active Member
Haiku is nearly perfect for me, however one feature I use constantly is the favorite buttons swipe from the bottom for opening garage doors and controlling certain lights. What I find that consistently keeps occurring is I open Haiku to open my garage door and immediately swipe up to get to the button, but if the "establishing connection" dialog is still up the favorite swipe is disabled and I end up swiping two or three or four times getting quickly frustrated with the lack of responsiveness when Haiku has not been used for a while and is doing a cold start.

I realize it takes time to connect to the controller but if it simply let me bring up the favorites and hit the button placing the command into the queue while it was still establishing connection this would greatly increase both the real and perceived responsiveness of the the system (real because the time taken to swipe and hit the button is also being used to establish connection, perceived because Haiku is responding to my swipe gesture instead of ignoring it). I also realize that the connection to the controller could fail and the queued command would never occur, again this is fine, I would rather have to hit the again rather than it prevent me from hitting the button at all.

Just a minor request, it's one of those small things that occurs daily the adds up.
 
Speaking totally out of turn, this may not be fixable; there's a lot to how Apple tells you to handle app loading and what shows on screen - and often apps will make it look like they're more "loaded" than they are; they need time to start up and get connected. Some re-sequencing may be possible, but there are surely some restrictions as well.
 
Once Haiku is up and displaying "establishing connection" with the animated spinner it is most definitely into application code and under developer control. There is a very short period of time before that point when iOS is displaying a static png that the developer specifies as the default/loading image, which goes away as soon as the applicationDidFinishLaunching delegate returns, the amount of time this takes is very dependent on how complex the applications initial uiview is as designed by the developer and how much blocking code the developer runs in main and applicationDidFinishLaunching. A simple "hello world" type app will have a start time measured in milliseconds.

So in order for Haiku to improve the situation it would need to immediately initialize some sort button command queue and initialize the favorites button view from cached settings at which point the favorite buttons should become responsive. During that time it can begin establishing a network connection to the controller on a background thread that does not block the button UI, then finally start initializing the main UI in a lazy loaded manner once a connection is established.

I don't know the internal details of Haiku, but it seems to be purposely blocking the UI while the connection is being established and is not an issue of iOS not yet handing over control. It may be difficult to change Haiku's behavior here but small things like this are huge when you use them everyday, my iPhone has pretty much replaced my garage door opener.

This is a an area where Android has an advantage, it would be trivial to add a widget with buttons for HAI buttons there that are readily available almost on par with a real garage door opener fob. iOS could actually do something like this using webclip shortcuts that jump to a url running somewhere like Haiku helper that runs a specific button in the Omni, then you could create new icons that when clicked bascially act like a button right on your home screen. I have thought about making some simple web pages on my home server using the Omni SDK to do this, but again if Haiku was a little snappier at getting to the buttons I would be satisfied.
 
Haiku does intentionally block input until a connection is established. This is by design to avoid the user issuing commands that may never execute (if the connection attempt fails).we can look at removing this, but we'll have to see how practical it is.

The idea you had re web clips for HaikuHelper should work, but you may need an intermediate php script or something similar that handles the authentication for you otherwise unfortunately as far as I know, iOS will prompt for authentication every time. With a php script handling authentication, this should give you nearly instant control.
 
By the way, does it take long for the connection establishment phase on your device? Here on Wi-Fi it's only about 1 second. Or are you on 3G?
 
Haiku does intentionally block input until a connection is established. This is by design to avoid the user issuing commands that may never execute (if the connection attempt fails).we can look at removing this, but we'll have to see how practical it is.

I figured this was the case and the reason as I mentioned in my original post, it is understandable but not necessary IMO. I can not remember the last time Haiku failed to connect, it has done it, but it is a very rare event if your Omni is accessible over cellular and WiFi. Also preventing the button press is a worse experience than pushing the button and nothing happening IMO. Thinking about this a little further I would suppose you would only want a single button press to queue and then the UI may block until fully connected and the button press acknowledged by the controller to prevent multiple button presses flushing through once the connection is established. Perhaps the button can be pressed and "grey out" until acknowledged but at least they a can be pulled up and hit and in the second it takes for me to swipe and hit Haiku is establishing the connection in the background making it feel much better.

The idea you had re web clips for HaikuHelper should work, but you may need an intermediate php script or something similar that handles the authentication for you otherwise unfortunately as far as I know, iOS will prompt for authentication every time. With a php script handling authentication, this should give you nearly instant control.

I would probably just code something up in ASP.Net on my windows server for this and embed authentication in the URL or cookie for this just like HAI's web-link does so once my device is authenticated once it's not prompting all the time(I have a SSL/HTTPS cert for my server so I don't worry about plain text auth in the request. I also use a phone level password so I prefer not to have second level auth to apps like Haiku, that is a separate feature request ;), for instance I used to use the @Home app and it did not require my pin code for arm/disarm since it already had it and used it to connect initially and I already had to enter a pin to get to the app to begin with, this would be a nice setting/feature in Haiku for those who lock their whole phone and don't need another lock in the app.

I know you can make url's to the Haiku app right? It would be interesting if you could make a web page somewhere perhaps in Helper that generates the proper links so they may be added as icons starting Haiku then immediately running a button.


By the way, does it take long for the connection establishment phase on your device? Here on Wi-Fi it's only about 1 second. Or are you on 3G?

It takes a few seconds sometimes on WiFi from what I can tell it's when my phone hasn't been used in a while and iOS is taking a little time to re-establish WiFi. For instance when it does take a few seconds to connect I can close Haiku and re-open and the the "establishing connection" dialog only flashes and it's ready to go very quickly even on 3g. I haven't been able to trigger this "cold start" that take Haiku longer manually, it probably involves letting the phone sleep for a while to do it, which is usually what it's been doing when I want to pull it out of my pocket and quickly open my garage.
 
Rolled into next update:

- Added support for 4" Retina display
- iOS 6 compatibility fix
- Improvements to weather forecast display
- Improved startup time
- Improved quick menu responsiveness on start up & during normal use
 
I am experiencing the same issue, and the new version seems a little better, apart from the issue I describe above.

What I don't understand is the reason why the connection takes much much longer and fails more often on the iphone 4 than on the ipad 2.

This happens wheter I'm connecting via 3G or wi-fi, directly via the wi-fi or going thru a dyndns server.

The ipad 2 connects almost instantaneously via wi-fi and I can't remember a failed connection (I don't use it in 3G) on the iphone it takes much longer to connect and often the connection fails.

I can justify the longer time to connect with the lower processor speed, but why fail so often?
 
I have been able to try it out, it did seem better at first, but now it seems much worse sometimes. One thing that could very well be affecting things is the upgrade to iOS 6, I know there has been some WiFi issues reported.

The issues mainly show when I haven't been connected to a WiFi in a while then I open up Haiku just as the iPhone has reconnected, such as when pulling in my driveway and pulling out my iPhone.

What is now occurring which I never have seen before is Haiku will hang on "establishing connection" (And the quick access buttons will not come up), sometime it will stay this way forever until I hit home to close the app, sometimes the app will close/crash on it's own. Restarting the usually shows the loading image(blank table UI denoting a full restart) for longer than usual and it may get stuck again. Last night I got stick in this cycle for 3-4 restarts before finally Haiku connected and let me open my garage.

I have noticed some other apps taking forever to connect on initially connecting to WiFi since iOS6 so the network connectivity could be related to that.
 
This is strange, I have not seen the issue here with iOS 6. Do the other apps hang like this too requiring a force quit?
 
Apparently iOS 6 has issues on wifi using WPA2 with AES encryption. If it is switched to TKIP or turned off its fine, my home wifi is AES. This may only be occurring on some devices, my 4S is almost unusable on WiFi while my iPad 3 seems fine.

Other apps handle the very intermittent network connectivity differently, most hang trying to download whatever data they need then have a timeout error at some point.

So I am pretty sure iOS 6 is the culprit, although Haiku definitely is not gracefully handling the situation. Perhaps if you can get a similar wifi setup with a 4S you might see the same thing.

I hear thre will be a iOS update coming very soon to address the issue.
 
Back
Top