Multiple MVC and background work

At first I though that once you move to another MVC, the first one was kind of destroyed :-)

But I now I think they stay in memory, ready to be called again.


i have two questions to help me understand more about this, and how app work in iOS


1.

If a have a navigation controller and to reach a certain MVC I have to go through multiple MCV,

Does only the top MVC can do work or other below still can be called to work ? for example, in a MCV that has a model (without UI)



2.

i just want to know conceptually not for my exact case and not exactly about bluetooth but just a theoretical question about how a pile of MVC is used by the system.


My app has Background modes turns on, with "Use Bluetooth LE accessories"

So far it work, even if the app is not the front most app, I received data from bluetooth and log it to file, But in the few MVC that are in the pile, what if 2 of those MVC, each have an object (my bluetooth Manager) that are called when bluetooth data is received, will both be called ?




thank you

For the first question, it despends how you transition to the next controller.


How do you keep a reference of the calling controller ? Through delegation ? By keeping an instance in the destination controller ?

I believe your use of "MVC" is non-standard. You are most likely creating a viewController (the C in MVC) and having that viewController create a second viewController and having that second viewController create a third viewController (or someting similar). The second is the child of the first and the parent of the third. All exist in memory at the same time. Only one is the top viewController (the child-most third in this example) and that one is the presenting viewController - it's view (the V in MVC) is being displayed on the device.


If you want to create a Model (the M in MVC) you need to define a central location somehow. One way to do that is to pass a pointer from the AppDelegate down to and through each viewController to some model class accessible by the AppDelegate. Another way is to define a static model and call it. I like this:


//create a class that starts this way:

static Model *singleton;
@implementation Model
+(Model *)sharedInstance{
    if (singleton == nil){
        singleton = [[Model alloc] init];
    }
    return singleton;
}


//  refer to that class from any other class using:

#import "Model.h"
NSString *theModelsString = [Model sharedInstance].someStringInModel;
[[Model sharedInstance] doSomeMethodInModelWith:someObject];

No, I just do a Segue to a new MVC and from there to a new MVC, etc like a drill down navigation


because i can go back to a previous MCV, I am affraid that they could be working when I dont want to

I dont keep a reference to a previous MCV.

When i go back, i presume WillAppears will be called but the ViewDidLoad will not ?


that is for the first question, just ot understand what happen to the code of the previous mvc


also sometime you have code that on ipad with be presentement with Master detail both on screen

but the same code on iphone will only show the detail but the MAster will still be kid on running. ?

my question is theorical. I just want to understand how it work.


thank you for the singleton, I have question about that too :-)

The App delegate is some sort of singleton because it is still working even when a MVC is the frontmost part


now I need to respond to call like

applicationWillResignActive

applicationDidEnterBackground

applicationWillTerminate


when those call are made by the system, i could be anywhere in my app

some of the thing i need to do are the same where ever i am in the app, but other sutff depend on where i am


What is the best way to deal with those calls

The AppDelegate is not a singleton.

All your viewControllers will remain in memory.

You are not using any MVCs. You are using viewControllers.

i re-read the code from AppDelegate and i see i now it is not a singleton but it must stay in memory .

thank you for the view controller stay in memory, i was not sure.


i dont understand the part about not using MVC

each controler has a model and a view, isn't that mvc ?

>The App delegate is some sort of singleton


singleton object, yes - see the docs: https://developer.apple.com/documentation/uikit/uiapplicationdelegate?language=objc


"The app delegate is effectively the root object of your app. Like the

UIApplication
object itself, the app delegate is a singleton object and is always present at runtime. Although the
UIApplication
object does most of the underlying work to manage the app, you decide your app’s overall behavior by providing appropriate implementations of the app delegate’s methods. Although most methods of this protocol are optional, you should implement most or all of them."


>applicationWillResignActive; applicationDidEnterBackground; applicationWillTerminate

>What is the best way to deal with those calls


See the docs: 'Managing your app's lifecycle.

> each controler has a model and a view, isn't that mvc ?


You are writing the code in a viewController. That is "C" in "MVC".


Much of the code you are writing in your viewController controls the display elements in the view that is displayed on the screen - that is the "V" - the "V" View consists of the things you add to StoryBoard, the various UILabels with red borders and UIButtons that glimmer when touched. The thing that tells them to glimmer and show red borders and display a label with large font showing "$2.34" is the C. The actual red border and glimmer and font showing "$2.34" is the V.


Some of the code you are writing describes the inner workings of your app - like how many widgets the user has and how those widgets are distributed to his goblins and the strength of each goblin and the price of the city jewels based on water rates ($2.34) and dragon fire. That is all in your Model. Most likely you have distributed your Model code among the various viewControllers rather than consolidate it into a single class.

>>i dont understand the part about not using MVC


MVC is a software design pattern, not a trio of objects. Think of the letters M, V and C as representing abstract "roles":


— M (model): an object that holds data independently of the way the data is presented to the user.


— V (view): an object the presents data to the user.


— C (controller): an object that manages the relationship between models and views.


Normally, you can think of an application as having one data model (which may be made up of multiple model objects), many view objects (arranged into multiple view hierarchies, possibly presented at different times), connected by multiple controllers. A controller object is not necessarily a view controller — that's the most common kind, but there are other kinds of controllers.


The legacy documentation about MVC is here:


https://developer.apple.com/library/archive/documentation/General/Conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html


Keep in mind that a lot of the details in that document apply to macOS. iOS does simplify things a bit.

maybe my definition of model is not right :-)


it is true that pretty much all my model have code in it.

it my controller i try to put only the code that has to deal with the view


i also have other object connected to the ViewController. that have logic but no UI, like a bluetooth manager and a communition manager.

ok, so far i learn that previous MCV stay in memory

now, if any of those object are called by the system, will they execute


for example, if one of the model (no ui) subscribe to a notification will it respond or do i need that the most upfront MVC keep a pointer to it.

A viewController (the "C" in MVC) in memory will respond and execute any command. If it is not the presenting viewController (!self.view.window) then any changes that are made to UI elements (the "V" in MVC) will not be seen.


One more time....you are dealing with viewControllers. Your use of the term "MCV" is both dyslexic and incorrect.

Oups sorry about the MVC. ( i do have problems with my brain, i was force to retire at 47 years old because of it, and now learning is very hard.)


the way i see it on my head is like this

https://youtu.be/RAcLKlwK7VY?t=530

when he change to the second MVC , the fist one stay there.


if the first one has a pointer to an object which can respond to message, for example like new data coming

will it work respond ?

It depends on how he left the 1st viewController (and that depends on how he initially presented the first viewController). If it was by dismissViewControllerAnimated: or popViewControllerAnimated: then it is no longer in memory. If it was by tapping on a tab in a tab bar controller then yes, it is still in memory. If it is still in memory then it can respond. If it is still in memory then the app won't crash when something tries to access it.


A class created as a singleton remains in memory and can be accessed anywhere within the app. This is why the M in MVC should be different from the V in MVC. And why it is easier to have a single, or just a few, M's in an app. Lots of VC and lots of screens but one or at most a few M's and the M's can remain in memory all the time. IMHO.

Thank you PBK


i am starting to see :-)


yes i have create an app before where the model was the same for the whole app, and i was passing the refence by pointer.


in this one, i have many model, most of them small, but one big with a lot of configuration and calculation, probably too big

i might try to separe it in two with one part being only var and make it codable, and the other one with all related func.



you mention: "it depend on how the view is dismiss."


I just segue from one mvc to a new one with either a button, on a table view selection.


here is the main route a user will take,

in the first one the user select a bluetooth device (AURT) then i segue to another one to configure wich type of firmware they have on the serial data provider attach to the bluetooth emitter. then i segue to another one to verify that the data i received correspond to the firmware selected in the second mvc. and then i go to yet another one to display a collectionview which is where user should spend most of the time, and from there, the user can select a cell to modify the configuration. There are other route possible like to edit the list of previous bluetooth emittor and probably one to edit and configure firmware.


i have some controller that take care of the UI.

I also have other that dont do UI, like a bluetooth manager and another one -> communication manager that receive the data.

They are attach to a ViewController .


but for some reason, i had two bluetooth manager doing similar thing but not exactly, and i wanted to know if they would run if i left one in a previous MCV.


so now i know they might so i will create just one on this manager pass it around and adjust the delagate when i segue to another mcv.


thank you for your understanding of my limited knowledge.

Multiple MVC and background work
 
 
Q