Question #1:
How do we make sure the built-in UI showing the next media information is never shown? (We want to display our own UI)
Question #2:
What is the best method to make the receiver play the next item when we decide to?
We are implementing our receiver on top of the CAF Receiver (V3). We are looking to implement the autoplay logic in Javascript on the receiver, not the sender.
Thanks!
Related
I'm a bit of a newbie so I apologize if this is an easy question.
I'm following this tutorial: http://www.truiton.com/2015/03/android-cardview-example/#comment-7174
It shows how to make a few CardViews in a layout with 2 TextViews in each - all programmatically.
I would like to modify it to have a Button instead of the TextViews and to have each Button make a Toast notification upon press. I am currently stuck because I have no context to make the Toast with (because I can only access the buttons in the MyRecyclerViewAdapter class). How may I solve this?
Well the fact that you have access to a button, means you have acces to a context. and to my knowledge, a onclick event on a button means that the button is still alive, and then you could assume that the context for the button is still active. The way to get the context from a view is very simple:
view.getContext();
The reason i mention the assumtion is that, relying on a view's context, could be a bad idea (for example after calling a webservice or something else, where a view could have been destroyed).
We have an SMS app for Android Wear (https://play.google.com/store/apps/details?id=com.awear.coffee)
Right now we use regular notification actions and when you select Reply it launches our activity on the watch. I want to replace the Reply action with a notification page with a custom activity that holds a few buttons and a list of strings.
I've tried two approaches.
Create a large notification page that holds the content
This doesn't work because Notification.WearableExtender.setCustomContentHeight has a hidden max value so the content gets clipped. I think it's the same height as if you use setCustomSizePreset(SIZE_LARGE). I've verified that if I use a default notification with a ton of text it can be larger than this, but if you use a custom display intent it gets clipped.
Use a fullscreen notification page and add a scrollview to it
This doesn't work because the input gets blocked somehow. Whenever you scroll the activity receives Action.DOWN, Action.MOVE, Action.CANCEL in that order, so you only get one Action.MOVE no matter how long you drag. I'm guessing this is because the OS wants to control the left/right swipes.
Any ideas on how to get around this? I've tried setting custom onTouch listeners but they still never receive all the touch events.
Any help would be appreciated. It would make our app much better if we could reduce the number of taps and swipes needed.
Jakob
if you are using bridged notification(With out having wear module) You can insert extended text content to your notification by adding one of the "big view" styles(InboxStyle,BigTextStyle) to your notification. On a handheld device, users can see the big view content by expanding the notification. On a wearable device, the big view content is visible by default.
BigTextStyle bigStyle = new NotificationCompat.BigTextStyle();
bigStyle.bigText(someBigText);
NotificationCompat.Builder notificationBuilder =
new NotificationCompat.Builder(this)
.setSmallIcon(R.drawable.ic_small)
.setContentTitle(title)
.setContentText(contentText)
.setContentIntent(viewPendingIntent)
.addAction(R.drawable.ic_map,
getString(R.string.somestring), mapPendingIntent)
.setStyle(bigStyle);
I ran into the same problems.
The limit on setCustomContentHeight is frustrating. I couldn't find a way around it.
Likewise, there doesn't seem to be a good way to circumvent the limitations imposed on tap-listeners with the fullscreen notification.
My solution was to add an Action to the first page of the notification that launches an Activity based on the GridViewPager. Once there, the limitations are gone, but it still mostly looks like a Notification. With the principal differences being, (1) you have to 'tap' the first Notification card, rather than swipe it, and (2) swiping up and down don't automatically go to the next/previous notifications.
Gwt HTML5 Canvas wrapper can responds to mouse and keyboard events, it binds to 5 - 6 types of different events, my question is, it is possible to define entirely new event system such as CanvasEvent (and related handler CanvasEventHandler extends to GwtEvent etc), bind this to canvas object and then handle all events differently using a handler interface methods will be something like onDraw(), onDrag(), onMove(), onSelect() etc.
I dont have good clarity of GWT event system but i want to know is this possible without individuality attaching separate event handlers to form a logic for handling my problem, can I access all possible event as one consolidated object and fire custom event based on conditions. What would be the best way to do it, there are threads with GWT custom events but they include senders, whereas in my case sender is already present (Canvas)
Thanks much
Certainly - remember that all of the GwtEvent objects are completely artificial and are based off of events fired from the native JavaScript. That JavaScript event object, (which comes in via onBrowserEvent) gets wrapped up as a ClickEvent or a KeyDownEvent based on the details of the original object, and then fired off via the internal HandlerManager instance. In the same way, you could listen for a MouseDownEvent, set some state, then if a MouseMoveEvent occurs, fire your own CanvasDrag event. You'd probably stop listening to those move events once a MouseUpEvent happens, then you would issue something like a CanvasDropEvent. If isntead the MouseUpEvent occurred right away with no move, you could trigger a CanvasSelectEvent (or you might have something else in mind for that select event).
Each of these new event types you declare then might contain specifics about whatever is going on. For example, while a MouseMoveEvent just has the element that the mouse is over and the x/y coords, you might be indicating what is being dragged around the page. That might be in the form of the shape that was last clicked, or even the data it represents.
Yes, the 'sender', or source, is already there, but it'll be easier to use if you expose some kind of a method to add handlers like addCanvasDragHandler, etc. This is not required - all users of your code could just use addHandler, but it does make it a little ambiguous about whether or not the widget supports the event in question. You would then call fireEvent on the canvas object to make all handlers of that event type listen.
Or, you could make a new class that contains an internal Canvas widget - possibly a Composite object or just something that implements IsWidget (Canvas has a private constructor, so you can't subclass it). This would enable you to add your own particular handlers, and keep your own HandlerManager/EventBus to track the events you are concerned with.
In my NSDocument-based application, my document's window just contains a WebView. I have defined cut: copy: paste: and delete: in my NSWindowController subclass, which is otherwise functioning nicely, but those menu items are disabled for me unless there's something texty for WebView to do.
It seems like a violation of the rules of the responder chain as I understand them; if you can't do something with it you should pass it along, but it seems the WebView wants to just disable the items for which it has defined methods and not play ball with my window controller. How do I get WebView to co-operate and yield respondership and UI validation to my controller when it doesn't have anything better to do with it?
The WebView is allowed to do what it likes with the menu items, there's no contract that states it must pass the validation responsibility up the responder chain. In fact, it's quite possible that this would break a lot of apps that implement, for example, the copy: method in their NSWindowController or NSDocument classes and are not expecting to have to deal with unhandled events from a WebView.
You'll need to subclass WebView and implement validateMenuItem:. You can then control the menu validation for the methods you're interested in and call to super for those you're not.
I notice that there are two methods by which an event handler can be hooked up to a GWT widget: addHandler and addDomHandler. The JavaDoc for addDomHandler says, "Adds a native event handler to the widget and sinks the corresponding native event. If you do not want to sink the native event, use the generic addHandler method instead."
I'd be very grateful if someone would enlighten me as to the difference between native events and logical events.
Native events are fired directly by the browser - events like clicks, mouseovers, keypresses, etc. To receive those events on a Widget, you have to specifically sink the events.
The generic events are, well, more generic. For example, I've created a SaveEvent and a DeleteEvent for my own use, that get fired when certain UI conditions are met. They are farther away from the browser and would never get fired directly by the browser. I think you should stick with the more generic events when you can. On the other hand, if you're creating a custom widget that you can't make out of other widgets - for example, if you want to build a slider that the user can click and drag - you'll need the DOM events.