I am building my first Android application that will guide the user through a series if listViews containing categories until the user reaches the final activity where a large block of text will be displayed.
My question is:
Can and should I build the listViews dynamically in one activity or should I build them all in eclipse manually?
There will be a lot of activities. I dont mind building them, i just dont want to bog down the application. From what I understand Android does a pretty good job of destroying old activities, but I am not sure the impact of having hundreds of activities would be.
Thanks in advance for your advice.
Sounds like one activity containing a ViewFlipper to hold the list(s). Presumably the list isn't the only thing you'll be wanting to display. You'll probably want to show a heading of some kind, and the user's location in the hierarchy.
What if the user hits back button? Will the app navigate to the previous activity?? Or will it be disabled?
I would suggest you make different activities since its the easiest way to do
Related
I know this question might not be one which has just one correct answer. But letting me know, that there are several solutions with good reasons for each of them, would already help a lot. So here we go:
I have designed an app which manages persons along with measurement data for each person. The data can be displayed in a chart. Generally this leads to the following tasks:
Person: Add
Person: View
Person: Edit
Person: Delete (more an option with a security dialog than a real screen)
Measurements: View (List)
Measurement: Add
Measurement: Delete (again more an option with a security dialog)
Measurements: Plot (in a large graph view)
The app will run on a phone at first. I have read that an activity is supposed to serve a very limited purpose, so the scenario would lead to one activity for each task.
However, when the app is displayed on a tablet in landscape mode, I can imagine to have three sections on the screen at once:
One section in the top right cornern managing persons
One section below that listing the values for the selected person
One larger section on the right part of the screen to plot measurements
I often read that I should avoid to create god activities. On the other hand I read that fragments is the way to go, so that each screen can easily be displayed as a subscreen on a tablet, as it is planned here.
I started off with creating the app for mobile phones, so I created one activity, which juggles all fragments (almost one for each task) in a single fragment container.
Is this the way to go, when I want to do it by the book?
I was wondering whether I should create a separate activity for each task. For the phone this makes things easier. But on a tablet I would have to control the fragments from one single activity anyway, correct? So in that case a god activity it needs to be?
You are definitely on the right track, but there are some things you may want to look into.
In my opinion Activities should only be used to host Fragments and transfer events between Fragments. Basically, the only logic that you should have in your Activity is handling the navigation. The logic stays in the Fragments (or some other layer, used by your Fragments) and it is not exposed to the Activity at all. In that way there will be no need to duplicate any logic and make some Activity a "God" Activity.
Good that you started thinking about it. You should always prevent god activity. Read about MVC, MVP & android architecture patterns which help you avoid creating a god object.
I'm trying to build an application that would run at the same time as another one, on top of it (hiding only partially the original app), that would display useful information for the user of the main app.
But it seems that 2 activities cannot run at the same time, overlap, etc...
For argument sake, lets say the app would be displaying date & time in a corner of the screen, while playing a specific game.
Anyone got any doc or sample code on how to achieve such a result ?
I'm also interested in how to know which app is currently running in order to decide in my app-on-top to be visible or invisible.
Any help appreciated :)
Thx
Looks like you are in need of Fragments: Fragments
The Android system is designed to be user friendly, and two activities at same time is not, so only one activity is on foreground at once. if you need the other to be running in background make it a Service, if you want to show some data and get back first one use a Dialog, finally if you want both you can either put them in one activity or use Fragments as #Tooroop suggsets.
Its propably too late ... but for others with the same problem:
check out how-to-draw-on-top-of-other-applications
and maybe also this if your app need to be on top on fullscreen apps
I'm planning to develop and app that presents the users with several different screens (of different information).
Was wondering what would be the best way to implement this?
Is it better to have separate XML layouts and an activity to display and allow the user to interact with each screen of data?
OR would handling all of these in the same activity be more efficient (and dynamically load / unload each layout)?
I'd say you want to go with the former, in the most cases, but obviously it all comes down to what it is that should be changing.
If you end up having two activities with layouts that only slightly differ, and you have to pass a lot of data between them, then it probably should have been one activity.
But in the most cases, where you're dealing with presenting quite separate things, I'd definitely create one activity for each presentation, so that you don't have to manually handle things like the click of the back button.
An Android Activity is a single, focused thing that the user can do.
The easier way to explain it is: An Activity is a screen in your app.
You want to have two different screens, then you should have two different Activities.
I seem to be missing something obvious here, why would I want more than one activity per application in Android? Does somebody have some solid examples?
Suppose you are creating a game. You need to have at least two activities - a welcome screen, and the actual game screen. The third activity in this example might be a settings page of the game.
Another example.
Suppose you are developing an application and you need to pop up a dialog, i.e. asking user to set username and password (Standard login screen). You might choose to create and activity and apply a dialog theme to it.
Think about it as the form of desktop application. you don't put everything on one form do you? :)
Sorantis' answer is spot on. Here are other thoughts as well:
Most Web applications, even AJAX-y ones, don't try to have everything in one single page. Some do, and those tend to be the ones that are slow as molasses to load (Evernote, I'm looking at you), have code that looks like a heaping mound of spaghetti, etc. Android is no different.
Also, state management for a super-complex Activity will be nasty, causing you problems with screen rotations and supporting being kicked out of RAM because you screw up onSaveInstanceState(). Memory management in Android assumes lots of cheap activities, not fewer massive ones. Intelligently handling the BACK button requires gobs of your own logic. If you want multiple entry points (e.g., Launcher icon and a MIME type handler and something some other app can call with startActivityForResult() and a search results handler), doing that in one activity will be a nightmare. And so on.
One very basic thing that makes having multiple activities in your program desirable is the use of the back button. I have a form in app after the user clicks search he is presented with another activity showing the results of the search. If he wants to change the search parameters he just can press back and without me doing anything particular he gets back to the search form. Doing this with one activity would be a lot of work for you.
The next thing is the memory management. Android will trigger the garbage collection automaticaly after changing activities that means my whole search form leaves the memory and doesn't take any resources away from the user.
I have developed some apps for Android, and this questions stays always:
How should I structure my UI? Should I launch activity after activity and leave the phone to make the "back" button, or should I choose more optimized, but more complex to implement, way with switching manually Views and then manually doing the "Back" button functionality?
What do you think (or know) is the better practice?
I would say that multiple Activities almost always makes more sense. I just don't think Android is designed for constantly switching its own views - you miss out on so much. You have to implement Back yourself, you don't get any inter-Activity transitions, you have to implement a lot of internal logic to resume an application in the correct state. If you don't partition your app into Activities, it makes it a lot more difficult later on to change the flow of your application. It also results in one mega-Activity that can be a lot harder to handle than a lot of smaller pieces of code.
I have trouble imagining that speed is really an issue; if it is then there's something wrong with the way you're initializing each Activity. For example, I used try to pass Serializable objects between Activities, and that proved to be incredibly slow; when I switched to a faster method of passing objects, the speed of launching Activities increased immensely.
Also, I think it's telling that the Android guidelines for Activity and Task Design don't mention switching Views at all; it's centered around an Activity-as-View design.
I'd like to point out some instances when a single activity might be better design for an Android application that has more than one full screen View:
If the application screens are tightly coupled and share a common Object that they are all operating on. In this case passing around the Object may require a Bundle and can be error prone since there will be copies of it. A good example might be a wizard. Yes you could use static's to access the common Object but static can be dangerous in Android (think configuration changes!)
If you want some really cool animations in between screens. Maybe you want a bird to take off in one screen and land in another screen. Try doing that when each screen is an activity!
On the other hand if one of your screens is designed to be shown by any number of other applications then that screen should be its own Activity.
UPDATE March 2014:
At this point the question should now include the choice of Fragments. I think that Views are probably the least likely choice of the 3: Activity, Fragment, View. If you want to implement screens that make use of the back button then it should be either Activties or Fragments because both handle the back button natively. Fragments will need to be added to the FragmentManager back stack for the back button to work. Managing fragments, dialogs and the back stack can be a bit of an annoyance though!
UPDATE Sept 2018:
Some devs at Google are recommending single activity apps using the new navigation architecture component.
Also keep in mind that implementing your app with multiple Activities will give the user a more coherent experience with the platform as a whole. Part of the experience will be shaped by using the built-in Google apps, so users will probably have an easier time using your application if it behaves similarly to the ones that are already installed on the phone.
Different from others I use a mixture of both, for example,
1. There is a main menu when the application starts
2. You click on search, takes you to search activity
3. Then there's a filter button, which just switches view and shows you filter options
4. There are two buttons at the end of the filter view, You hit "Search" or "Cancel" and you are back to the Search View again (without switching activity)
5. Now if the user hits the phone back button he's taken back to the main menu instead of the search filter options. Which I guess is the correct behavior.
Use it the way user will feel natural. And keeping everything in one activity will make it complex.
It all depends on application, what are you trying to achieve better performance, smoother UI. IMHO I prefer the second approach of controlling the Activities manually even that it is more complex as you have stated. This is a approach I have used in my android tabs project, also you might want to take a look at a class called ActivityGroup (not sure the package) it allows you to have multiple activities that you can switch between, good thing about this class is that your activities are not unloaded when you switch but a bad thing is it takes longer to load your main app.
Just my opinion.
The problem with switching views, that I stumbled upon, is also caused by garbage collector. Seems that GC is triggered when you leave activity and not the view. So, changing tabs with a fairly complex children views, for instance, will almost inevitably lead to stack overflow exception..
I've experienced so many problems with multiple activity layout that I strongly discourage it, unless there's good reason to pick it.
Disadvantage of multiple activities
Using multiple activities it is much hard to refactor code to return data from activity.
If you call a 'sub'-activity then the main activity may be killed. But you never experience that while debugging on a decent device, hence you need to handle always saving state and correctly recovering state. That is a pain. Imagine calling a method on a library (ie. another activity), and you would have to be ensure that when that method returns your app must be able to recreate its state completely with all fields on all objects in the VM (ie. activity.restoreIntance). Its insane.
Also the other way round, when you open a subactivity the VM might have been killed since the subactivity was first spawned, such as when app is minimized while subactivity is displayed.
Its so much cleaner to just have one place to store the relevant app-state, and in my case, most often if VM is killed, I want to return user to main-screen, and let them do their stuff again, because I don't spend 30-50 hours coding save/resume functionality that 0.1% of users will ever experience.
Alternative
Fragments or just manage you activity views yourself. Managing views manually, requires coding some view-switching alternative to activities/fragments with transitions if desired.
And no it does not mean one mega-activity, as suggested in the accepted answer, in any other way than its one mega-app. It just requires a bit more design of the codebase into fitting pieces, because there's slightly more work managing views, though much less work managing activity-state and other weirdness.
Possibly relevant: Reddit: It's official : Google officially recommends single activity app architecture