I want to trigger the default swipe animations on Android when a swipe gesture occurs, without changing the currently displayed Activity.
The point of this is that I want to simulate that the Activity has changed when an important event occurs in my Activity.
The questions I've seen on the Internet all relly on changing the Activity, Fragment, View ,etc.
I wonder if this is possible. Thanks in advance
This is not possible as far as I know. Google would generally be against allowing such behavior through purely their libraries as it does not follow Android ui patterns.
Related
I am writing an android app that uses Fragments and an ActionBar.
Is there a simple way to know when the entire app has finished starting up? Each fragment has it's own layout, and my startup code needs to touch them all. Is there an event I could use to accomplish this?
Thanks!!
onCreateView is called after the view is "all there", so its a good place for code that needs to run late in the game. You could set a flag here or send an event to notify other views that you're ready, but it is per fragment.
However, fragments are kind of based on the idea that they will be created as needed. In a normal app they come and go dynamically so there isnt ever a time when the "whole app is loaded". So, there isnt going to be a single place you can check for whether all fragments are ready unless you make your own. Before doing that you might want to consider other ways to accomplish the task at hand. Your design may not be a good one if you are having to fight against the underlying system.
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 feel like an idiot for having to ask this question, but I have no idea what a slider interrupt is on Android, and a search of Google and Stackoverflow turned up nothing. Amazon sent me a rejection notice for my app because all of the activities except the main one (which they call, "pop up windows") do not respond well to a slider interrupt. I have no seekbars anywhere in the app, so that isn't the "slider" that they are referring to.
Also, one of the views in question isn't a new activity at all, but a listview. It disappears on a "slider interrupt." As far as I know, I have no control over what a listview dialog does in this case. Once I figure out what a slider interrupt is, how do I tell the listview not to close when it happens? I suppose I could track whether the listview is open and recall in onResume or whatever function handles slider interrupts. But without knowing what a slider interrupt is, it makes testing difficult.
I had the same problem with Amazon. I filed a ticket and here is the response:
A slider interrupt occurs on devices with a flip-out keyboard. While the app is running the keyboard is flipped out.
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
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