I’m designing quite a large App and on startup it will create sessions with a few different servers. As they are creating a session which is used across all parts of the app its something I thought would be best in App Delegate.
But the problem is I need the session progress to be represented on the screen. I plan to have a UIToolBar at the bottom of the main menu which I don’t want to cover with the progress bar but cover the UIView above it.So the way I see it I could do it a few different ways.
1) Have the App Delegate establish the sessions and report the progress to the main menu class so it can represent it in the progress bar (will I have any issues doing this if the sessions are created in a separate thread?),
2) have the App delegate display the main menu (UIView with a bunch of buttons and UIToolBar) and have it track and display the progress (I have never displayed anything in the App Delegate but assume you can do this but its not recommended) or
3) have the App Delegate just push the main menu and have the mainMenu class create the sessions and display the progress bar.
4) I think the other way to do it is to create the sessions in a delegate class and have the delegate set to mainMenu rather than self (AppDelegate), although I’ve never used anything other then self so not sure if this will work or if I will be able to close the thread (through calling super maybe?) as its running in the AppDelegate rather than the delegate of the class.
As I’ve kinda said before the sessions are being created in a class in a separate thread so it wont lock the UI and I think the best way is the first but am I going to have issues having it running in a separate thread, reporting back to the app delegate and then sending that message to the mainMenu view?
I hope that all makes sense, let me know if you need any further clarification. Any information is appreciated
Cheers,
Presumably the state of the connections will impact on your app’s functionality. I would probably think in terms of a connections manager object which is able to initiate connections, maintain their state and respond when queried about their status. In the same way as a singleton object will return the existing object or create and return a new object of none exists, a connections manager doesn’t even need a “make connection” method, just “get handle” – if the connection is not open it can try to make it so.
You also mention status must be reported on the main screen. Having a manager object that is able to do tasks of indeterminate time (opening a connection to a host that may be ready, busy, far away or just plain broken) in the background and then report progress to the main thread so the UI can be updated (remember, no UIKit access in secondary threads) seems ideal and it keeps your View distinct also.