openframeworks / openFrameworks

openFrameworks is a community-developed cross platform toolkit for creative coding in C++.

Home Page:http://openframeworks.cc

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ofxiOS: Proposed restructure

jvcleave opened this issue · comments

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

commented

Seeing the ofxiOSViewController's resposibilities, is there any special reason it needs to be a UIVIewController?

Couldn't it be done in a UIView?

The UIView doesn't really need anything but some properties set. However you can't have a UIView without a UIViewController.

There are also events that you will want to be aware of that the UIView wouldn't know about (e.g. viewWillLayoutSubviews).

Also in order to better control the lifecycle of the ofApp you will want to do this in the UIViewController