openframeworks / openframeworks/openFrameworks

ofxiOS: Proposed restructure

Open
#5,472 2 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

iOS
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.

ofxios current - page 1

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

new ofxios - page 1

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.