I have a tabbed iOS application with each of the tabs having some sort of json request so the view loads ever so slightly slowly. I want to remove that lag completely so I'm wondering if there is a way to call the ViewDidLoad function from each of the classes during the login phase of the application.
if (login == "Success") {
UserDefaults.standard.set(true, forKey: "isUserLoggedIn");
UserDefaults.standard.synchronize();
DispatchQueue.main.async {
// Load all resources here
}
}
I can understand this can be bad practice if the app is very large, but I think in this scenario the app isn't huge, but the lag between the view controllers is enough to be annoying. I would rather have the user wait at the start for 3-5 seconds whilst everything loads, and have a smooth experience once inside. Is there a way to do this?
You shouldn't call the lifecycle functions of the viewcontroller for yourself. The viewDidLoad function will be called when the view has been loaded.
Apple: This method is called after the view controller has loaded its view hierarchy into memory.
So calling let _ = viewController.view will trigger the view creation and the call of this function.
But i think it's much better to have a startup phase instead. Think about a 'startup'-screen that downloads everything you need (with maybe a spinner and a text) and moves automatically to the content (the tabbar controller) when done. That may also fix the problem of a low network connectivity (think about a download that take a minute for example). You may display that screen modally above or as screen before the tabbbar controller.
If you don't like the idea of a startup phase you may also design your ui responsive. Start the download whenever needed / regularly and update your ui according to the results when ready. The ui will be fast then, but uses last known data. The meaningfulness and implementation depends on your content.
Update
On second thought: If you already have a server login screen, why not download the content directly after the successful download as part of the login? Users do not know if you are still checking the login or downloading some necessary data. You may say that login is only successful if server login AND download are finished successfully.
Related
I'm having an issue with this code (I have it in didFinishLaunchingWithOptions). I need it to finish executing the code inside before the app continues because it sets up some critical things in core data. It sends this to the background though and starts running the rest of the app and it doesn't finish quick enough for the data to be usable.
DataManager.getDataWithSuccess { (data) -> Void in
//code to execute here
}
How can I force the app to wait for this code to finish before moving on?
You shouldn't block the didFinishLaunchingWithOptions method from returning so that it can wait on an asynchronous task. It's crucially important to note that iOS applications are only given a limited amount of time to complete launching before the application is killed by the operating system.
An approach I have used in the past when waiting on asynchronous things to happen that need to happen before I really launch my app is to create a LaunchViewController. The interface for this view controller matches perfectly to the app's splash screen. From an end-user perspective, you can't even tell we've left the splash screen.
Here, we do any set up code such as asking your DataManager to get data. Then, when it (and any other set up actions) completes, you simply present the next view controller in much the same way you'd move between any other view controllers.
A huge positive side effect here is that you can have much nice looking animations from your splash screen into the first screen of your application.
An iOS app I'm creating shows a setup screen upon first launch which requires data to be written to the database.
Upon launch, I need to access this value form the database.
If it is set, launch main view controller
Else show setup view controller.
As far as I'm aware theres two ways I can do this, programmatically setting it from the AppDelegate or using an initial View Controller as a splash screen and performing the look up and segue there.
What would be the best way to approach this? Is it wrong to do a database lookup in didFinishLaunchingWithOptions?
Using a splash screen is probably the better option as it provides better scope for modification in the future and allows you to update the user on progress. It is fine for the app delegate to run logic to determine how the app starts but you should endeavour to keep the app delegate minimal and focussed.
I very much doubt that you would get this approved (if your goal is the App Store). Your app delegate needs to create a window, and set a rootViewController to that window before it returns YES in appFinishLaunching:
You simply do not have enough time to check with a server before creating the first viewController and you'll be creating poor interface if you try. I suggest the first ViewController will need to be informing the user that it is checking with the server with an activityIndicator or something. The best :)
According to Apple documentation, "To help your widget look up to date, the system occasionally captures snapshots of your widget’s view. When the widget becomes visible again, the most recent snapshot is displayed until the system replaces it with a live version of the view."
What I am seeing, however, is that the snapshot is removed from screen before the live view is prepared. This results in a flash effect where the old snapshot is taken off screen, the view is blank for a split second, then the new view appears.
Is the developer responsible for making the transition between the snapshot and the live view seamless? If so, what is the strategy behind doing that? I don't see any way to directly control that transition.
I was able to mitigate the effect greatly by moving data loading to
widgetPerformUpdateWithCompletionHandler: and keeping drawing in viewWillAppear:, but I do still see a flash once every 15 (or so) opens of the Notification Center.
I had this same issue and finally figured out the issue I was having with my widget. It turns out it was related to a misunderstanding about the Widget Life Cycle on my behalf.
From the documentation I thought that the today view would keep a 'snapshot' of my widgets state until the widgetPerformUpdateWithCompletionHandler method completion handler was called with success.
This does not seem to be the case. From what I can see the 'snapshot' is just used when the Today View is animating in (when the user pulls down the notification centre). As soon as the today view is loaded and stationary your widget is loaded from scratch (inflated from xib if using) and viewDidLoad is called. At this moment you should populate you widget with cached data (not from a web request). If you don't you will see temporary data from your nib. This is what causes the flashing.
When viewDidLoad is complete widgetPerformUpdateWithCompletionHandler is called which allows you to fetch fresh data. When the fresh data is fetched you should call the completion handler and cache the data it so it can be used when the widget is loaded later on from scratch (in viewDidLoad).
A simple way to cache the data is in user defaults.
You need to be careful about your compilation handler in the
-(void)widgetPerformUpdateWithCompletionHandler:(void (^)(NCUpdateResult))completionHandler
method. What happens is that your extension probably has an error and everytime view appers it is being called again. Try to attach your extension to debugger(Debugger->Attach to Process-> your extension id) and see the result by putting some breakpoints.
I am new to Parse and iOS app development, so please pardon my question if the answer is obvious.
Does a function execution continue if the next view in a view hierarchy (nav controller) is loaded?
I currently have a view where the user takes a picture, which is then displayed on screen. I want to begin the upload and packaging of this image immediately, to save time. So my question really deals with the [saveInBackground] and [getObjectInBackground] functions. If the user taps the button to go to the next view, before the upload is completed, will the functions stop their execution or continue until it completes?
Thanks
Siddharth
As long as you use the function saveInBackground, your photo will be saved even if switching views. If you used saveEventually then the photo would be saved whenever it can (if there is no internet it will upload it when internet becomes available).
I'm developing a small app on top of core data. At startup, I need to launch a maintenance task - fast but important -. To run this task, the app delegate must open a UIManagedDocument, and perform various checks on it. The app views must not start until the checks are completed. Because opening a UIMD is asynchronous, the app delegate isn't done when the first UIview tries to access the doc. The application then crashes due to a race condition because the app delegate and the view are trying to open the doc at the same time, while the doc state isn't yet finalised.
I'm using a storyboard, so segues are pretty much in control of the OS... Next time, I'll do it all manually..
What would be your recommendations ?
Note:
1)I can not perform the task when the app. goes into background state, because if it is brought back up again, avoiding inconsistent states between the underlying database and what's displayed in the view will be very tedious.
2)For the same reasons, performing the maintenance task during normal execution is not easily done.
3) All views access the UIMD via a singleton, according to the code proposed here
Setting a mutex lock in the UIView isn't my preferred route, because the screen remains black - no data -, while displaying the tab bars, until it is released by the app delegate.
Is there a way to have the app delegate wait for a signal before it hands the control over to the UIViews ? In this case, are there any gotchas ? I suspect this is probably not the recommended way to do, and iOS might kill the app if the delegate stays too long waiting for the maintenance task to complete. What would be "too long" in this case?
You could do it more elegant way. The first view the user will see must be some kind of SplashView - just an image with progress indicator. It should stay on top while your task is going on. It's not too important how you're showing this view. You can set it as the first in your storyboard or just create it manually in applicationDidFinishLaunching message.
Then in your task send a NSNotification when it's about to finish and in the observer in your AppDelegate just hide your SplashView and present your first view with valuable content.
You can even add some visual effects for transition between those views and your app will look really great! :)