openframeworks / openframeworks/openFrameworks
ofxiOS: Proposed restructure
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.4k
- Forks
- 2.6k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 9
Description
I was recently working on a project and ran into some issues with the current ofxiOS implementation. (primarily around app lifecycle, orientation, fbos and ExternalDisplay) In troubleshooting I ended up with a different approach.
The current ofxiOS works by:
- Create an ofAppiOSWindow
- Create an ofxiOSApp
- Create a ofxiOSAppDelegate, subclass of it or implement your own ofxiOSViewController (seen in Native Examples)
- If a custom ofxiOSViewController is not used, ofxiOSAppDelegate on launch creates an ofxiOSViewController which in turn creates an ofxiOSEAGLView.

Issues:
- The ofxiOSApp is required to be created much sooner than it may need to be.
- ofxiOSEAGLView is given responsible for deleting the ofxiOSApp. I typically prefer the class that creates an object be responsible for deleting it.
- While updating ofxiOSWindow size and position, ofxiOSWindow messages ofxiOSEAGLView (via a singleton ofxiOSGetGLView()) creating an cross-dependency.
- The ofxiOSWindow (and ofxiOSEAGLView) is a Singleton implementation but doesn’t necessary have to be as with External Display you could theoretically have 2 different ofxiOSApps running on 2 different screens.
- ofxiOSEAGLView doesn't really need to exist as it is just a UIView with a layerClass flag set.
Proposed Approach:
Give more responsibility to ofxiOSViewController. An ofxiOSApp is primarily just a object inside of a UIViewController and its lifecycle can be better contained as such.
New ofxiOSViewController Responsibilities:
- Creation of the ofAppiOSWindow
- Creation and Management the Renderer
- Creation and Deletion of the ofxiOSApp
- Updating the Renderer’s dimensions

I used this approach in a recent project and it worked quite well. It also allowed me more flexibility with External Display, solved #5033 (and with other modifications allowed it to be ARC compatible).
Thoughts/feedback appreciated - I will set up an example project with my approach in case someone wants to try it
Here are the links to the UML (requires sign in)
https://www.lucidchart.com/invitations/accept/eaac0819-3447-4d8b-9473-92579145cb9a
https://www.lucidchart.com/invitations/accept/fe5c3256-6417-4a2f-903a-9b4044fcec84
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the current ofxiOSAppDelegate, ofxiOSViewController, ofxiOSEAGLView, ofxiOSWindow, and ofAppiOSWindow lifecycle described in the issue. Compare those relationships with the proposed controller responsibilities, including renderer dimensions and ExternalDisplay handling. Done means an agreed, implemented restructure that addresses the listed ownership, singleton, dependency, and lifecycle issues.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, ios
- Domain
- mobile-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100