Is there something like maximum activities in android app?
I would like to know because I am thinking to create sound app with ringtone feature. It will have roughly around 40 activities. But only 1 will be running constantly.
Is that too much? Should I find another way?
Explanation why I need 40 activities
I have 30 sounds and I want to set them as ringtone.
1 normal activity with buttons to play Mp and stuff, and 35 other activities, 1 for each file.
What I want is to on Long click start activity with layout and there will be more buttons
I tried with contextual menu but it doesn't look good.
You shouldn't have a problem directly due to the number of activities, but I question your design. It will likely be difficult to get right and suffer performance issues and the APK will probably be very overly large.
An alternative approach could utilize the fact that you can selectively use/show different layouts for a single activity and that a single layout can selectively show different components in the the same visible space.
You can have as many activities as you want. There is no constraint on the number. All Android activities are stored in a stack and the one at the top of the stack is the one that is visible. When memory is low, the Android OS will automatically start killing the ones that are lower down the stack and are not running any background tasks or services.
Related
Today I heard that android can only support two separate touchscreens at any time.
Is this strictly true? I haven;t been able to find a reference online.
If limited to two screens only, the project I work on gets a lot more complex as we have three screens on our product.
In my experience, while making an application, you are not restricted to create as many screens, or technically called Fragments and divide the screen into small portions. Ofcourse, the more the fragments, the greater the latency for the android system to process various interactive events that will be generated by the end user. Also, multiple ViewGroups present inside these various fragment layouts, will increase the complexity of the application, hence adding to the latency.
I have a simple app, with nothing too fancy going on (essentially just a tab pager and a recycler view). However when I start up my app from the launcher I get an all white screen for ~3 seconds before my ui shows on screen. I have not had this issue with other apps before. Now I am wondering, how can I look into why it is taking so long?
Does Android Studio have anything to help see why my app takes so long to load?
The delay seems to be worse if starting from completely dead. If the program is in recent tasks the white screen only displays for about a quarter of a second or so.
Android Studio provides a couple of tools to help you track down performances. You'll be able to find out if you allocate too many objects on the main thread, or if your XML hierarchy is too complicated etc.
I'm working on an app that doesn't support screen rotation. Do I really need to save the instance state of all my activities? How rare is it for android to kill activities? If the activity is killed and restored it will just look to the user as it did when they first came to it, which was probably quite a while ago anyway if the system has killed it. It doesn't seem like such a bad user experience to me if it is rarely going to happen. What do you think?
It is a catastrophic UX if an application loses its state just because I went to the settings to change the screen brightness. This happens frequently on 512MB RAM devices - which are still sold in large quantities. There are even devices with 256MB produced right now.
Yes, it happens a lot. It will happen to certain users much more frequent than to others. Those users will have no pardon with your app.
it really depends on the type of screens you are developing. When the activity contains a lot of data for example, it should be convenient to save the state of your activity (not all activities).
If you have several fields that the user must refill, it can be a bad experience especially if the virtual keyboard of device is not that easy (assume you are using a Galaxy mini for example)
In other words, it is a good practice but its up to you to decide if the user experience will be degraded or not
Serge
FWIW, I have written several single orientation apps for our current product and I feel that it's still important to save state. It just makes for a more usable application when everything is how you left it when you return.
In general, it's not that much work either. First, keep in mind that if you assign an ID to views in your layout's, the default Activity.onSaveInstanceState() will do most of the work. It will remember Checkbox states, EditText contents, etc. There are relatively few things you need to save. Here are some of the things I've saved with the state:
Relevant Activity parameters
ListView position information
Current Tab in TabView
Activity parameters are by far the most common.
I am developing an Android app. I have already crossed more than 20 Activities. So I am bit concerned about it. I mean if there are more Activities in an Android app, does it affect the performance of App like Speed, Memory or any other issue?
Though it is not a standard question but still I feel its something which might help others too
Yes Suraj more activities will affect performance
An activity is the equivalent of a Frame/Window in GUI toolkits. It takes up the entire drawable area of the screen (minus the status and title bars on top). Activities are meant to display the UI and get input from the user
An Activity (calling-Activity) can spawn another Activity (sub-Activity) in 2 ways:
Fire and forget – create an event (Intent) and fire it
Async callback – create an event (Intent), fire it, and wait for it’s response in a callback method (of the calling-Activity).
So the effect of activities will depend on performance of your device, its processor and memory etc.
Even if any activity will remain in stack and not finish then it affects device performance.
Even you have to take a look at security measures.
I have a requirement where in I need to have two threads of the same process rendering to screen using openGL ES.. I am newbie in android applications and havent done much application development before. I know a bit about openGL ES and I need to test some driver code urgently.
I have two Activity of GLSurfaceView. I use setcontentview and the layout xml file for defining the layout. Each activity has its layout file separately. The size of the rendered displays are small around 10% of the screen and I have made sure that the positions of the display are non-overlapping in the 2 layouts.
Initially one activity is launched which in turn launches the 2nd activity through intent mechanism in the "oncreate".
1) I tried have two activities to run at same time but i have not been successful at that. Some documentation referred that while one activity is running the other activity is possible to be in the visible state. I am not sure whether its possible to have both the activities to be visible at the same time.
2) Initially the implementation was that one activity launches the 2nd activity through intent mechanism in the "oncreate". This resulted in 2 activities running but not simultaneously. Is there a way I can have both activities running simultaneously and displaying.
3) Later for creating the second thread I used the "runnable" mechanism and created a thread and invoked the 2nd activity through the "run" of "runnable". While I could confirm that the thread was confirmed I could not see the 2nd activity running.
4) The constraint is due to the fact that I need to have separate eglCreateWindowSurface for each of the 2 rendering threads.
Are there any sample/examples where I can see how 2 activities or 2 threads are running simultaneusly while displaying to the screen?
I have gone through many tutorials and sample code and discussions to find some hint to my problem. Can someone help with some links or explanations
It is not possible in any version of OpenGL to render to the same render target with two threads. OpenGL is a state driven system so changing the state in one thread will overwrite the state in another thread. There is only a single copy of the OpenGL state as there is only one GPU to process that state.