How can I make an activity which comes as a splash screen before the app starts and waits for a specific time like 3 seconds in which the user have to draw the unlocking pattern to get in to the application?
If the user is unable to draw the right pattern, the application should open a simple web browser or another activity which is not the part of the application.
Also, after putting in the correct locking pattern, how can a user change the locking pattern so that he can use the new pattern next time he uses the application?
Start by designing an activity that displays the splash screen. Then extend it with simple time-out logic that opens the web browser and calls finish() (to exit the splash screen activity). Then extend the activity (or perhaps the view showing the splash image) to capture user input and compare it to a pre-defined pattern. (I suspect that this is the core of your question. You will have to override onTouchEvent; capture the coordinates of ACTION_DOWN, ACTION_MOVE, and ACTION_UP events; and compare the movement to your pre-defined pattern.) If the correct pattern is recognized, cancel the timer and start the new activity (with an Intent) and finish() the unlock activity.
To allow the user to change the locking pattern, you'll need to move the predefined pattern to the app's shared preferences or to some other modifiable location (such as data base or file). Then define an activity that prompts the user to define the pattern using whatever method you like (such as drawing the new pattern and capturing it using the same techniques as above) and which overwrites the stored pattern. Finally, rewrite your original splash screen activity to use the stored pattern instead of the predefined pattern (and, if the stored pattern isn't found, to initialize it with the predefined pattern).
Note that these two activities—unlocking the app and defining an unlock pattern—are separate from anything else in your app (except maybe a button or menu to let the user get to the pattern definition activity).
Or, you could use the Android Open Source Project's code:
http://code.google.com/p/android-lockpattern/source/browse/src/group/pals/android/lib/ui/lockpattern/widget/LockPatternUtils.java?r=7470bc287cba61198430e3d8aff32196bb5824a0
Related
I'm developing an android app that is going to be used on a information screen. This app contains 5 (weather, next run, opening hours, etc...) activities, the plan is to loop through these activities with a timeinterval. So it starts with first activity, sleeps for like 5 seconds and then jump to next activity, and when it comes to the last activity, it should start in the front again.
What is the best solution to create a navigation system like this? Have Android some special features for things like this, or is the default startActivity() the only way?
And there is a little twist with this, some of the activities needs to retrive data from external sources by HTTP. So the activities must be done with data-query before it starts the activity.
You use startActivity to swap between activities. After you are finished with an activity, remember to call finish() - otherwise there will be a lot of instances of the same activity.
But if you want something like an information screen, you could use a single activity but use Fragments. That way you simply inflate a single fragment, and keep a timer to swap between them. You can still show the same content, but there are some differences between activity and fragment in inflating and finding the views by id.
I have a multi-activity application. Say I set up a listener for some type of event in activity A, but then switch to a different activity B (within the same app) before the event has triggered the listener. What is the status of that listener? Does it always get destroyed? Or does it depend on the type of event? Or does it depend on whether the listener was set up within the main UI thread of activity A? Or some other conditions?
EDIT: The reason I ask is that I wish to interrogate the purchase states of a variety of in-app purchase items right at the start of my app's splash screen. This involves instigating some code and setting up a listener for "ok_here_is_the_answer()".. the problem is I'm worried that it may take longer to get the answer than the duration of the splash-screen activity. In that case do I have to start all over again in my application's second activity?
If your listener is created within Activity A and is tight to its context, then it would be destroyed when the activity pause i.e. go to the background.
If you want to do operation that should survive across activities, you can define it within the application context or in a dedicated service.
This might not be the answer to your question but you shouldn't use a splash activity (or even a splash) for many good reasons. I'd recommend you to use a full screen dialog instead which also would solve your problem.
But about your question it depend on what kind of listener we are talking about? Anything involving the context is over and done. Handlers, threads etc. is still running though (afaik).
My Android app comprises several activities: M (main or root), A, B, C...
Below is a possible activity navigation graph:
When my root activity M is being initialized, I cache some parameters (like screen dimensions) as static variables in special class MyUtils to use them later in other activities.
The Kaboom happens when I press Home button in activity say C and then launch a dozen applications. When I return back to my application, it appears that everything has been destroyed. C.onCreate method is being called, but cached parameters appears to be reset.
I would like to start from M, not from C after Android has devastated my application after a long pause. How can I achieve this?
I thought of something like this:
// to be put into all my activities but M:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (MyUtils.GetScreenWidth() == -1)
{
// seems like Android killed my app
finish();
return;
}
// Normal initialization.
// Use MyUtils.GetScreenWidth() to align my ui elements.
}
...but I'm not sure that it's the best way. What would you suggest?
To be honest, I would do the same or something similar to what you're doing. A possibly better idea is to have a static MyUtils.initialize() method, perhaps taking in an application context parameter, that is called at each onCreate() of each Activity that uses MyUtils.
Either that, or store the values each in a SharedPreference.
You probably don't want to do things this way unless you require the user to interact with the front-door activity (for example, to authenticate the user again).
If you do want to force them to come back in through that front door activity, you can use an Intent to launch it when you detect that you have started up in a new process with one of the other activities. You will probably want to spend some time reading through the documentation for the Intent flags to select the ones which apply for this usage.
It's not a really smart mean but you could store these information in some other place like a database or simply a file then retrieve it when needed.
Trying to understand best practice for the lifecycle of my android application, and how activities fit into it.
For example, I have a main activity, sort of the "home" of my application. But, on start-up there are several activities that I 'might' need to run, depending on several cases, one being that it is the first time the app's been run.
Is best practice to call these 'start-up'/house-keeping activities FROM my 'home' activity? Or should the application begin with a 'house-keeping' activities, do the work, then finish() and start the 'home' activity?
Thanks for advice about this,
-- J
For the best user experience (and cleaner code), you really shouldn't chain Activities.
A good best practice for the scenario you describe (needing a particular layout of options on first-launch) is to set a SharedPreference the first time that the "Home" Activity is created. In the same Activity.onCreate() call you should make a decision about what your UI will display based on that saved value (e.g., either set the appropriate View's visibility to View.GONE or choose a different layout.xml altogether).
As an added bonus: You can overload a hypothetical "has been opened" SharedPreference with the version number of the app (e.g., LastOpenedVersion) to be able to present the user with a change log the next time they open your "Home" activity after an upgrade.
I would set your LAUNCHER <intent-filter> on whatever the user will most likely want to go to from their home screen. Presumably, that would be your "home" activity.
In onCreate() of that activity, make the determination if there is some other activity that is needed (e.g., "first-run"), and call startActivity() on it. When the user presses BACK from there (or you finish() that new activity), control will return to your "home" activity.
One possibility is to start from a splash screen Activity (rather than a "home" one), which then determines what to launch next.
You should also consider if your start-up/house-keeping needs to be accomplished via an Activity. If it is not something that the user interacts with, then you can move that functionality into a Service that runs a separate thread.
I am writing a 3d live wallpaper for android using the famous GLSurfaceView wrapper (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers)
When i open the preference screen to change wallpaper settings, the settings are displayed as transparent over my wallpaper preview. This is good because it lets me preview the settings changes I make. This works great, except for one problem: The live wallpaper is paused as long as the settings are on top of it!
How can i avoid my wallpaper pausing?
I came up with a workaround which could be useful, depending on how your wallpaper functions...
In my settings activity, whenever the user makes a change (e.g. moves a slider, checks a checkbox), I broadcast an Intent with the relevant settings information.
In the live wallpaper's onCreate method, I dynamically register a BroadcastReceiver to receive these settings events. I unregister this receiver in onDestroy.
When receiving a settings broadcast, I make the wallpaper draw a single frame with the new settings. As the settings activity is transparent, this immediately gives the user an idea of what the wallpaper will look like with the chosen settings.
Similarly, using this approach, you could schedule the wallpaper to animate for a few seconds after a settings change — or whatever is appropriate for your implementation.
I found this to be kinda annoying as well. I averted the issue altogether by simply calling finish() in my settings activity whenever a change is made. This allows for an instant, full preview of the wallpaper for the user. It only takes a click to go back into the settings to make another change and it makes for a rather nice user experience.
public void onSharedPreferenceChanged(SharedPreferences sharedPreferences,
String key) {
finish();
}
I used this in my line of wallpapers. Here is an example: