How can lazy loading be implemented in android tv or use recyclerview input leanback? the problem is this:
I get a large list of covers from the server, more than a thousand, there is not enough memory on the physical device and the application hangs. As I understand it, listRow in the ArrayObjectAdapter link in BrowseFragnent renders and stores all the elements at once.
Related
The issue occours after ca. 2 minutes passed (about 1800 times updated). TextViews simply stop to update with no reason, even if accelerometer updates are still working. Our team is working on multithreaded aplication where we have to update some UI control values on UI thread (thats problably the reason why the issue occours). We have spent amount of time trying to figure out what might be the problem and finally we have decited to report it as an issue. I have prepared some sample code based on accelerometer functionality, but in fact the same problem occours when we are trying to use other hadrware devices or sensors (e.g. bluetooth). Here is the link to the sample app repository:
https://mvvmlightbug.visualstudio.com/DefaultCollection/_git/MVVM%20Light%20bug#path=%2F&version=GBmaster&_a=contents
During debug process I've found out that Garbage Collector is somehow removing my bindings. It was because of WeakReference usage in MVVMLight for Android library. I've lust replaced all WeakReferences with object types and since then there is no more problem.
For MVVMLight creatrors: please ensure that WeakReferences are the best solution - you should rather replace them, because Android's GC is removing bindings with no reason.
I'm developing a mobile app using Flex and I have run into some problems using BlazeDS. Some users request a (relatively) pretty large amount of data from my server, which returns in about 2 seconds. The data consists of some pretty simple objects (Client, which has a name/phone/email, and a few other properties, some of which are other nested objects with more properties). The largest requests consist of no more than about 10,000 of these objects, which is only a few MB in size. The problem I am running into is that as soon as the server sends its response, the mobile screen locks up while the data is being processed. For 10,000 objects, this can take several minutes and sometimes even crash the device, and at best leave the user with a frozen screen the entire time. For the average user, it is at least 2-5 seconds of frozen screen. This is not only an issue for devices with limited capabilities. This also happens on my PC (i5 processor, 8GB RAM). From what I can tell, this downtime is taking place somewhere between when the device receives the response and when I can access the data. Setting a breakpoint on the first line of the following RemoteObject result handler has the screen lock up BEFORE it reaches the breakpoint:
protected function myResultHandler(event:ResultEvent):void
{
var result:ArrayCollection = event.result as ArrayCollection;
//Do other stuff here
}
I know very little about BlazeDS and AMF, so my only guess is that the freezing happens while the objects are being created on the device. Is there any way to speed up this process at all? Should I normally expect to see really poor performance like this? Any help would be greatly appreciated.
After a couple of hours digging around, I found the solution to my problem: On the server side, the objects I was sending had a ton of extraneous properties unrelated to the information I needed on the mobile app. In addition, there were helper methods on those classes in the form getMyHelper() which would attempt to generate a property on the Flex side. This resulted in a huge list of reference errors being thrown during the download since no properties with those names existed in the AS objects. I created stripped down 'lite' versions of the objects I needed sent across with no extra properties or methods. The massive lists now display nearly instantaneously after receiving the response from the server.
We are looking into JavaFX 2.2 as a framework for building a desktop application. But before burning many developer hours we wanted to make sure that JavaFX is fit for the job, so we made a small stress test to see if it leaks resources. The test shows and hides a Stage, containing a Label and a Button, in a never ending loop. We would expect this to continue forever without problems, but after approx 15500 iterations we get this exception
java.lang.RuntimeException: could not create platform window
at com.sun.glass.ui.Window.<init>(Window.java:180)
at com.sun.glass.ui.win.WinWindow.<init>(WinWindow.java:20)
at com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:97)
at com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:131)
at com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:82)
at com.sun.javafx.tk.quantum.QuantumToolkit.createTKStage(QuantumToolkit.java:501)
at javafx.stage.Stage.impl_visibleChanging(Stage.java:928)
at javafx.stage.Window$10.invalidated(Window.java:689)
at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:127)
at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:161)
at javafx.stage.Window.setShowing(Window.java:782)
at javafx.stage.Window.show(Window.java:797)
at javafx.stage.Stage.show(Stage.java:229)
at leaktest.FXMLController.showHideDialog(FXMLController.java:58)
Our best guess is that show()/hide() on Stage leaks some resource, and dheapmon reveals that desktop heap memory is actually leaked during the test, but we don't hit the limit (20 MB on our test machine). GDI handle and USER handle limits are not the problem either since those handles are not leaked (according to Process explorer). Any suggestions to what causes the exception?
This was a memory leak in the window disposal code of JavaFX. The leak was fixed in JavaFX 2.2.40 as part of bug fix RT-26822 Win: Stage Exception:could not create platform window.
I have a ProgressBar in MANUAL mode responding an URLLoader's progress events that seems to get drawn far less frequently than I would like. If I debug the app, I can see many events firing from the URLLoader yet it seems that the ProgressBar is being re-drawn at some random and slow rate.
Now if this was my own code (URLLoader is a black box), I would pause once in a while to let the UI update, say via loop with a timer. I presume that the URLLoader itself is blocking the main thread from processing drawing code. Adding validateNow() and invalidateDisplayList() does not seem to help much.
private function onLoadProgress(resource: TResource, evt: ProgressEvent): void
{
_progressDialog.prbCurrentItem.setProgress(evt.bytesLoaded, evt.bytesTotal);
_progressDialog.prbCurrentItem.validateNow();
_progressDialog.prbCurrentItem.invalidateDisplayList();
}
Now there are many TResources (just a class that can manage its data) being loaded in sequence, but the URLLoader is so greedy that it does not let the UI get updated more than a few times when loading & processing (parsing into XML objects) 50 or so 10KB files. So just counting which files loaded visually does not work either; I'm lucky to get 2-3 screen updates the entire time.
Loading a 700MB file looks much better, but again the progress bar updates are random and slow.
Additionally, I'd like to know if there is any way to influence or even control the rate at which ProgressEvents are fired by the URLLoader class. I have not been able to find at what rate it normally dispatches progress events either; is it at a fixed percentage per file or every x frames or milliseconds?
As these are local files, would I be better off not using the URLLoader class and instead switching to FileStream?
Environment
Flex 4.1.0.16076 SDK
Compiling to AIR app
App frameRate is 60
OS is Windows 7 x64
My bad, should have looked harder.
.-'---`-.
,' `.
| \
| \
\ _ \
,\ _ ,'-,/-)\
( * \ \,' ,' ,'-)
`._,) -',-')
\/ ''/
) / /
/ ,'-'
Provided that you have a regular connection , it is actually surprising that the loading progress of a 700MB file is not accurately represented with your Progress Bar. You also state that when debugging you can see the events being fired. This would lead me to think that the problem is on the display side. You have provided the code for the progress listener, it would be interesting to see what the code does on the view.
Displaying loading progress is quite a common task which works fine on many applications, so , although this can't be excluded , I wouldn't blame URLLoader right off the bat. Do you have any other processes going on whilst loading , any possible interferences?
I need to show an image sequence as a movie in an Adobe AIR application - i.e. treat lots of images as video frames and show the result. For now I am going to try simply loading them and displaying in a movie clip but this might be too slow. Any advanced ideas how to make it work? Images are located on a hard drive or very fast network share, so the bandwidth should be enough. There can be thousands of them, so preloading everything to memory doesn't seem feasible.
Adobe AIR is not 100% decided, I am open to other ideas how to create a cross-platform desktop application for this purpose quickly enough.
You could have an image control as your movie frame, then load up a buffer of BitmapData objects. Fill the BitmapData objects with the images as they come in, and then call the image load function to load the next image in the buffer.
private drawNextImage(bitmapData:BitmapData):void {
movieFrame.load(new Bitmap(bitmmapData));
}
In case the images aren't big but you have a lots of them it can be interesting to group sequences on single bitmaps (à la mipmap). This way you can load in say, one bitmap containing say, 50 images forming 2 seconds of video playback at 25 fps.
This is method is specially useful online as you want to limit the amount of pings and handshakes causing slowness but I reckon it can also be useful in order to optimize loading, unloading and memory access.