Custom Splash Screen Solution for iOS Apps

Overview of the Issue

As a developer, we’ve all been there - our app’s login functionality is working, but there are some quirks that need addressing. In this article, we’ll delve into one such issue and explore possible solutions to ensure a smooth user experience.

Background: The `didFinishLaunching` Method

Understanding the Delegate Pattern

In iOS development, the delegate pattern is used extensively for handling events and notifications between objects. When an app launches, it typically creates a single instance of its main application window controller, which becomes the root view controller of the app’s navigation stack.

The didFinishLaunching method is called after the app has finished launching and is ready to receive user input. This is where you can perform initial setup tasks before presenting the first view controller to the user.

In our case, we’ve modified the didFinishLaunching method to check the user session validity with the server. If valid, it loads the main view controller; otherwise, it displays a login view controller.

However, there’s an important point to consider: the didFinishLaunching method itself doesn’t load any view controllers because it waits for the response from the server.

Problems with Loading View Controllers

The Two-Pronged Problem

We’ve encountered two primary issues here:

Error Message: When we try to load a main view controller immediately after calling didFinishLaunching, we get an error message indicating that we must have exactly one main view controller loaded.
Ugly Display of Intermediate View Controllers: If, despite the error message, we decide to load a view controller while waiting for the server response, it appears on screen before our app is fully launched.

Exploring Solution Alternatives

Introducing the Splash Screen

One viable solution to these problems involves creating an intermediate splash screen that loads the necessary data and only presents the root view controller once the data has been received from the server.

Here’s how we can do this:

## Creating a Custom Splash Screen

In our case, we create a custom `SplashScreenViewController` that contains a loading wheel image and loads any required data. This approach allows us to bypass the immediate need to load view controllers while waiting for the server response.

Key Elements of the Solution

Custom SplashScreenViewController: We’ll create a new SplashScreenViewController subclass, which will contain the necessary elements (like the loading wheel image).
Loading Data: Within our app’s delegate, we’ll load the required data in the background while displaying the splash screen.
Switching to Root View Controller: Once all necessary data has been loaded from the server and validation is complete, we’ll switch back to our root view controller.

Step-by-Step Implementation

Creating the Custom Splash Screen

First, let’s create the custom SplashScreenViewController. This will serve as a simple container for our loading wheel image:

## Code: Custom `SplashScreenViewController`

```swift
import UIKit

class SplashScreenViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // Create and display the loading wheel view
        let loadingWheelView = LoadingWheelView(frame: view.bounds)
        view.addSubview(loadingWheelView)
    }
}

// A simple `LoadingWheelView` subclass for demonstrating our custom splash screen
class LoadingWheelView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        // Create a UIActivityIndicatorView to display the loading animation
        let activityIndicator = UIActivityIndicatorView()
        activityIndicator.frame = CGRect(x: 0, y: 0, width: 100, height: 100)
        self.addSubview(activityIndicator)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Loading Data and Switching to Root View Controller

In our app delegate’s implementation of the didFinishLaunching method, we’ll load the necessary data in a background thread while displaying the splash screen:

## Code: Background Thread Loading of Data and Switching to Root View Controller

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Create and display the splash screen with our custom loading wheel view
        let splashScreenViewController = SplashScreenViewController()
        window?.rootViewController = splashScreenViewController
        
        // Perform background thread operations to load data from the server
        DispatchQueue(label: "background", qos: .utility, attributes: [.concurrent], options: []).async {
            // Load necessary data here...
            
            // Once all data is loaded, perform any additional setup tasks as needed
            
            // Switch back to our root view controller now that all data has been loaded and validated
            DispatchQueue.main.async {
                let rootViewController = RootViewController()
                window?.rootViewController = rootViewController
                
                // Perform any necessary setup tasks or transitions here...
            }
        }
        
        return true
    }
}

By implementing this custom splash screen, we can elegantly bypass the need to load view controllers immediately while waiting for server responses and maintain a smooth user experience throughout our app’s launch process.

Additional Considerations

While the above approach demonstrates how to create an effective custom splash screen solution, there are additional considerations worth noting:

Loading Large Data Sets: For apps that require loading large amounts of data from servers, consider using asynchronous loading techniques and caching strategies to minimize network requests.
Managing Splash Screen Visibility: Implement a mechanism for controlling the visibility of your splash screen based on app launch circumstances, such as changing between different states (e.g., from “loading” to “running”).

By staying aware of these factors and effectively implementing custom splash screens within our iOS applications, we can ensure seamless user experiences even when working with potentially complex data loading workflows.

Conclusion

In this article, we explored an issue surrounding the execution order of view controllers in an iOS app’s launch process. By understanding how didFinishLaunching methods work and exploring alternative approaches to handling background tasks and data loading, we have seen a practical solution involving creating a custom splash screen.

By adopting strategies like these for managing our apps’ complex workflows, we can create smoother user experiences that enhance the overall quality of our applications.

Last modified on 2023-07-11

Understanding the Login Process in iOS Apps