Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ofxiOS: Proposed restructure #5472

Open
jvcleave opened this issue Mar 4, 2017 · 2 comments
Open

ofxiOS: Proposed restructure #5472

jvcleave opened this issue Mar 4, 2017 · 2 comments
Labels

Comments

@jvcleave
Copy link
Member

jvcleave commented Mar 4, 2017

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

@jvcleave jvcleave added the iOS label Mar 4, 2017
@martinell
Copy link
Contributor

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

Couldn't it be done in a UIView?

@jvcleave
Copy link
Member Author

jvcleave commented Dec 21, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants