Ok, so I have been struggling for a couple days with this, and I hope someone can help me.
I want Android to always run my splash screen activity, because I load a bunch of data from web services that I need throughout the rest of the app. This works fine with the flag android:clearTaskOnLaunch="true" set when you launch the app from the home screen.
Where it does not work so well is the long press of the home button and then selecting the app. In that case it starts the app in whatever random spot the user left it last. The problem is that if the app has been killed due to memory, it still shows in that recent apps list and when a user restarts the activity from the long press, all my data is gone so the app force closes.
So, my ugly workaround is to remove the app from the recently run list. I would much rather it showed up there but that it started my app the same way as if it was clicked on the home screen.
Anybody know how to do this? The ebay app pretty much does this, so I know it can be done.
-frank
Instead of reading your data in OnCreate, you could do it in OnResume. See the flow chart here:
http://developer.android.com/reference/android/app/Activity.html
as you can see, OnResume is always called whether the app is created initially, resumed from pause, or reloaded.
kaediil said:
Ok, so I have been struggling for a couple days with this, and I hope someone can help me.
I want Android to always run my splash screen activity, because I load a bunch of data from web services that I need throughout the rest of the app. This works fine with the flag android:clearTaskOnLaunch="true" set when you launch the app from the home screen.
Where it does not work so well is the long press of the home button and then selecting the app. In that case it starts the app in whatever random spot the user left it last. The problem is that if the app has been killed due to memory, it still shows in that recent apps list and when a user restarts the activity from the long press, all my data is gone so the app force closes.
So, my ugly workaround is to remove the app from the recently run list. I would much rather it showed up there but that it started my app the same way as if it was clicked on the home screen.
Anybody know how to do this? The ebay app pretty much does this, so I know it can be done.
-frank
Click to expand...
Click to collapse
In the onResume for the activity that is crashing, you could test your data to see if it's still there, if it's null you can run the code to repopulate it again.
I thought this topic might have ever been discussed before.
However, I tried to search the solution in the site but none of any i found. Prob I missed something.
I was tring to override the home button event. What I intended to do is to block the home button event(return back to the main page of default Android) and run my launcher home instead.
For example, if you wanna do the button test application on any android based device, home button needs to be handled.
Eventhough Android official website has announced that the developer is unable to override home button event, I still notice that some developers has completed this activity.
What I found so far is some developers add
<meta-data android:name="android.dock_home" android:value="true"/>
this line into their Androidmanifest and they say that's all they did for blocking the original home page.
I did the same procedure, however, it did not work well on my side.
Probably some of you have the experience on hadling this matter. Please share your experience so that I can follow up to get this issue done.
Any reply is appreciated.
Thanks in advance.
There is an app that remaps keys. perhaps you can take a look at it? You can find it on a post on the desire oxygen rom.
Xda app
You cant override the home button, but you can establish yourself as a replacement for the launcher. If you do that, the user will be prompted with a list of apps that can act as the launcher when they press home
--Please move post if not in the correct section---
As far as I can see so far there is no tool/app/hack to disable the soft keys (mainly the home button) for gaming. I imagine all recent soft key phones (HTC Desire HD, HTC EVO, HTC Thunderbolt) suffer from the problems of accidental pressing the home button and throwing you out of the game, losing all progress.
I am surprised that there is nothing I can find that solves this issue (at least not without sacrificing Sense Laucher) and I'd be willing to bet there would be more people than just me that would be willing to pay for this app or tool if it was to be developed especially with all the great games around.
I'm hoping that making this thread might encourage developers to create some tool or app here that could benefit everyone and hopefully be worth their while.
Here's all I can find so far:
When I look at the Android Developer Website I see reference to to KeyguardManager having privileges to disable the home button...
http://developer.android.com/reference/android/app/KeyguardManager.html
public boolean inKeyguardRestrictedInputMode ()
Since: API Level 1
If keyguard screen is showing or in restricted key input mode (i.e. in keyguard password emergency screen). When in such mode, certain keys, such as the Home key and the right soft keys, don't work.
Returns
* true if in keyguard restricted input mode.
See Also
* inKeyguardRestrictedKeyInputMode()
Click to expand...
Click to collapse
So far I've only come across one good post which modifies the specific application you are running (lets say a game) to act as a launcher and then disabling the home button. Here is the post...
Hi,
I found a way to tackle HOME key. For your application set the manifest as:
<action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.MONKEY"/> Now ur application is an alternate Launcher application.
Use the adb, and disable the launcher application using package manager
pm disable com.android.launcher2.
Now the Home key press will always stay in the same screen.
Click to expand...
Click to collapse
I'm not sure what the best method to approach this. I have only extremely limited knowledge of Android. Okay so if the Sense launcher couldn't be modified to disable the home button and we couldn't make another app which acts as a launcher that simply keeps the current app in focus then it might be messy but what about a tool that remakes all apps & games. What I mean is say (failing all else) a tool that batch modifies all apps you set it to modify with the above script and then sets them as acting as the launcher. The issue with this I can see is this method is that I believe it would mean you would need to resign each app or game. I believe current auto signing tools such as the one posted by Stericson only work for around 70% of market apps. You could push the other 30% of the uninstallable/unsignable apps to the system/apps folder but again I think this whole method might only create ongoing problems such as when there is a newer version of the app released then the process needs to be redone...
My guess is there is a better way. Maybe the KeyguardManager could somehow be engineered to disable the home key or the function it performs could be set to another dummy launcher that sit in the background and just to stop sofkey presses?
Okay i've only just tried this out tonight for a couple of minuted but I think it's problem solved! I've just tried out ButtonMapper as a forum memeber has suggested and what do you know, it works!! So happy!! I'm no longer thrown out of a game by touching the home button!!!
I used ButtonMapper 0.2.4 posted on the XDA forums. I couldn't select nothing for the home key so instead I selected "focus" and this seemed to do the job. Great work!! I must give a donation to the developer.
Great news! Do you have a link to ButtonMapper for those of us on XDA app?
Sent from my Nokia 3310 using XDA App
Sure thing buddy
http://forum.xda-developers.com/showthread.php?t=850464
Hi!
I've found a strange Activity behavior while programming a game for Android (currently with API level 8)
Following Situation:
The Main Activity only consinsts of one View on which the Game Thread draws all the sprites and stuff. In the manifest I checked android:multiprocess="false" and android:launchMode="singleInstance" for the Main Activity, so that Android only creates one instance of this activity, so you always come back to your left game after pressing the home button and starting the app again. This works great, but if I turn off the screen WHILE in game, and the activity is active, and turning it back on, Android creates another instance of the game (the Main Activity), so it starts over again.
So my question is, what could I do to prevent this and have the same behavior as if switched back to Home Screen before turning off the screen?
(The testing device is a HTC Desire HD with Android Revolution HD 5.1.7, if this is necessary information for helpers )
I hope someone here can help me!
I think you will have to listen for the screen off intent and handle this situation very explicitly. Maybe make the pause screen come up and then when it turns back on have your activity check for instances of itself and then deal with it.
Do you use static activities?
From something awesome
Thanks for your answer
The ScreenOff/On Intents method would be easy, but how can I recover the old Activity in the new one?
The Activity should be static, cause of the manifest properties, or not?
Another idea: In the onPause() Method queck if it was Screen off (with the corresponding intent) and 'call' the home button
Is this possible? And how could I realize this?
There is a way to use adb to send the home key press. And you can run adb on the phone with getRuntime().exec("adb keyevent xx")
Where xx is the home button constant
From something awesome
Thanks for your help!
But I made it now a much easier way...
One single 'moveTaskToBack()' in the onPause and everything works perfect!
Nice. Its always best to assume that android will do nothing to manage your app and to just do everything very explicitly
From something awesome
Hello there!
I would like to try it by myself, but unfortunately I cant. So, someone who tried the SDK, have you noticed changes in multitasking system?
Right now the only way to resume an app is using fast app switch. But I really dont like it. I rather just use the homescreen icon instead. Right now it relaunch the app.
Any changes on that? (oh please)
Thank you so much!
mikeeam said:
Hello there!
I would like to try it by myself, but unfortunately I cant. So, someone who tried the SDK, have you noticed changes in multitasking system?
Right now the only way to resume an app is using fast app switch. But I really dont like it. I rather just use the homescreen icon instead. Right now it relaunch the app.
Any changes on that? (oh please)
Thank you so much!
Click to expand...
Click to collapse
Windows Phone apps can never resume via the homescreen like iOS, due to the addition of the hardware OS back button.
To illustrate why; imagine you have an app that has start page and a settings menu. When a user goes to the settings menu, they can only go back to the start page by pressing the hardware back button (this is standard Metro design).
Now imagine a user opens the app, goes to the settings menu, then exists the app by pressing the Home button. They then do a few other tasks and then resume the app. They are now stuck in the settings menu and can't get back to the app start page; the back key will take them back to the WP8 Home screen (this is how the WP OS backstack works).
To get around this issue, Microsoft specify that starting the app from the front page always has to start a fresh instance, so the user can never get "stuck".
iOS has software back buttons on every page, so all apps can resume however you launch them. Android had the same problem with their back button (actually worse, as their backstack can be altered by the OS choosing to kill memory-intensive apps); to get around this, from ICS onwards Android apps are meant to have a software back button in the top-left, to go back within the application (hardware back key is still OS backstack).
Aphasaic2002 said:
Windows Phone apps can never resume via the homescreen like iOS, due to the addition of the hardware OS back button.
To illustrate why; imagine you have an app that has start page and a settings menu. When a user goes to the settings menu, they can only go back to the start page by pressing the hardware back button (this is standard Metro design).
Now imagine a user opens the app, goes to the settings menu, then exists the app by pressing the Home button. They then do a few other tasks and then resume the app. They are now stuck in the settings menu and can't get back to the app start page; the back key will take them back to the WP8 Home screen (this is how the WP OS backstack works).
To get around this issue, Microsoft specify that starting the app from the front page always has to start a fresh instance, so the user can never get "stuck".
iOS has software back buttons on every page, so all apps can resume however you launch them. Android had the same problem with their back button (actually worse, as their backstack can be altered by the OS choosing to kill memory-intensive apps); to get around this, from ICS onwards Android apps are meant to have a software back button in the top-left, to go back within the application (hardware back key is still OS backstack).
Click to expand...
Click to collapse
But it sucks so bad! They should review this. I hate to use the back button, and I hate to not resume the app. Using a common app, for example, WhatsApp. I was in a chat with someone. Then I hit Windows button and Im at start screen. Then I receive a message from the same person I just left the chat. What I do? I can open from the toast, can open from fast app switch (back button), or open from start screen icon.
If I open from toast, that will depend on what the app was meant to be. In WhatsApp it would take me to the chat, because of deep toast notification. But, right now, it needs to reload the whole app to open just the chat.
If I open from fast switch, it will resume the app right away. Nice. But in any other platform the message would be there waiting for you. Right now, in WP, it takes a lot to refresh the chat. You keep like 10 seconds staring at the screen waiting it. Its even faster to just reopen the whole app.
And if I open from start screen, its almost the same effect of toast, but it dont take me to the chat, but to the start screen of the app.
The point is, the fast switch is not helping that much. In fact, it would makes sense to change the fast switch to open when holding the Windows button instead of back button, and whenever an app is open, opening it from start screen icon just resume it. Actually, a lot of people doesnt even know, or even knowing, doesnt even use fast switch. Im not a common smartphone user, and even so I dont use fast switch.
For me, its the worse problem of platform. And I dont care about CE or NT if it works, but I care about it working at all. Doesnt make sense to put a whole computer in my pocket if it cant resume a single app.
i don't like the idea either to relaunch the app when you just have put it in background. then again, i also hope we will be able to close apps from the fast-appswitch-screen. and add an option to the gesture lovers out there: pinch out on homescreen to launch multitasking. or swipe from edge like w8. or anything like that. it would add to UI experience and would eliminate that 2-seconds-pause when pressing and holding down the backbutton.
Was the question not about Windows Phone 8?
Windows Phone 8 is supposed to behave differently, since true background processing is supposed to be enabled. I haven't played with the SDK yet, but I suspect that for non recompiled apps, things will behave as they do on Mango. But, I think that things changed to target WinRT and set to be able to run in the background will be able to resume right where you left off.
It wouldn't make sense for an app that is running and processing things in the background to restart when the tile is pressed.
It's been a while since I used Mango or wrote any apps for it. But, when an app is suspended, the dev has a specified amount of time to save the state.
That way when it is relaunched, the app can resume where it left off, by processing the saved state on launch. I thought with fast resume the app stayed in memory, but that was done through a registry hack and not directly made available by any carrier.
After doing some reading, the multi tasking enhancements might only add gps and voip to the currently supported background processing.
JVH3 said:
But it sucks so bad! They should review this. I hate to use the back button, and I hate to not resume the app. Using a common app, for example, WhatsApp. I was in a chat with someone. Then I hit Windows button and Im at start screen. Then I receive a message from the same person I just left the chat. What I do? I can open from the toast, can open from fast app switch (back button), or open from start screen icon.
If I open from toast, that will depend on what the app was meant to be. In WhatsApp it would take me to the chat, because of deep toast notification. But, right now, it needs to reload the whole app to open just the chat.
Click to expand...
Click to collapse
Tapping the toast to re-open the chat is the correct behavior here. I guess it's just bad coding that makes it take so long to resume; it should just be able to go straight to the conversation and skip all the "loading contacts...connecting" stuff.
JVH3 said:
Was the question not about Windows Phone 8?
Windows Phone 8 is supposed to behave differently, since true background processing is supposed to be enabled. I haven't played with the SDK yet, but I suspect that for non recompiled apps, things will behave as they do on Mango.
But, I think that things changed to target WinRT and set to be able to run in the background will be able to resume right where you left off.
Click to expand...
Click to collapse
Are you sure you're not thinking of Windows 8? For Windows Phone 8, no changes have been announced regarding multitasking or background tasks, *except* that a few select APIs (VOIP, location) will be able to run in the background, similar to iOS (not true backgrounding like Android)
Also we are talking about resuming, not background processing. In the WP8 SDK emulator, apps built into the OS don't resume; Therefore it's safe to assume 3rd party apps are not going to either.
JVH3 said:
It wouldn't make sense for an app that is running and processing things in the background to restart when the tile is pressed.
It's been a while since I used Mango or wrote any apps for it. But, when an app is suspended, the dev has a specified amount of time to save the state.
That way when it is relaunched, the app can resume where it left off, by processing the saved state on launch. I thought with fast resume the app stayed in memory, but that was done through a registry hack and not directly made available by any carrier.
Click to expand...
Click to collapse
When an app is closed the developer is meant to save the state, so that it can be reloaded if it is quick-resumed. However, once the app leaves the backstack (the 5 apps that appear in when you hold the back-button), this state is supposed to be discarded.
This is not a technical issue; it would be trivial for app developers to save the state and make their apps resume. The issue is that Microsoft's publishing guidelines (to get your app published on the WP app store) specifically says that an app launched from the home screen must launch showing it's introduction page, i.e. it can't resume. It could save some state, so a web-browser could still have all the recent tabs open, but it couldn't show the last one seen (ironically IE9 does resume it's state - guess Microsoft are allowed to break their own guidelines).
I agree it doesn't make sense to restart an app that is performing some background task; but then how to you avoid users getting stuck within a certain page, as in my example above? If WP8 includes a hardware back button, they can't change this policy.
Well, thats a shame. I hate reloading the app everytime I need it. Its so meaningless. I dont need VOIP, I dont need Skype running all the time. But I do need apps to be fast.
It really depends on how exactly the developers save their app state when the app is sent to background/tombstoned.
I, for one, use a text file to save data ( a lot of data) and proceed to loading the app as usual, and the moment the user presses a button, a pop up asks him weather he wants to restore or start anew.
I'm guessing that not every app will do this, as it is up to the developer to implement this.