Just wondering if this could be a useful feature or API? This would try to connect to Particle with a timeout and then retry after the retry delay.
This would be useful for battery and cellular devices with system treading enabled. This would be different from the cmd waitfor()
Then what does this do that the waitfor() command doesn't allow you to do?
The more, and better, arguments you have for something like this, the better chance it has of getting picked up.
The wait for is blocking this other call would not be blocking.
So if your device is portable and battery opereated trying to connect via celluar. There is a very high battery drain during this connections time, but the device needs to perform other tasks while it’s waiting to connect.
I agree, and I already proposed a timout feature for Particle.connect() a while back.
@Moors7, the problem with any “secondary” function like waitFor() is that it would need to be executed in order to help, but since Particle.connect() doesn’t return from its potentially “endless” endeavour any subsequent function can’t help before it’s called 
Particle.connect() (and other long-blocking calls) should be made cooperative to allow user code to control them and not “execute and pray” hoping it’ll return in time.
The problem is, when you leave the system thread in charge of the reconnection it often fails to reconnect, but when you want to take control of the connection in the application thread, you will lose the decoupling between (unpredictably blocking) cloud connection and business-logic and hence the prime goal of the application thread will be impaired.
This is what I keep arguing about in this issue
It seems to me that this and what would appear be a recent increase in threads about electron/photon connection handling are all related. (Did 0.7 make something here worse/more obvious???) I’m with @ScruffR (I think) on this, these events shouldn’t be blocking , at least not to the extent they are now. It shouldn’t be necessary to babysit the system calls either, they should be well behaved and unobtrusive from the getgo. I’m slightly concerned the new Mesh devices are going to divert resources from getting Electron/Photon to a place where the debates that seem to happening on issues like this are largely solved - a nice reassuring firmware V1.0+ say. Indeed could not blocking behaviors like this in the middle of a mesh could stop the whole mesh working?
These devices are essentially sold as controllers with IoT capability baked in, however if the IoT bit interferes with the ability of the application thread to do some actual control they are inherently compromised.
Is something like this being considered for 0.8.0?
I like the idea of the user firmware having the ability to know when connections can’t be made. I think it would help devices with connection issues function, like how desktop apps have something like an offline mode.
I think Particle needs some incentive (
"pressuring") to realise that the current behaviour isn't quite as satisfying for users as it's supposed to be.
I realise that devs do see some difficulties in pulling the non-blocking approach off, but it would just add so much more flexibility for cases where the "auto-reconnect" built into the system just keeps failing and impacting business-logic of application firmware.
+1 for wanting this behavior fixed 
+1 waiting for this fix
What do you think @bsatrom?
Just to be precise, with SYSTEM_THREAD(ENABLED) I haven't seen the blocking of Particle.connect() although an implicit WiFi.connect() might occupy the µC enough to give the appearance of being blocking - even beyond the stated ~2sec.
So the proposal for a timeout would be most important for single threaded mode and also apply to the WiFi connection process.
+1 to @ScruffR’s comment. Using SYSTEM_THREAD(ENABLED) should yield the desired result. Beyond this, what would be an example use case for being in single-threaded mode and achieving a non-blocking result?
A use case is any where the developer wants to very carefully follow the flow of code execution without the jumping around of SYSTEM_THREAD(ENABLED).
Thanks @tommy_boy, can you be more specific? System threading runs your application loop on a single thread, so you wouldn’t have to jump between threads to follow the flow of your user firmware. Are you suggesting that you’d like to be able to follow system execution as well?
Sure, in my application, I use SYSTEM_THREAD(DISABLED), and I have a lot of code that is run in a SINGLE_THREAD_BLOCK because it’s all timing specific. It’s mostly a bunch of DS18B20’s and analog circuitry that I’m sampling and performing a lot of logic on. Besides the photon, which is running as the master device, there’s an atmega328 and attiny2313 communicating with each other over I2C, another timing specific process. You guessed it too, I don’t link the idea of not being able to easily follow the execution process of the Photon. This is especially true during debugging. My application is controlling a critical system so I need to be able to quickly and easily identify exactly where my cpu execution is occurring. I don’t like how I can’t control the retry process of Particle.connect in my online applications. It can be frustrating to see the photon essentially get halted on this process if the cloud connection is spotty when my application code made no such call - meanwhile, my system-critical code is not executed.
I’d also like to add that enabling system threading in my application causes the freememory to return 6k less available bytes. Without threading, free memory returns about 29k bytes. With threading, I’d be dangerously close to the 21.5k byte cutoff for the Photon to crash.