I have created an exercise app with text-to-speech functionality that says exercise name and sound when it's time to rest. but when I turn the screen off app keeps working making the sound and saying the exercise name. I think it has something to do with activity lifecycle, but I am a beginner in android development, so I don't quite know them.
How can I make the app stop working when the screen is off?
You have to pause your TTS manager when your activity/fragment goes to the onPause()/onStop() state and becomes not visible to the end user.
Please, read about activities/fragments lifecycle and determine which state would be the best solution for your case. You can either override these lifecycle methods directly (the easiest way) or you can use the Jetpack Lifecycle lib to create lifecycle-aware components (a cleaner approach if your TTS manager implementations exists as a separate class (and it should be so)).
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.
On calling back my first activity ,it should call onResume.It is calling the same in android version 2.2.But when I checked in for android 4.1 it is calling onCreate method that calls splashscreen and hence it looks like the app is restarting.How could I make sure that onResume is called for every version of android?
Thanks
As Henry said, you can't guarantee that onCreate won't get called again - you're not in charge of that lifecycle. If the system decides to get rid of your activity while it isn't in the foreground, then when you return to it it will be recreated. If you want to make sure that you don't show the splash screen again you will need to save state to say that it has been shown (e.g. using onSaveInstanceState). As an aside, splash screens generally aren't a great idea on android, partly for this reason. It's better to view your app as a loose collection of activities that can be entered and reentered somewhat randomly, as the android system basically does. Where you see splash screens used on android, it's common to see them slightly misbehave.
If you want to keep track of your application lifecycle, to which a splash screen might correspond, then you can subclass the Application object and put a flag there. However, android may leave your app running for weeks, so the user won't necessarily see that splash screen very often.
Keep in mind that the true purpose of a splash screen is supposed to be to show the user something nice while a long loading process is happening, and not to put your branding in their face. If you use the approach with onSaveInstanceState (and often onRetainNonConfigurationInstance too) then the cases where you show the splash screen would indeed be those where you need to redo that loading process, so that would be correct. However, it's generally better to rethink the design and bring up a minimal UI quickly, then show that some data is loading.
Finally, here's someone who goes into great depth on this subject: http://android.cyrilmottier.com/?p=632
If the system has removed your activity while it was unused, it will receive an onCreate thats normal behavior.
You could make the splash screen part of a separate activity to avoid the problem.
To keep me busy during the holidays, I decided to learn about Android Development.
So I'm following the tutorial about an Activity's lifecycle. In the linked article, it says:
During normal app use, the foreground activity is sometimes obstructed
by other visual components that cause the activity to pause. For
example, when a semi-transparent activity opens (such as one in the
style of a dialog), the previous activity pauses. As long as the
activity is still partially visible but currently not the activity in
focus, it remains paused.
However, once the activity is fully-obstructed and not visible, it
stops (which is discussed in the next lesson).
I downloaded the sample app. The sample app has 3 activities, each with buttons that launches the other activity from an Intent. When I clicked "Start B", I expected that Activity A's state should be "Stopped" since it is now fully-obstructed with Activity B's layout. However, it was set to "Paused".
The only time that Activity A's state turns to Stopped is when I click "Start C" from Activity B's layout.
Why is this happening? Is it because of some optimization that is present on newer Android versions or am I misunderstanding the article?
Here's something I learned the hard way - Google's Android docs are not exactly accurate about everything!
Sometimes, The system optimizes certain behaviors which seem to deviate from the docs. The only way to know exactly how something works is by the hard way - by digging through the source!.
If your app depends on certain system level behaviors such as stopping and pausing to work exactly in a particular sequence as advertised then you will have a hard time. This behavior is controlled by the system and offers no guarantees.
The best way I have found to deal with this is to find out the contract that Google promises the developers and stick to it. For example, In this case, the contract says that if you follow the rules, implementing the required lifecycle callbacks when they are needed, then it will work, and you do not need to know exactly under what circumstances onStop(), onSaveInstanceState(), onPause(),onDestroy() etc are called.
In other words, If you do what is needed to be done when your app is paused by implementing onPause() , Then you don't need to know exactly when your activity will be paused. The pausing/resuming is controlled by the system and is subject to change from version to version (or maybe even from manufacturer to manufacturer if they choose to customize this behavior).
Wish someone had told me this when I had started. It would have saved me a lot of time and frustration. Hope this helps.
I'm pretty much new to Android, but over the last two or three weeks I've managed to figure out most of its innards and how things work.
However, one thing is still bothering me - what's the basic difference between Activities and simple forms? Well, I know Android doesn't have such thing as a 'form', but by that I mean a fullscreen layout of elements that has an underlying class and all its functionality is executed in it, rather than in a process-wide class (Activity, to be precise).
As long as I understand, Activity is a separate process that's instantiated by OS to perform some actions that are basicly independent of the whole application. That also means that we can run only one of the application's activities, and it will still perform all of its functions without needing the whole application to be loaded. For example, if we have a movie player that can also convert movies from one codec to another, we can implement that functionality as a separate Activity so that other applications, like file managers, will also be able to convert movies between codecs using only that Activity, and not the whole application.
And that seems perfectly straightforward. The question is - why is everybody using separate Activities for functionality that cannot be separated from the application? In other words, people generally use Activities where I think simple forms within the same process would be more appropriate. For instance, I've seen people using a separate Activity for things like application settings, which obviously wouldn't be be launched outside the app itself, or editing application-specific data, which wouldn't be done outside the app as well, since the data to be edited should be selected from a list only known to the application.
Another example right from my experience - a unit converter application. It has a main menu with a GridView of units' categories, in each category there is a list of units and by clicking any unit we have a 'calculator' form for entering value that we want to convert. If I'd been doing that like everyone suggests I'd have three Activities - one for the main menu, one for the list of units and one for entering the value. But why? Why would I want to launch any of those three Activities separate from the application? If I'd want to launch main menu Activity - well, why not launch the whole application then? If I want just a list of units - again, just launch the whole application, it's not like some Facebook client is going to convert values between pressure units (since the list of units covers only one category at a time). And launching an activity for the calculator simply would not work, since it should return to the list to perform conversions and you'd have no list activity launched.
And anyway, even if I'm wrong and people use it wisely there's still an issue that Android SDK doesn't really provide any support for forms as I'm used to. Yes, there are things like ViewAnimator, ViewSwitcher etc. But all they do is switch layouts in their place, and that is hardly switching between forms as such. So the only choice to get close to that functionality at least is to use Activities. And we're back to the square one.
So to put it simply - am I missing something from the Android philosophy? Because I'm pretty sure that using a separate Activity (and a separate process as a result) for every single form in the application is an overkill. And if it really is and everybody knows that - why doesn't Android have any substantial form switching mechanism?
Thanks in advance for any clarification on this issue.
An activity isn't spawned in a separate process (unless you explicitly tell it to). Everything in your APK will be spawned in your process. Even if another application is using your Activity for whatever reason.
You can make your Activity "effectively" private to your application by not assigning any intent-filter to it in your manifest.
For the examples given, a form is equal to an activity. That isn't a universal statement as you delve deeper into Android, but for a beginner that's a decent analogy to make. Another common analogy is that Activities are more like web pages than traditional forms based UI.
I am starting to develop an application for Android and was wondering what the common application design/structure looks like.
In iOS, I would generally start with a RootController which contains a UITabBarController and fill this with 4-5 UINavigationControllers. Each UINavigationController would contain its stack with UIViewControllers.
What would a similar application look like for Android?
Start reading here. The basic building block is an Activity, you setup your UI, display data and respond to events in your Activity classes. Screen navigation is handled by starting other activities using intents.
I lay out my activities and my activity xml files. Then I code in the components that are needed in the activity classes. Then I set up preferences and my submenu etc. From there I do my support classes and glue it all together.
Egil.. The Android way is significantly different from the iOS way in that it is more like a web interface.
First: "Activities" or UIs can be killed at any time. In fact, rotating the phone can kill an activity. So that each Activity needs to be able to save its state in onSaveInstanceState and restore state in onResume. Furthermore, "shared document like data" is written in onPause() and restored in onResume(). The closest analogy in iOS is saving state on low memory warning.
Second: Activities are relatively independent of each other so that state needs to be passed between Activities (UIs) using intents or saved globally using say Application state.
It is possible to quickly move an iOS TabBar to Android using Androids Options menu, but there is no built in hierarchy of views like UINavigationController.
I have a table comparing and contrasting iOS and Android here.
Take a look at Android Design in Action, they have great video lessons on how to design Android apps!