I need general advice.
I'm building an app that can be started via the icon (normal way) but also with an intent triggered by a click in the notification area (the app places an icon in the notification area). The is awaken when a time event / alarm occurs.
The app has 5 to 10 views. Is it better to open a new activity for each view? How can I be sure not to have mutliple tasks open? Say if my app is Activity-A, Activity-B, Activity-C and can be started from Activity-A and Activity-B (depending on if it's opened via the icon or the notification area) ... how do I clean everything upon app close?
Or is it better to have one activity and just switch views (xml layouts)?
I'll start of with what you should watch and read. It should be clear that navigation in Android is very easy to do wrong. Google has a history of doing differently from app to app, but they are getting better. This said, if you are to do an app you should know how it is intended to work, and the best way to do that is to read the docs. As mentioned, there was an excellent talk at IO'12. There is also a very good section on the design site, and finally there is a good section in the API Guides.
To summarize: a full screen is an activity (which in turn can be constructed of fragments). The activities should in virtually all cases be structured as a tree with the root being the activity that are launched from home. For every activity you should have an "up" activity that takes you up in the hierarchy. Note that this is different from back which should take you to the last full screen state you were in. Also note that full screen means that for example tabs should not be recorded in the "back history", since they provide navigation within a screen.
When it comes to tapping a notification it should be equivalent to: pressing home, remove the task from the recents view (clearing the task), opening the task, and finally take the shortest path to get to the activity presenting the info that the notification told you about. Complicated, yes indeed... But at least there is a helper class in JB and in the support library called TaskStackBuilder.
The key to all this is a UI design that follow the Android design guidelines. Take your time to make the design for your app, and make sure to separate up (static) and back (temporal).
It might be as simple as using a different launchmode, which you can define in the manifest or I think in the inent you are using. It takes some experimenting but SingleTask or SingleInstance may be the right choices for you,
Your activity should support onNewIntent in this case, to reuse existing Activities if that is the desired effect.
In this case I better use one activity or use fragments.
Related
When I press the 'Home Button' it will put the app in background (paused, as expected), then when I open the app again it will open with the Main Screen instead of the Previous Screen.
This also affects the 'Back Button' creating a stack of multiple Main Screen.
Any ideas?
I would highly recommend reading about Tasks and Back Stack as there are many different use cases. You are most likely interested in android:launchMode here as there are four different modes that will work in your Intent.
android:launchMode documentation
There is a great demonstration on the Google play store for this:
https://play.google.com/store/apps/details?id=com.novoda.demos.activitylaunchmode&hl=en
If anything, you will want to tag the Activity with singleInstance:
Same as "singleTask", except that the system doesn't launch any other activities into the task holding the instance. The activity is always the single and only member of its task.
I read somewhere that each time you call startActivity() to transition to a new screen, you are creating a new instance of that activity. This immediately raised a red flag to me.
In search of a way to prevent this issue, I read about using FLAG_ACTIVITY_REORDER_TO_FRONT. However I'm a little alarmed that this method is not used in any of the tutorials I've seen for opening a new screen in your app. So I think I might be missing something. I mean wouldn't you always want to make sure you're not creating a duplicate Activity? isn't this kind of a big deal and shouldn't tutorials address it?
I just want to make sure that I am understanding, and dealing with, this issue correctly, and using the commonly practiced way to transition between screens.
I understand in some cases you open a screen, do something, then close it using finish() and go back. But if an app has a complex 4 level hierarchy , and the user needs to be able to jump around between the screens?
I mean wouldn't you always want to make sure you're not creating a duplicate Activity
Most of the time you probably won't want to have two instances of the same Activity but I suppose there are situations where someone might
isn't this kind of a big deal and shouldn't tutorials address it
It is definitely something that Android developers need to know about and understand how to use. I would imagine that you may not see a lot of it in tutorials because most of them teach you the basics to get you started. When a developer is new to Android, they typically have enough to learn about the framework. And they normally show you how to do a few screens (which is often all someone may need). They expect you to learn more of the details by reading through the docs and using websites such as SO
I understand in some cases you open a screen, do something, then close it using finish() and go back. But if an app has a complex 4 level hierarchy , and the user needs to be able to jump around between the screens?
Yes, a lot of times you won't be getting too deep because the deeper the easier it is to get a "lost" feeling. This is why I like using Activities with a Dialog Theme when possible. It gives the feeling that you aren't actually leaving the screen you are on. However, that doesn't really answer your question. There are many flags that can be used with Intents to keep the stack from growing. The one you mentioned works and I also use Intent.FLAG_ACTIVITY_CLEAR_Top quite often if I need to clear all Activities from the stack and get back to one single Activity. There can be so many different situations between apps, users, and developers that how you transition and work the flow or navigation just depends on what you (really, the user) needs.
It seems like you are on the right track by asking these questions. Think about what will give the user the best and most natural experience and find the right flags in the Intent Docs for your situation
I hope this cleared things up for you a little. If you don't understand something, feel free to ask
You usually want to avoid creating a duplicate activity, and IMHO, it's a bug in the Android system that the default behavior is to allow it.
(Sometimes you do want to allow it, e.g. you've written a "get filename" activity, and more than one application is likely to call it.)
You control activity creation in two places: In the manifest, and in the flags of the intent that launches it.
In the manifest, the <activity> tag has the attribute android:launchMode, which can be one of:
"standard"
Default. Can be instantiated multiple times, can belong to any task, and can appear anywhere on the stack. Normally part of the task that called startActivity() unless the FLAG_ACTIVITY_NEW_TASK was used. A new instance of the class is created to respond to each new intent.
"singleTop" Identical to standard, except that if the target task already has an instance of this activity at the top of the stack, a new activity will not be created. Instead, the existing activity will receive a call to onNewIntent().
"singleTask" There can be only one. It's the first activity of a new stack, and is thus the root of an activity stack. If there are more intents, they'll be sent to onNewIntent().
"singleInstance" Identical to singleTask, except that it's the only activity in its stack. If it tries to launch a new activity, the new activity will start a new task. Same as if FLAG_ACTIVITY_NEW_TASK was in the intent.
I personally find the history back stack in android more confusing than helpful to end users. The use of back buttons can often not do what the user expects.
There are a few options available to you if you want to use activities as the main construct.
For workflow type activities (e.g. capture forms) start the first activity with Intent.FLAG_ACTIVITY_NEW_TASK and at the end use FLAG_ACTIVITY_CLEAR_TASK
For top level activities that are often a returning point start the activity with Intent.FLAG_ACTIVITY_CLEAR_TOP. This basically checks if the activity is already somewhere in the stack and if it is pops off every activity above it in the stack and resumes the original activity.
Another possible method for the top level activities is to use one top level activity and use fragments for moving around, e.g. tab browser etc. Then just use activities for actual separate tasks.
I am trying to understand what happens when you press the back button. how does the system manipulate the back stack? From where does it get the window handle to the top window?
I have looked into the PhoneWindowManager.java, but couldn't find what I am looking for. Has anybody seen this code earlier?
What you are refering to as the "back button in the action bar" is called the "up button". The difference between the two is well explained in that article from the documentation: Navigation with Back and Up.
In short:
The Up button is used to navigate within an app based on the hierarchical relationships between screens.
The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.
Difference is well market for instance when you navigate to an app from another app. E.g.: you are accessing an application's Google Play screen from a link in your mailbox. Once in Google Play:
Up will take you to Google Play's home for applications
Back will take you back to the GMail application
Well, this will take you back, as like the back button would:
super.onBackPressed();
The documentation for onBackPressed() says that the Back button simply ends the current activity. No back stack manipulation is needed.
At a deeper level, Android does maintain a stack of activities inside of a Task, and it can determine which activity to show next when the top activity finishes. But those mechanisms live in native code and are probably beyond the scope of what you're trying to do. As far as I know, the best you can do from Java is to use RunningTaskInfo (source code here), which will expose the "base" and "top" activities in the current Task.
If you're trying to implement complex app navigation, there are a number of flags that you can use to control the way in which activities are placed on the stack.
I have seen couple of Android applications when I came across one common practice. Navigation header does not have a Back button. Since then I was quite confused so as to place the same in the Navigation header of my application.
Should back button be placed in Navigation (Header) or we should leave keys to handle it? What is the best practice we should follow?
Thanks
My personal view is that each platform has its own way of handling certain functions. An apple device will have a back button on its navigation bar because that is the place where an iphone user will look for it.
As far as Android is concerned, because we are supplied with a physical back button, we must leave it at that because that is the first place an android user will look to if he wants to go back.
Therefore since user satisfaction and ease of use is the main concern, i would not play with the back button (unless i have to).
Similar to the responses above, however for the sake of simplicity I have taken a central approach in which I actually keep a back button in the navigation header however user can still press the hard key back button and the code actually performs the same functionality.
Essentially what it does is to cover both set of users, some really new ones who do not understand Android hard-keys yet, like people used to iOS (pun intended) and the other more suave Android users.
oI believe there could not be best approach. It depends on your custom UI and how much screen estate your navigation consume. The best approach is to buil two variants ant alllow to beta-testers decide.
Allthow back button on the screen could be as much handy, so much annoying.
What the "Back" button actually does, is to close your current activity and bring the previous one to the front.
You can do the same by calling finish() in your current activity. It will remove the current activity from activity Stack and take you to the previous one.
Asaf Pinhassi
Does anyone know of a way to show another class without creating a new instance?
It seems a bit crazy from a memory management point of view that each time you want to display a different form / page you need to use StartActivity which then creates a new instances of the class instead of reusing instances previously created.
Thanks in advance
I guess from what has been said - there is no real way to do it which won't hinder the "Back" functionality of the OS?
I'm building an app which is linear except on each screen it has a home button which then makes it possible to countermand this functionality and end in a loop - is there anyway you know of to destroy all over views and reset back to the main class? (IE prevent a memory leak from becoming a problem but also not damaging OS functionality)
Consider it a "clear history" without restarting the app
Not sure if this would work for Android (coming from a MS/C# background), but conceptually one option is to iterate through open forms looking for one with a specific handle. Then, once you find it, simply call the method to show that form. This would depend on there being a Java equivalent to the Application.OpenForms property in .NET.
It seems a bit crazy from a memory management point of view that each time you want to display a different form / page you need to use StartActivity which then creates a new instances of the class instead of reusing instances previously created.
Tactically, you are welcome to add FLAG_REORDER_TO_FRONT to bring an existing activity back to the foreground, so long as you understand the ramifications from a navigation standpoint.
However, your question is rather curious. How are you accessing StackOverflow?
Clearly it's not via a Web browser. Web browsers use the exact mechanism that you feel is "crazy", rendering Web pages even if that Web page had been viewed previously. They have been doing so for over 15 years, and we've been doing OK by it.
The Android navigation model is designed to approximately mirror that of the Web:
Users click on things to move forward
Users click on a BACK button to move to the previous thing they were looking at
Users click on a HOME button when they want to switch to some other major thing to go look at
By "reusing instances previously created", you're circumventing that navigational model. For example, let's suppose your activity stack were A-B-C-D, and you call startActivity() with an Intent for B and FLAG_REORDER_TO_FRONT. Now, the activity stack is A-C-D-B. When the user presses BACK times, they no longer are on the B they were looking at originally, but are back at A. In a browser, this would be rather strange behavior.
There are other flags on Intent, or attributes on <activity> in the manifest, that offer "reusing instances previously created". However, they are not there "from a memory management point of view". They are there where the traditional Web BACK-heavy navigation pattern does not fit your needs.
Assuming you aren't screwing up anywhere, Android will destroy under-utilized activities, garbage collect that memory, and even return that memory to the OS.