I have a Page View Controller that's implemented in 3 files. One of them, the ModelController.m implements "generateData" method, which basically just builds and formats all the pages for this Page View Controller. Inside this method, the first thing I do is I create a Progress Bar popup with "Cancel" button. Then, inside the while() loop, I keep building the pages and at the same time, every 10th page, I update the progress bar for the user to see that the application is still generating the output.
Once the "generateData" method completes, i.e. builds all the pages (and there may be over 1,000 or even 10,000 pages depending on user input), it returns "self" to a method inside RootViewController.m, which in turn passes that generated data in "dataObject" to "viewWillAppear" in DataViewController.m, which finally displays pages in that object to the user.
It all works great, except the "Cancel" button. Because "generateData" method runs on the main thread, it blocks and the "Cancel" button becomes totally unresponsive. By "blocks" I of course mean it takes all CPU cycles, not allowing anyting else to execute, and it may take over a minute to generate 10,000 pages so I really want to allow the user to cancel the operation.
I tried to create a separate thread for the Progress Bar popup which contains Cancel button, but that won't work because all UI operations need to be performed on the application's main thread.
What almost seems to work, is when I put the "generateData" method on a separate thread and keep the Progress Bar on the main thread. This would work just fine, except that now "generateData" is put on another thread to execute in the background and returns immediately, hence returning empty "self" or rather empty "dataObject", causing a crash because there is nothing in that object yet to display.
So how can I check if the "generateData" thread is done, and "return self" ONLY when it's done? I can't really have some BOOL true/false variable and do it in a loop, because that loop on the main thread would be again blocking the "Cancel" button.
Or, alternatively, what is the correct way to implement the "Cancel" button on a lengthy method in iOS? Maybe I'm doing it all wrong, but for the life of me I can't find the right recipe for this.
Thank you in advance for the help, the code is rather extensive and that's why I didn't include any, but I hope my description gives you a good idea of what's going on. I can provide code if that would help.
The correct way to do this is to load the data asynchronously (on a background thread) and update the main (UI) thread to update the progress bar, etc... But you probably don't need a progress bar since you can probably load those pages faster than a user can flip them, so load 100 and let the user play while you continue to load the next 99,900... Except those may not be the exact numbers you should use....
If you continue to use the progress view and cancel button, then you would cancel the background thread when the user presses "Cancel", which would respond since your data generation is on a background thread...
Look into either Grand Central Dispatch or NSInvocationOperations
Here's a good tutorial by Ray Wenderlich to get you started.
Related
I'm creating a SwiftUI multiplatform app in XCode and I have a section of my code that hangs. I want to update the user so they know what's happening and are willing to wait. I originally planned to have an alert with text that changed and then planned to have a Text element that updated. In both cases this isn't shown until after the code executes and as such only shows the final message (normally the success done message unless an error made it end sooner).
Is there anyway I can have a visible message to the user through an alert or SwiftUI element that is updated right away and thus will be helpful?
The fact that the alert isn't even shown until after the code executes is bad and incorrect. This suggests that you are doing something lengthy on the main thread, and that is an absolute no-no. You are freezing the interface and you risk the WatchDog process crashing your app before the user's very eyes. If something takes time, do it in the background.
I am testing the GUI using the tools of Webdriver.io and mocha. The tests themselves are written in CoffeeScript. Some interface elements are loaded for a long time, and a rotating loading indicator appears. In order to continue the testing process, it is necessary to wait for the data to be fully loaded (that is, to wait until the loading indicator disappears). This process was performed using function (1):
wait_for_page_load = () ->
$('... load indicator selector ...').waitForDisplayed(20000)
$('... load indicator selector ...').waitForDisplayed(20000, true)
In the first line, I expect the moment when the download indicator becomes visible. In the second term I expect the disappearance of the loading indicator.
However, in the process, I was faced with a situation in which the download indicator appears and disappears too quickly. At the same time, I simply do not have time to “catch” the loading indicator, because at that moment, when I expect it to appear, it already disappears. At the same time, an error message is displayed in the console:
element ("... load indicator selector ...") still not displayed after 20000ms
I found a way out of this situation. When a similar problem occurred, I fixed only the disappearance of the loading indicator. This process was performed using function (2):
wait_for_page_load = () ->
$('... load indicator selector ...').waitForDisplayed(20000, true)
It should be noted that with the fast disappearance of the loading indicator, it is also impossible to do without waiting at all - in this case, new data will not have time to load.
However, in some situations, I cannot determine in advance exactly how long the loading indicator will be visible: sometimes it disappears almost immediately, and I cannot track the moment it appears, in these cases I have to use function (2); sometimes it rotates for a long time, and it is possible to track the moment of its appearance using the function (1).
Is it possible to write a universal function that will fix the appearance and disappearance of a graphic element, even if the element appears and disappears very quickly?
So far I have found the following way to solve the problem. In situations where it is necessary to wait for the loading indicator to disappear, I first time out one second, and then wait for the loading indicator to disappear.
utilities.wait_for_page_load = () ->
browser.pause(1000)
$('... селектор индикатора загрузки ...').waitForDisplayed(20000, true)
Thus, if the download indicator appeared and disappeared too quickly, then at the end of the timeout, it will no longer be on the screen, respectively, we automatically waited for the download indicator to disappear. If the download indicator hangs on the screen for a long time, then at the end of the timeout, we simply continue to wait for it to disappear.
The method is not ideal. Its main drawback is an increase in the total test run time. However, the method is universal and allows you to handle both situations described in the question.
For example, I have 2 buttons Change email and Change password, and each of them call functions with Alamofire request, and responce data should reload both the UI and data scheme.
The point is that this PUT requests change not only servers's data, but generate new token and get updated user's profile.
And when pressing buttons at the same time, at the same moment touches begin and end, app crash after parsing requests.
I'm blocking another UI elements(like textfields), I was trying to block another button, but when press it together, it's not works.
So how can I prevent the same time touch? I'm not good at OperationQueue, maybe thats'the way? Is there an option to check if operation not first at the queue and kill it?
Set isExclusiveTouch of your UIButton to true in order to trigger only one button action in a specific time.
This code will get all the buttons contained in the view and set the exclusiveTouch to true:
self.view.subviewsRecursive()
.filter { $0 is UIButton }
.forEach { $0.isExclusiveTouch = true }
This problem with the UIResponder object is very usual. However, your problem description is not clear and your implementation seems not so good.
Here, to resolve this quick touch event problem:
Your solution is debouncing the action event of UIButton.
Debouncing also helps to prevent multiple executions when a user mistakenly pressed a button (or any UIResponder object) multiple times so quickly that even the UI was not blocked till then. Following article may guide you more regarding the same:
Debouncing to tackle repeating user action
I'm trying to minimize memory usage in my app, and one of the things I'm doing is calling finish() in the onPause method (which I know is not the best way to do things). For the most part, it seems to be working well, but when the user clicks the back button from the next activity, it logically skips over the finished activity and goes back further. Is it possible to have that activity in the back stack and just get recreated if the user presses back?
No. This conclusion comes from the task and backstack documentation as well as the activity documentation and a general understanding of how a stack data structure works.
A stack data strucure only has 2 possible operations push/put, which adds something to the collection, and pop, which removes it. Stacks folow a last in first out model, or LIFO, where by last thing added - in your case an activity - is the first thing removed when pop is called.
Within the android lifecycle activities are generally popped from the stack when the back button is pressed. At that point onDestroy() is called and the activity is removed (you can verify this by overriding the onDestroy() method and logging the results if you want to check). Alternativly you can force onDestroy() to be called by calling finish() as you are. Finishing an activity effectivly does the same thing as pressing back. The activity is destroyed and must be recreated before it can be added to the stack.
For what you're trying to do the stack would have to incorporate some intermediate state in which an activity does not exist but rather something akin to a reference is held that, when moved to the top, would indicate that the corresponding activity should be recreated. Since this is not how the sack works - it only holds activities - that state cannont exist and so the result you are talking about is not possible.
Your Goal is to minimize memory usage,Just make use of activity life cycle, You can do this alternative(if you need)
-Just leave onCreate() method blank.(only do setContentView(layout))
-Override onResume();
-whatever you were doing in onCreate just copy paste to onResume().
-and In onPause(), Recycle your all bitmaps and set them to null(I think you are using Bitmaps thats why you are very cautious about it ). and remove your views.
Now what will happen, when you launch your new activity, onPause() would be called. that will remove your all bitmap and views. and when you come back, onResume() will be call.(onCreate will not be called). and that will again initialize your view and bitmaps.
No, i don't think that is possible. Once you finish the Activity it's gone. You could, however, implement and handle your own stack. On back pressed, you would just start the closed Activity again.
I'm automating an app that shows some overlay messages anywhere on the app for several scenarios, such as app installed for the first time etc. (I'm fairly new to Robotium too.)
The overlay displays a text that goes away by swiping or clicking on it. Also, there are different types of these overlays with different unique text on it. (let's call it Activity A)
I wanted to create a robust test case that handles this case gracefully. From the test's perspective we won't know that the activity A will be present all the time. But I want to recover from the scenario if it does, by writing a method that I can call any time. Currently, the tearDown method gets called since my expected activity name doesn't match.
Also, even if the activity A exists, there are other predefined overlay texts too. So, if I use solo.waitForText("abc") to check for text "abc", I may see the overlay 2 with the text "pqr" instead.
So I was looking for a way to automate this, and I can't use solo.assertCurrentActivity() or solo.waitForActivity methods as they just stop the execution after the first failure.
So any guidance is appreciated!
All the waitFor methods return a boolean. So you can use waitForActivity() exactly as you want to. If the Activity doesn't exist it will return false.
You can check which Activity is current:
Activity current = solo.getCurrentActivity();