I have an app where on start it checks the user's position and then get the weather for that spot. Mainly wind direction and speed.
It does the normal check to see it it has Intenet connection, but I found that if there is connection, but very slow the app freezes on launch screen (doing the check on startup).
I have a class that does this, which is called at startup after which a home screen is loaded.looking around, GCD seems the right way to go, but can I get the answer to be displayed in a label in the home screen when it is finished with getting the data? Main tread would have left, or rather bypassed that class and have arrived at the main screen.
Would I need to maybe use something like Notification Centre to help the label updating and re-load?
Thanks for any thoughts or code snippets.
Jorgen
PS. I am trying to keep the app iOS 5.1 to keep old iPads happy.
GCD seems the right way to go, but can I get the answer to be displayed in a label in the home screen when it is finished with getting the data? Main tread would have left, or rather bypassed that class and have arrived at the main screen. Would I need to maybe use something like Notification Centre to help the label updating and re-load?
Yes, I think you're on a very good track here. Let's keep the two issues separate, though:
After doing your background work, still in GCD, you're going to come back onto the main thread because you now want to update the interface. That's easy and straightforward.
If you have a communication problem, a notification can be an excellent solution. You can broadcast the need to update that label, and if the correct view controller exists and is listening, it will get that information.
Having said that, though, you should think about your architecture, since there may be a better way than a notification. Once you are back on the main thread, why are you not in a place where you have a way to know whether the correct view controller exist and to talk to it directly. I'm not saying the notification is bad/wrong! I've used this solution myself, and a notification is quite a standard way to come back from, say, an NSOperation. I'm just saying, give it a little thought.
Related
First of all I'd like to say sorry in case my question is dummy, I'm really new to iOS and what to understand how thing are going on. Imagine such a situation - user taps on home button and the app starts to collapse, but immediately after taping on home button user taped on some UI element. So, I'm wondering how the iOS will handle this? I tried to do some tests using breakpoints, but since it just test I can't be 100% sure. It seems that if the UI interaction event will happen before the system will call willResignActive then the event will be fully processed and if the system will call willResignActive first, then the even will be discarded and won't be handled at all. Is this correct, or I missed something? Thanks
First, why do you want to use this in your app? If a user presses a button exactly in this time, it's okay that the action is not handled.
The only thing you have to keep track of is that whenever the button gets pressed and let's say you store a file without a completion handler it could be that you present an alert which is saying that everything went well but you actually not saved the file because the user left the app in this time.
But since you're never doing critical actions without completion handlers, in my opinion, there's no need to make sure that this doesn't happen.
If I got you wrong, just comment!
I see a lot of posts about people trying to obscure sensitive information from their app snapshot so that its not readable in the multitasking app selector. But I have a different problem.
I'm trying to save as much memory in my app as possible when it enters the background, and one of my app's views has a lot of subviews that is the largest memory usage of my entire app. I've written code to remove and delete these subviews, which i then recreate when the app returns to the foreground (I've actually called these methods in the resign active and did become active methods). Everything is working fine but when I delete these subviews, the view correctly appears rather empty, just in time for the system app snapshot to be taken. So as the app is restored this empty view is displayed for a short time before the app renders properly.
I'd like to be able to manage these views but I guess it needs to happen AFTER the app snapshot has taken place.
Actually profiling the app's memory usage I've noticed that the large (70meg) memory usage that's present whilst the app is in the foreground drawing these views drops right down when the app is backgrounded even if i don't manually delete the views myself. The documentation is clear that the actual backing CA layers etc are all handled by the system so thankfully the majority of memory savings are already being made by the system itself. But still there's another 5-10meg that I can save by doing what I've described here so it feels like a good idea. Is it possible though?
I wonder if I should request to be left running a little longer which I think i saw was possible may be the solution? Especially if the app snapshot is taken before this extra time is given to the app.. This would mean the screenshot is correct and the memory is saved a split second later.
Thanks for your time, Cheers!
I'm not sure why you're worried about 5-10 megs of RAM. The system will reclaim lots of memory by blowing away the backing layers, as you said, and recreating them when the app is foregrounded again. But what, exactly, do you hope to accomplish by reclaiming more memory yourself?
Unfortunately you can't control when the snapshot is taken. You could, I suppose, do a dispatch_after to have your view destruction code happen after a delay, but this wouldn't be deterministic since you don't know when the snapshot will be taken. And it's also possible that the code won't be run at all if your app is asleep when the dispatch timer goes.
I think you may be optimizing prematurely.
Add a snapshot view on top of your view hierarchy before removing the subviews.
UIView *snapshotView = [view snapshotViewAfterScreenUpdates:NO];
Not exactly sure that will help save much of those few MBs you worry about, but that's the common way of doing something like this.
I want to have some information drop down from the top of a view, stay on the screen for a second or two, and then go back up out of the view. I have search for displaying notifications and/or banners. All I get is either push notifications (which I don't need to use) or iAds banners.
I'm working on a barcode scanning app and I want to briefly show the value of the barcode shown without requiring the user to tap on anything. How can I accomplish this?
Don't use notifications and banners, because that might not work: the user can turn them off. In any case this is not a notification of anything, so it's a misuse of notifications.
Just do what you described, yourself: animate a view onto the screen, and then (in the animation's completion handler) use delayed performance to animate the view right back off the screen after a short delay.
You should use a view which manages its own state (INCOMING, STAY PUT, OUTGOING). This way you can reduce the memory footprint and many other bugs in the process. I coded something for a similar process. Check it out
It seems like the fade animation between the launch screen and my first view is really slow.
I don't think it used to be like that. Is there a way to control the speed of that transitional animation?
I looked at some apps on my phone and the launch screen doesn't fade as slowly as mine. What things could I have done to affect that?
(No I don't have slow animations turned on, only the fade animation is slow)
In WWDC 2012 video iOS App Performance: Responsiveness they enumerate a whole list of issues that have impact on the app startup time, ranging from attaching to unnecessary frameworks, optional linking to frameworks that you really could make required, the use of static initializers, overly complicated initial scenes, too much information stored in preferences, etc.
That video covers a range of topics, like the above, which impact startup time. In the demonstration, they show how one might benchmark the startup time. Unfortunately, in my experience, there's a good chance that you might not be able to do anything to fix this issue (e.g. you need certain features and therefore need certain frameworks), but it's still an illuminating video and it might give you some ideas of things you can try to alleviate the start-up performance issues.
If your app splash screen show more time, so please check following things in your app.
1. AppDelegate.m
in didFinishLaunchingWithOptions method have you called any heavy method which takes more time for finish task if yes then change that method location, basically in appDelegate class don't write any heavy methods.
2. first view of your app.
check viewDidLoad() method, if you call many method or any heavy method from here then your launch image will show still your control not come out from viewDidLoad method, so if you want call any methods at view launch time then call them from viewWillAppear or viewDidAppear method (in viewDidAppear method don't call any UI related methods)
I never figured out what was going on here, but the next day when I started up xCode and the simulator it was back to the normal loading time.
Boy, this is frustrating.
I sent in my app to Apple after months and months of development. It was quickly rejected due to the fact that they said it was unresponsive at the home screen. Here is the screenshot they sent me:
Now, when I build the exact archive of the app that I sent them, I have no such issues:
The buttons were created in the storyboard file and were IBOutlets, but the highscore label that you see was created programmatically. Is it possible that the storyboard file didn't upload properly? I have already messaged them in the resolution center about it and tried to submit it again to see if it would work next time, but I was wondering if anyone knew anything about this issue.
From above screenshot, I've understand something that issue related with network error. See, they were tested with flight mode. According to apple guidelines, it should be go on in home screen without much more delay. At least show an alert for this issue. Just test with this scenario, you will get this.
When they said it was unresponsive, it may be due to the fact that its stuck for certain reasons, check if you make any API call at the viewLoad method, also, if the UI may turn unresponsive incase you are performing some heavy operation on the main thread, try using a background thread of these operations
It's been an extremely long time, but I thought I'd say what was wrong in case anyone comes across this in the future. Basically, I had created the buttons in Interface Builder but was re-instantiating them in viewDidLoad of my view controller. Since IBOutlets are weak properties, they were thus being released. Why that wasn't happening when I ran it on my computer, I have no idea. Still puzzles me to this day.