When titanium android app is running smooth. I didn’t find any crash or run time error. But the problem is when I minimise it and reopen it from background after some time(1 hr or 2 hr) its going white blank. Any help to fix this?
Check the logic in your application. Are you adding and removing UI elements on the screen after the background process runs? Sounds like you are looking at a window or view with a white background. I think if you don't assign a background, it comes up black.
Often find that when this happens to me, it is some view I didn't set a height and size for. It covers over or pushes down all the other UI elements so it appears blank when is reality the other UI elements are beyond the edge of the screen.
To troubleshoot, I often give my views and windows different colors to figure out exactly what view, or window, I'm looking at. Often it isn't the one I suspected or a view that is larger than I wanted it to be.
Related
I don't know if this is the right place to ask for a solution.
I have a weird bug on Samsung S9 Android 8.0:
The area for the 3 Buttons (Menu, Home, Back) is blocked for some apps, so their UI ends on the top border of this area although I set these buttons to not fixed so that I have to swipe up to see them. One of these apps is Instagram.
Also, there is the problem that the outline of some UI is shining through the current UI of each app, no matter which app is currently running. This UI is always the same. I removed all UI elements from an app I'm working on so that I have a completely white screen. Then I made a video because on screenshots the UI fragments are not visible:
https://der-magere-student.com/public/media/WIN_20210115_02_29_04_Pro.mp4
On the bottom you can see:
In more or less black: the android menu buttons (BUT NOT THE REAL ONES, the real ones are hidden until I swipe up)
In more or less white: 4 of the five toolbar button of Instagram (home (house icon), the magnifying glass, the Plus (inside the android home button), and the heart) The fifth is not visible
On the top you can see:
The right side of the WhatsApp toolbar: From right to left. The more icon, the call icon, and the video call icon
horizontally centered with a bit offset from the top display border you maybe can see a little bar. I don't know where this comes from
There is a lot more but it's not visible on the video and also not identifiable for me. But I can see something.
Does anyone know where this bug comes from? Is it known? How to fix it?
You're looking at OLED screen burn-in. It's not a software problem; it's actually wear on the screen that happens slowly over time.
The UI you're seeing at the bottom of the screen is Android's navigation buttons, which are particularly notorious for getting burned into the screen (see, for instance, this image from this article), because they're always in about the same spot. Newer versions of Android take measures to reduce the burn-in from them, but there's only so much that it's possible to do.
Try opening something that shows a white screen with the navigation buttons hidden: you'll see the same thing.
so ive created a fragment for my app where a window pops up, and asks whether to take the picture from the camera or to get it from the gallery. Everthing, but the two buttons in the middle, are exactly 1 .png. This background png (that also includes the texts), has two transparancies. One in the white background (which is at about 25 percent) and one in the black background that takes about most of the screen. This opacity level was first set to 1%, now it is set to 0. The black basically doesnt even exist anymore. Yet it is almost fully black. You can see from the image i attach, that one is bearly able to see anything through. But why is that? Where does this heavy alpha channel come from?
Thanks!
I ran a Traceview on my Android app and the result was terrible: 2200msec. I've talked with a lot of people and have been told to go up or down the stack and find the offending code. The problem is, when I go all the way up, or all the way down the stack, there's no obvious indicator as to why (I know you're scoffing, because you're right, there is a reason, but please read-on I'm new).
If I look at Excl CPU time, BitmapFactory.nativeAssetDecode is taking a huge amount of time, well over 1400msec. Obviously this is a major part of the problem with my Activity, however, identifying where this is coming from has been a nightmare. None of my "direct" code is anywhere near (not a Child, nor Parent) this part of the stack, in fact, all my "direct" methods appear to be well-behaved, firing and finishing in mere 0-4 msec as would be expected.
One thing I've found is if I start my Traceview AFTER setContentView(), the Traceview log drops to just 90 msec. I'm honestly too new to understand this result, I know this is misleading because of course setContentView() takes time, but perhaps my layout is causing WAY too much time to be taken? Could my layout really be causing 2110 msec?
This is where I'm confused. My layout has zero overdraw and appears to be a well-formed and non-redundant XML file. My biggest layout has 41 view widgets in it, I swear I've seen many well-performing Activities with over a 100 view widgets in them. My view is designed of essentially 4 Layouts and 36 view widgets (TextViews, etc), each of these items has a Style assigned to them from the Style.xml. I hope I haven't taken things for advantage and created a monster view?
Perhaps if someone could expand on the theory to trace issues when they aren't caused by direct code you write, or the theory behind isolating the cause of the CPU time for "runaway" methods, I'd be able to better help myself (and God knows I've tried, this entire weekend in fact).
TL;DR If I start my Traceview AFTER onCreate's setContentView() it takes 2110 msec less time to load my activity than if I put it BEFORE setContentView(). My Activity's view isn't exactly complicated though, so I'm confused.
I appreciate it so much,
Ryan
One of the things that can really hurt you is to have layouts whose measuring affect each other. I would be that you are using lots of "weights" in your layout, as these are a bit time intensive to calculate.
You can analyze your slow layout using hierarchyviewer. This is in the Android tools menu in IntelliJ or in Eclipse. It only runs on test devices, or with apps that have added ViewServer (see this for instructions)
One note-- green, yellow, and red are relative to your current view Hierarchy. Here is a note from the documentation:
These indicators can be red, yellow, or green and represent how each
view renders in relation to other views in the tree. They are not a
strict representation of a bad or good view, per se.
A red dot means that this view renders the slowest, compared to all views in your hierarchy.
A yellow dot means that this view renders in the bottom 50% of all views in your hierarchy.
A green dot means that this view renders in the top 50% of all views in your hierarchy.
It really is just an indication of what you should try to fix.
Well, I found the problem and it's bitter sweet. It's sweet because it wasn't my code nor layout causing the problem, it was the admob AdView using the loadAdOnCreate="true" to create ads. It's bitter, because I now may have to switch sources of revenue if I can't remove the loading delay created by the AdView!
At the moment, I am using Euro 2012 app and it has some interesting layout parts. If you go to matches->knockout screen, you'll see 3 screens like this.
If you slide left or right, you move between them not like between one activity to another, but just like all these elements are laid on one big canvas and you slide each screen into focus. Even thou, if you slide left/right, the screen cannot be stopped in the way that half of each image is visible, so I guess it's not a big canvas. Somehow you can slide screen like one big image, and yet it always lock perfectly as if they used 3 activities for this.
How did the do this?
It's a ViewPager, available in Android support package and described in their blog.
The designing is not so much difficult, As i think to draw that boxes showing quarterfinals, semifinals.
They having layout( we can do by placing image in background also).
The major role played by FrameLayout which shows you that effect(emphasis), the flages are fetch from url as matches are decided(not essentially images only names are sufficient as flags came inside app and gets applied as updated).
After your click i think the start image gets change it's just replacing that image with new one.
As you said they are not on single canvas (but if they did customization of heir Viewpager that it's not stopping in between activities), but i think it's on single canvas.
If your taking about quickness of loading and all it's up to you as much code and processing you optimized it gives you smooth feel and fast processing.
We can appreciate the work but we can not say it's too much difficult as i think it's quit easy...
Hope this explanation helps you to understand ....
To improve the perceived startup time of my application, I am using an image as a drawable for my initial activity as described in
http://developer.android.com/resources/articles/window-bg-speed.html
and it works wonders for what it is intended to do. The application seems to be presenting its first screen within a tenth of a second, much before my onCreate is even called.
However... My application, like most applications, should display under the notification bar of the system (it is not windowFullscreen, only windowNoTitle), and the background image I specify will take the size of the full screen, its top part going under the title bar.
My application will then start and as any well-behaved application it will display content adapted to the actual size of the viewport... which means it will not match the background image.
I could possibly leave room at the top of my startup image, but even at the same screen resolution, different devices have different size notification bars, so I can't have it fit the screen smoothly that way either - not even by supplying one image for each existing screen size, because they will have different notification bar sizes.
This happens before even the first line of code of my activity is even executed - that's the whole point of putting a background image there, to give feedback to the user as early as possible, even before the activity is actually started. The only way I can see would be to somehow tell the android framework to fit my window to the region under the bar and not the whole screen, but I couldn't find how to do that. Does anyone have an idea how to make my image closely fit the interface that will then be presented by my activity ?