As many other Ionic developers I'm experiencing slow state changes on Android. My problem; it takes a few hundred milliseconds before the app starts to make the transition. I'm using native transitions and crosswalk, so the when the transition is being performed it's smooth.
My best guess is that the timeline looks like this:
1) Button is pressed, activating the state change.
2) App loads the new state
3) Transition being performed to the new state
Step number 2 is what seems to take a few hundred milliseconds, and I really thought this would be solved by Ionics view caching, but it didn't seem to make any difference.
My views are mostly static, so my idea is to find a way to cache the views properly, and manually trigger when the cache should be cleared.
Do you know how this can be done? Or if you have a better idea of how this can be solved, I'd really appreciate it if you could share your advice.
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.
My initial question dealt with building a translucent view that allowed manipulation of a view below it. Bluefalcon did an excellent job answering this and helped me understand view mechanics a little better:
How can I interact with elements behind a translucent Android app?
I'm still unsure of how to manipulate an underlying view that is not part of my app. The effect I'm trying to achieve is like the Screen Filter App:
https://play.google.com/store/apps/details?id=com.haxor&hl=en
In this app, once started, it seems a "filter" view is placed on top of everything but you can still interact with whatever is running under it. The app store, email, home screen etc.
I currently have getWindow().addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE); in my app's onCreate method. This seems to get close. If I swipe on my app nothing updates, but when i back out of the app the home screen updates as if i swiped.
Any help will be greatly appreciated!
I need some advice. I’m building an app that has a sequence of 4 actions that will occur when the user presses a button. As soon as the user presses GO, that button must become un-enabled, and some visual cues in the interface must show which of the 4 actions is taking place. (Changing the visibility of ImageView, for example) The GUI must change immediately to keep in sync with sounds that are playing.
After each of the 4 actions, the GUI must change to reflect which of the actions is currently happening.
Current attempts – I can’t get the GUI to change before the first action starts (sound is playing), and at the appropriate times in between the actions. The actions are to play 4 different sounds. Currently, I’m using the MediaPlayer.
I haven’t had any luck trying to force the GUI to update when I want to. I have used AsyncTask, and tried all combinations of setEnabled(), invalidate(), forceLayout(), refreshDrawableState() to try to force things to happen in the gui when I want them to – corresponding to the 4 sounds playing in sequence.
My problem seems to be that I’m trying to do 4 things in one onClick handler. I have been really struggling with validate() calling reDraw at "sometime in the future."
I don’t know what design pattern would be best suited to providing a visual cue to the 4 things that are happening in sequence.
I’m just starting to look at Handlers. Is this the way to go? I thought it would be easy. Any advice?
If I remember correctly the onPreExecute and onPostExecute methods of the AsyncTask execute on the GUI thread. Doesn't updating the GUI from these methods work?
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