github.com/.../progress.mc
If you can use insert code on the forums you code would be a little more fun to read. Or.. use a gist on github/gitlab.
You can start a progress bar as the first view:
Code: https://gitlab.com/waterkip/ciq-demo-watch-app/-/blob/progressbar/source/BuggyApp.mc
Result: https://imgur.com/a/Js3dc3X
Unless you want to require user input, you don't want to do this in a BehaviorDelegate. More likely in initialize() for your main view as well as your glance view for a widget/glance. I'm think I understand what your code is trying to do. but it can probably made to work with far less code.
As I am trying to reproduce app with your approach i noticed that it works only with selected devices. For eg. when I run it on vivoactive 4 it crashes:
Error: Unexpected Type Error
Details: Failed to start CIQ Application
Stack:
Encountered app crash.
In that case, an intermediate view would be best. I would take the approach with a boolean for firstview and if not firstview you pop the view (essentially quiting the app) and with first view you forward directly to the progress bar view.
As to where to put the logic, I think it doesn't really matter, the delegate is the controller so you could do it there in the init or you add it to the view (you'll need to extend it) in the init. I dunno what kind of view it is, it doesn't inherit from WatchUi.View so I dunno what kind of API is has to be shown on screen. So you'll need to put most logic in the init code. Which sounds a bit weird to me. Because it is object instantiation, so you'll be doing a lot of logic while creating the view and/or delegate.
You could try to do it in a seperate view, start the webrequests and push the progress view while that is running. You'll need to have some kind of timer that triggers a popView so the progress bar gets removed as soon as your webrequests are done.
This can all be done with a single view, When getInitalView is called when a app starts, it returns a view and optionally a delegate for that view. In initialize for that view, do the makeWebRequest, and set a flag as to what should show in onUpdate(). And change the flag in the makeWebRequest callback (real data or error for example). You could also use user input to trigger the makeWebRequest my way of the delegate that already exists. (maybe if there was an error so the request could be re-tried. One view, one delegate.
If this is a widget, there is also getGlanceView where in that view's initialize, it does the makeWebRequest. There no input in a glance, and less memory that in the full view (can be as little as 28k, and even less if a background service is used (combined they can only be 28k on some devices)). One view, no delegate.
I think you think this is much more complex that it is.
I cannot make requests work when running in constructor. Even updated to your single view suggestion, but still getting -300 error. Also decided to drop progress bar, as it adds uneccessary complexity and I just want to make this widget work.
-300 is a time out. Can you tell if the server is seeing the request and trying to respond? Maybe the server is ignoring it for some reason. What do you see when you use the url and params in a web browser?
I do what I suggested in a bunch of things and it works fine.
Heck, it could even be that whatever you are using for a data connection is really slow,
I don't. I told him how to get from an opening view to the progress bar view and how I would implement the fetching. I split the problem in two bite size chunks.
But you are right, it can be all done with the progressbar view. You just need to extend it and add a timer where you first complete the init with a timer call that starts the actual fetching and than that functions pops the view back once the web requests are done. You than have a progress bar for the webrequests. And you have a view somewhere that will do something with the data you have fetched. Done. Ok, so two views, because you also need to have a view that shows the data in the UI.
I think that connection or server is not the problem as before requests worked fine. I use heroku to host my proxy to trim size of request from public traffic data provider. For eg. test tequest