UI element updates does not work when purchase completed - Google billing client 4 - kotlin

I have changed over to Google billing client 4.0 library. Since then when purchase is completed, my ui elements updates does not work.
I was trying to check if they are not in UThread anymore or something, but it is not working properly still.
billingClient!!.acknowledgePurchase(
acknowledgePurchaseParams
) { billingResult ->
if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
saveSubscription(purchase.purchaseToken, sku)
mainAct?.runOnUiThread {
Toast.makeText(context , "Vásárlás sikeres", Toast.LENGTH_SHORT)
.show()
delegate?.purchaseSuccess(
actProduct,
prevProduct,
purchase.purchaseToken
)
}
}
}
When the acknowledge is done, my UI elements should be updated. There is a menu item should be enabled and in the purchase page a textfield should show that the item is purchased. The code is running, but the UI elements are not updated.
Once I move to a different fragment, the menu item turns to enabled, so it seems to me that somehow the UI is not refreshed.
In the code mainAct is the context to the MainActivity.
Any idea?
The code was running properly on Billing library 3.0.3 and runOnUIThread was not needed at all.
Still getting weird behaviour with this library. I was setting up the billing at the same time as my users log in to the app and go from the login page to the first fragment. This fragment has a recyclerview and this recycler view was filled with data from the web. The recycler view was randomly not showing the elements, even if they were loaded and the adapter was properly updated.
One you moved to another fragment and back the recycler view was showing the data properly.
As I said, the first time call when the billing server is approached the UIThread is messed up and even if data labels or menus are updated, the updates were not showed.
So something is definitely wrong with this library.
Any idea?

This behaviour is a bit weird. The documentation is saying the most of the billing library functions can be run from any thread. Only few needs to be run on UIThread. AcknowlegdePurchase should be running on AnyThread.
I have put the Toasts into runOnUIThread and the inside the delegate functions all commands I have also put inside a runOnUIThread closure.
Now it works as on billing library 3.0.3. But the documentation was not telling anything about any of these changes, so it is really unclear, why the behaviour has changed that much between the two libraries.

Related

Xamarin Xaml force update interface elements

The post has been rewritten to better fit the current problem.
I have a button x:Name="selectVesselButton". On button click, it tries to establish a connection to a server, which takes a sec or two for to do. Originally, I wanted the button to be grayed out while it was downloading and deserializing the json file from the connection.
My old code (before async, and trying to update the button):
// disabling the button to prevent spam clicking.
string buttonText = selectVesselButton.Text;
selectVesselButton.IsEnabled = false;
selectVesselButton.Text = "loading...";
// retrieve data for speed page.
RetrieveData();
// redirect to next info block if build was successfull.
FocusSpeedblock();
// enabling the button again.
selectVesselButton.Text = buttonText;
selectVesselButton.IsEnabled = true;
The issue with this code was that the button visuals did not update until the RetrieveData() was finished, defeating the purpose of doing that at all. This was because the code for updating the interface and the code for downloading and deserializing the object were both on the same thread.
However, following Ivan's advice, I made the downloading and deserializing Async, which fixed this issue (more like moved it).
This works fairly well, but I am still having some trouble updating the interface automatically. I have some labels that need to be updated based on the json file output. The value of the labels update on the background, but only update visually once I interact with the labels (I.E. scrolling the scrollview they are on). Check edit 3 for more detail on that.
EDIT 3:
When the second thread is finished, it should call the UpdateSpeedLabels() and update some labels. However, they update in codebehind, without instantly updating the interface. They only update if I interact with those labels.
The preferred way of doing this on Xamarin is with data binding. As you opted out of this it is still possible.
What you need is to ensure that your long task is not running in the UI thread as it blocks it and prevent its updates. You do this by using Task.Run(() => { your task code }); . However you can't update your user interface inside the Task.Run as it is not running on the UI thread and it would crash the app, so you need to use Device.BeginInvokeOnMainThread(() => { your UI code }); inside Task.Run for that part.

Xcode 7+ Is there a way to Preserve App State after Recompiling

My application has deep navigational chains of 8+ screens deep (Wizard-style). When i'm editing a View Controller, and i want to make a quick visual change and re-test, As a tester, I have to go through the full flow to end up where I was before recompiling, in the same Data state. Is there a way that Xcode can somehow preserve the application state, and re-run the same view controller?
If there was an automated way to detect the last launched screen, and re-display it after the recompile, that would save a lot of developers a lot of time.
I realize something like this can be built custom. Something like:
IF A Certain Debug Flag is ON:
- Retrieve from NSUserDefaults the Class Name of the last controller used, and redisplay it.
The problem with this is: Data State and Navigation State will not be preserved. Also, all other object state which invokes and depends on your controller will not be included. That's why I need a more universal solution.
IF A Certain Debug Flag is ON: - Retrieve from NSUserDefaults the Class Name of the last controller used, and redisplay it.
The problem with this is: Data State and Navigation State will not be preserved.
But this is exactly the problem that the built-in state saving and restoration mechanism is intended to solve, is it not?
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoringState.html
I recommend you use a User Interface target and then create an XCTestCase that works on your view controller and exercise it. Use the new record button in Xcode 7 to get you started with the test case. Familiarize yourself with some of the new queries it uses for some of the dynamic information you may be creating.
Another option would be to inject your test case's UI state into the application delegate in the setup function of an XCTestCase. Then it will need custom logic to navigate to the correct view controller. Then your test case could focus on just that ViewController once the Application delegate has navigated to it.
Of course you can use the debugger and breakpoints in the Test Case and your View Controller while UI Testing. By "scripting" this you do significantly less manual clicking on a device to test a ViewCOntroller
Also you've now got a Test! Hopefully worth something to you down the road when you change something

Custom Grid App

So I am trying to make modifications to the custom grid app that rally has already created. I found the source code at https://github.com/RallyApps/app-catalog/tree/master/src/apps/grid. However, I cannot get that code to work. I have added it to a js and then ran build (I also changed the json). However, when I then add the app to rally it doesn't give me the settings options (object, query, pagesize, etc) and just generates a table. This table generates 4 rows (the number of user stories I have), but the rows are completely blank except for gears at the beginning of each row. I was wondering if I was building this app incorrectly or if I had grabbed the wrong code. If not, is there a place where can I get the complete code or a way to modify the already existing code?
Thanks
You may add a fetch to the config as below:
config: {
defaultSettings: {
types: 'hierarchicalrequirement',
fetch: 'FormattedID,Name'
}
}
and it will display a grid.
It will not display settings dialog however. The source code in this github repo is not exactly the CustomGrid app available from the AppCatalog in the UI. It does not have the full functionality and not ready yet. I submitted a defect.

Wix Installation - Using Burn to have Managed UI & Displaying Same Progress Text as Built In dialogs

I am using Wix Burn to install per-requisites of our project, I have used ManagedBootstrapperApplicationHost to have custom UI, I have been following project available from Wix Source code to create my Managed WPF application..
Now the problem is the Progress (Message) it shows that doesn't match the progress message we have using inbuilt UI - WixStandardBootstrapperApplication.RtfLicense
Basically I am using following code from the Wix source
private void ExecuteMsiMessage(object sender, ExecuteMsiMessageEventArgs e)
{
lock (this)
{
this.Message = e.Message;
e.Result = this.root.Canceled ? Result.Cancel : Result.Ok;
}
}
How can I have the same display as the normal Progress dialog has.. Do I have to individually set Message from other methods like PlanPackage etc..
The wixstdba does not show the action data progress messages today. There was someone talking about adding the feature on the wix-devs mailing list but that has not happened yet. It's simply a matter of adding code like you have in the managed case to the wixstdba (that doesn't have it yet).
If you just want to display the name of the package being installed the way the wixstdba does it, then you'll want to handle the Engine.OnCachePackageBegin() and Engine.ExecutePackageBegin() callbacks. Those callbacks tell you when a package begins to be downloaded and then installed respectively. As part of the args to those callbacks you'll be provided the package id.
To get the friendly display name, you can read the BootstrapperApplicationData.xml that is automatically included next to your Bootstrapper Application .dll. In there are WixPackageProperties elements that provide lots of information about the packages in the bundle, including the DisplayName.
--- Sorry, the following is an answer to a question that wasn't asked. ---
The Engine.ExecuteMsiMessage() callback is called when the Windows Installer displays a message (like action data or a request to prompt the user for input). Progress is provided via a three different callbacks.
You can get the overall progress via the Engine.Progress callback. This is a very coarse grained progress that essentially moves as each package is cached and executed.
You can get the overall and individual package progress via the Engine.CacheAcquireProgress. This progress moves as each package is downloaded/copied and verified to be placed in the Package Cache.
You can get the overall and individual package progress via the Engine.ExecuteProgress callback. This progress moves as each package is installed/repaired/uninstalled.
So the Engine.Progress shows you the total overall progress and is very easy to use for a single progress bar but the progress bar will not move very smoothly. You can get a smoother overall progress by adding the Engine.CacheAcquireProgress to the Engine.ExecuteProgress. Note: that will give you a progress bar that goes to 200.
You can see how the WixBA handles all this in the src\Setup\WixBA\ProgressViewModel.cs file.

App works as desired in debug mode but crashes in Rally environment

I have created an app that creates a grid dynamically, as well as lets the user make changes to one of the grid columns via a 'numberfield' editor. Everything is working great in the debug environment but when I try to edit one of the fields in the Rally environment it crashes the app. From the looks of it, the iframe containing the app is just reloading altogether.
Now, here's the weird part that may be a clue to what's going on. The app crashes after I click elsewhere on the app (committing the change) but if I scroll the mouse wheel somewhere on the app, the spinner loses focus (no up/down arrows) and then if I click somewhere the edits are applied and the app doesn't crash. Once again in the debug mode I don't need to go through this, I can just click elsewhere and the changes are applied.
This is a known issue with 2.0p5 that will be fixed with the next release of the SDK. Basically it's using a sledgehammer to respond to the fact that something was edited and refreshing it. Since the new SDK can communicate with the message bus this is totally unnecessary...
In the meantime you should be able to patch your app by defining a global Rally.getApp function that returns your app instance to prevent the hard refresh:
//In your app definition give it an xtype:
Ext.define('My.App', {
extend: 'Rally.app.App',
//...
alias: 'widget.myapp'
//...
});
//Find the app instance by its xtype and return it
Rally.getApp = function() {
return Ext.ComponentQuery.query('myapp')[0];
};
You can then delete that code once 2.0p6 is released and you upgrade.