I would like users to install the widget component of my app. Currently my "mainactivity" simply pops up a textview saying that there is a widget and to see their widget list.
Unfortunately right now, this requires them to open the mainactivity at all. If they want to see the widget in their list of widgets.
I don't want to do anything annoying, but there does seems like there are a lot of hurdles to actually getting and using a widget right now.
Things I could do: setup an onboot service that checks to see if the widget is on the launcher screen. It could remind users once or twice (ever) via some kind of notification. The widget can turn off that service using its onUpdate method or other lifecycle commands. I personally hate erroneous notifications.
One thing I'd like to do is programmatically open up the widgets list. is that possible? any other best practices? Since we can't have widget only apps anymore, I'd still like the main component of my app to be a widget.
setup an onboot service that checks to see if the widget is on the launcher screen
That will require the user to launch your activity, anyway, on Android 3.1+. Your "onboot service" will not run before then.
One thing I'd like to do is programmatically open up the widgets list. is that possible?
No. After all, the user has to indicate where on the home screen the app widget goes first.
any other best practices?
An app that is purely an app widget, unless it is blindingly obvious that it is only an app widget, is going to have these sorts of issues. That is why many app widgets are simply one piece of a more substantial app, so that if the user elects not to use your app widget, or does not notice that it is there, it is not that big of a deal.
Related
I'm trying to figure out the right way to add Chromecast buttons (pause, play, etc) to an Android Notification. I've set up a custom notification that sends PendingIntents to a ChromecastService. That service is trying to interact with a class I built called ChromecastAdapter. The ChromecastAdapter implements MediaRouteAdapter and contains all the listeners and state that go along with casting. However, all this state is gone as soon as I exit the application. So, my ChromecastService doesn't end up having access to the Chromecast once my app is gone.
It seems to me that the only way to get this to work is refactor all the Chromecast state into a Service that implements MediaRouteAdapter. I really don't want to do this since I'm pretty happy with the way things are now.
Since these interactive Notifications are required by Google, I feel like there has to be a standard way of interacting with a cast from a Notification. Am I on the right track here? Do I have to place all my Chromecast interactions behind a Service?
What the behavior should be depends on the type of app and the requirements of the app. If your app is "gone" (in the sense that the Application instance is gone), then the question that you should ask yourself is whether you would want to keep a notification mechanism to stay around; there are apps that when they are killed, the receiver also gets closed and user is sent back to the home screen on the chromecast device, in which case there is no reason to keep a notification around.
On the other hand, there are apps that based on their requirements, you would want to let the cast device continue what it was doing (for example play the video) even if the mobile app is gone. In those cases, you may want to have a notification mechanism in place for "bringing up" the app. To achieve that, you need to maintain certain amount of information/state/objects in a service, enough to be able to establish a connection again and "join" the running app. In addition, your "service" needs to be aware of the status of the app on your receiver so if that app is killed (say, someone else starts casting a different app to the device), it can be notified and exit.
I know that it's not possible to place an app widget programatically on the homescreen - the user has to do it by himself. But is there a way, to let the user create an app widget without having to go to the "widgets-tab" and choosing it from the list of all available widgets?
My idea is to have a Button in my Activity, which provides some kind of shortcut to that list . This way the user still would create it by himself, but he wouldn't have to leave the app. Is there an Intent I could use in combination with startActivityForResult()?
Have a look at CommonsWare answer here:
Add widget to homescreen from Android application
You can bring the list up put you are unable to select a widget and install it for that your app must be an appWidgetHost
In Android O, its possible to pin app widget programmatically. Just watch at example here
Also check out Google official documentation
I want to make my running application's widget. I mean I want to access my application through widget on home screen. I want to dial a call, send sms to particular number which is stored in my application.
Is it possible in android? I am stuck on this if anyone has any type of idea then please suggest me..
Edit:-
I want to make widget like Power Control. In this we can operate all features of settings through widget. At the same ways I want to control my application through widget and for that I have to sync my application with widget or visa-versa. So I am not able to understand how can I do that.. Can anyone help me in this manner?
Thanks.
You can create broadcast receiver to consume all the broadcast events, and it doesn't matter if you fire broadcast events from your application of from your widget, they all will be handled at your broadcast listener.
There is no shortcut to convert an app to widget.
Sorry buddy.
You should do an additional component to your application. That component will be widget. In Eclipse you could add a new class to your package through the wizard and say that it will be a widget.
It should have simple layout - check elements you used in the view. only FrameLayout, LinearLayout, RelativeLayout, AnalogClock, Button, Chronometer, ImageButton, ImageView, ProgressBar, TextView, ViewFlipper are allowed. Using forbidden elements causes "Problem Loading Widget" message. Beware!
I think, you have already seen that page about how to place a widget in Manifest and how to make an appwidget-provider.
After installing on the device or emulator you whould install widget to the screen. Long touch will conduct you to the widget install wizard of the device/emulator. You will need to do it only once - at every debug launch you'll have the new version on the right place automatically.
Don't forget to renew all important views though - it will not be done automatically. (check what is not refreshing by itself and refresh them in code).
I think, you already know, how to call your launch Activity from the widget body. Only now it won't be launch activity already, but the activity to be first launched from the widget. The widget will be declared as launch in the Manifest.
System settings: just localize your settings-modifying logic in one class (like PowerControlHelper or something), figure out what parameters your methods will take and reuse it both in widget and in full-UI application. Not much difference there, you can access all the same android APIs from within widget logic as well as from activity logic.
Your application's own settings: it doesn't matter where you access your private data as long as it's the same application. See http://developer.android.com/guide/topics/data/data-storage.html#pref for more details on Shared Preferences.
I developed an APP + Home screen widget for Android. Now I updated the app (incremented the version code/name) but when i install, it doesn't automatically replaces the existing widget on screen. It just says "problem loading widget".
Any Idea??
Did you change the class name of the broadcast receiver implementing your widget? If so, don't do that.
There is of course the related use-case where there was a widget loaded on the home page and the user then uninstalls the application that contains the widget and widget config app. I guess this is the same as a new version which must to an uninstall/install cycle.
When that happens, all you see is the "Problem Loading Widget" in a toast-like box on the home screen. As far as I can tell, the widget gets no indicatation that the package is being uninstalled and I guess then the home screen AppWidgetManager thows up a default message.
Not well thought out behaviour on the part of the OS team. I suggest that it would be better to call the widget's onDisbled() and onDestroy() methods and to remove the widgets from the home screen before the package is removed so they can tidy up if need be and the user (non-geek phone user) gets a clean experience.
All I can find is the indication that only the user can remove a widget from the home screen, says commonsguy: Removing AppWidgets programmatically
I sure us developers can handle the odd weird toast, but for non technical "ordinary" phone users this sort of behaviour drives them back to iPhones very quickly.
This is the right behavior to me. As app is installed again, its widgets should be installed again too. If, for instance, there is a new activity to configure the widget, how do you know it as a user ?
There is, indeed, no way to guarantee that a new widget would run at all from this perspective.
I'm developing a Learning Application. In it, I have an Activity where the user can select some applications from a list of all the applications installed on his device.
Now, I'd like to launch my Activity whenever the user launches any of the selected applications from the app list. Basically I'd like to override the selected Activity by my activity. Once the user complete's some task, the user should be returned to the previously clicked Application.
How do I "Capture" this 'Launching other applications' part? BroadcastReceivers? Any example would be highly helpful. I'd be very grateful if anyone points me in the right direction with reference links.
This is very similar to a Lock Apps Application. But in a very badly twisted kind of way.
I know I have to use a background service to monitor the user activity.
You don't intercept arbitrary application launches, if that's what you're after. Doing this silently goes against the Android (or any reasonable) security model.
What you can do is offer an alternative Home screen.
However, if you just have a list view of available applications, nothing stops you from defining custom behaviours within that list activity.