Here's the deal: I have a heavy layout that cannot be improved any further, as it contains LinearLayouts with weights (so I cannot use RelativeLayouts).
In Activity A, I click on a list item that fires off Activity B. Activity A freezes until Activity B is fully loaded, then Activity B gets shown. So this is the complete queue of events:
Activity A: open B
Activity A: freezes
Activity B: finishes inflation/setContentView
Activity A: goes back into the application stack
Activity B: gets shown
How can I immediately show Activity B so that Activity A won't freeze?
I thought about inflating a temporary layout in B, but I need a callback method that tells me that B is fully visible and I can then replace the temporary layout with the real one.
Can anyone help me?
Thank you!
Off topic: layout inflation in Android is a real pain, it shouldn't block the whole UI, but it does. Same thing for setting list adapters.
You should do your time taking task of Activity B in thread and if you need to update the UI after your task completes then do it using handler.
You can do your time consuming loading using AsyncTask .You can use
doInBackgroundMethod to load the data
onProgressUpdate you can bind your layout to data.
If you works this way your Activity will not be frozen
Related
I have this activity, with a list of tokens/options in it. As of right now, i have a button that, using intents, opens a new activity based on the item selected (basically: a text to modify the settings and add extra info).
Now, i would like to make the first activity to show, in the below half of the screen,a preview of the new activity, but with fewer/diferent options and less information.
I know how to do that using fragments, but i don't know how to approach the creation of the new activity.
Is there a way to merge them both, to pass the first fragment to the second activity, or do i need to completely code (and thus, modify) "twice"?
Is there a better aproach that lets me do that easily?
If considered you are inflating options in recycler view in the activity, add a frame layout in the same as a container for a fragment to preview the new activity. Set the visibility to gone for the frame layout and when an option is selected set the fragment and display it. For a nice animation use android:animateLayoutChanges="true"
in the options activity xml at the root view. Hope I helped happy coding :)
I hope, I can formulate my question correctly and understandable.
When I write an Android App in Kotlin, I normally have a button to close the app and for example finish it with writing a file or something like that.
Now, sometimes I don't finish it with the button, but swipe it out. Then, the file is not wirtten..
Is there a Kotlin statement to catch the "swipe out" and perform some code? When I Inflate another view, at the end I have a dismiss-statement or dismiss.listener and can do some code.
example:
dialog.dismiss() or popupwindow.dismiss()
So question: is there a dismiss.app or something like that?
When your app's Activity is destroyed (either by the user swiping it away, or the system killing the app to free up some resources) it goes through the usual lifecycle steps, ending with onDestroy.
These steps also get pushed to any lifecycle-aware components that are observing that activity's lifecycle, including Fragments (like a DialogFragment) - so that will also get an onDestroy() call. Fragments can be destroyed at other times too, but you can look at the activity's lifecycle to see what's going on there if you need to.
But really, as a general rule you want to save data in something like onStop(), when the activity/fragment is going to stop being visible, i.e. it's going into the background. That's a good time to make sure you've saved all your important data and state, because the user may not be coming back, and you can't be sure onDestroy will be neatly called (e.g. there could be a crash, or the phone might suddenly lose power).
Don't rely on persisting data with the onSaveInstanceState() callback though - that's intended for saving UI state, and if the user backs out of the app / swipes it away, that's counted as a fresh start for the next time they load the app, so onSaveInstanceState won't be called (since the UI state isn't being saved). Use onStop instead (or onPause if you like - have a look at those links for more info on what the difference is)
When I press a button in VC++, the program starts reading data from USB which takes several minutes to be completed. During this operation I want to show the status of the progress in an edit box in the same Dialog using m_editCtrl.SetWindowTextW(output1); But during the transfer the contents of the Edit box are not changed. How can we change it?
Thanks
If the main thread is busy like in a loop, it will not update GUI. You should create a thread which does the heavy lifting and the thread, in turn, should post update messages to GUI.
Here is an example to get started and will do the job but it can be improved. In this example, the thread is calling the GUI API directly but it will be even better if you post a message to parent window using HWND and it will update itself.
My windows 10 IOT core application uses SPI to collect change notifications of
many entities. There are excellent examples for launching a timer to get SPI data, update data and binding UI elements to this data. The result is anytime SPI gets some data about a changed entity, the data that drives the UI is updated and any UI element bound to this data is updated. I can even change what subset of data is displayed on this page by using two way bindings to track the selected items on a list.
Just like the many examples, my code is structured as follows:
public async void Init_SPI()
{
....
periodicTimer = new Timer(this.TimerCallback, null, 0, 10);
} // public async void Init_SPI()
private void TimerCallback(object state)
{
/* UI updates must be invoked on the UI thread */
var task =
this.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>
{ ... update states of data that many be bound to UI element
My issue / question:
I don't see how to update data for multiple pages based on the above, since this.variable refers to the UI thread of the page that launched the timer.
It would be too inefficient to update a static class and have the multiple pages continuously poll this static data to make the UI track these large number of element.
My only thought at present is to code all the XAML pages in one page and tab between these "virtual" pages. I would rather have multiple pages to keep the functionality of these pages separated.
Any suggestions for how I could update multiple pages from data read on a SPI port would be appreciated.
Regards,
John
Sorry for a very late answer, but my solution would be to still create "real" pages -- but "relayed" the data only to the currently visible page. So whenever a page becomes visible I would have made the internals of the code piece above { ... update states of data [...] to point out that page.
This could be achieved with a simple switch statement, or by a simple interface with a HandleSpiData(TheSpiData) method -- or even a simple Action<YourSpiData>.
I have a question regarding coded ui UIMap.
Every time I record an action on the same application, coded ui generates a new object for the same window in the application.
It looks like:
UIAdminWindow
UIAdminWindow1
UIAdminWindow2
and so on...
every window class holds different buttons, even though it's the same window.
Thus it's very hard to keep code maintenance.
What i would like is that every time i perform actions and records on a window, even if not at the same time, the already generated class for this window, will be updated with the new controls.
any suggestions to why it happens?
Thanks a lot!
You can clean up your UIMaps by doing two things:
Use the UIMap Toolbox (from codeplex) to move controls within the UIMap so they are all under one control tree.
When you have duplicate UI controls, go to the properties for the action that references the duplicate control and change the UI Control property to point to the original control in the UIMap.
The duplicate trees should now be unreferenced and you can delete it from your map, keeping things clean.
And yes, it's a pain to do, but it's worth it for maintainability.
In UIMap.uitest you can change the action name and the control name for better maintenance.
For example: you can set UIAdminWindow as FirstAcessWindow or other name that will express comfortably the control or the action.
What I can guess is that there is some randomly generated content or element identification data such as class or title that may be causing it. This may be caused by different username for example. Also you can update the element from UI map element tree.