Partage
  • Partager sur Facebook
  • Partager sur Twitter

Understanding the lifecycle of an iOS app

lifecycle of an iOS app

    7 octobre 2019 à 13:21:00

    An iOS app follows a typical lifecycle. In the beginning, the app is simply an executable; it’s not running, lying patiently in wait for a user to click its icon. When the app starts, it goes through numerous initialization steps. During this transitory period, the app is in the inactive state. The app is indeed running (and in the foreground) but will not receive events, so it can’t interact with anything during this time. The app then transitions to the active state. Now, the app is making merry, and you and the app are making sweet music together. This active state is the app’s useful state. 
    At some point — mostly when another app starts, say, a phone that’s triggered by an incoming call — the iOS runtime will put your app in the background. At this point, the app is in the background state. Most apps stay in this state for a short time before being suspended. However, an app could request extra time to complete some processing (such as saving its state into a file for use the next time it starts). Also, an app meant to run in the background will enter and stay in this state. Note that apps in the background can and do receive events, even though they don’t have a visible user interface. learn more from the ios app development course 
    An app in the suspended state isn’t running code; however, it is using power and the processor. The system moves an app to this state whenever it needs to further conserve resources and does so without notifying the app. If memory runs low, the system may purge the app to create more space.
    1. After the first initialization of the app, appDidFinishLaunchingWith Options is called, which in turn invokes the portion of the app’s code that sets up its user interface.  The user then sees the app. The app now sits in an event loop, where it waits for user interactions. 
       2.  When a user interacts with the app, an event is triggered,    and a callback method tied to the event is invoked. Most often, the callback method consists of code written by the app’s developer, although it could be reusable code provided as part of the iOS framework. 
    3. Once the callback method is done, the app goes back to its event loop. This sequence of actions (of events triggering callback methods) proceeds until the app receives an event that causes it to either shut down or go into the background state.
    • Partager sur Facebook
    • Partager sur Twitter

    Understanding the lifecycle of an iOS app

    × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
    • Editeur
    • Markdown