On a wearable my app displays a rest timer as shown in the picture. It simply counts down and is updated each second.
My problem is that since it is updated each second, it creates a flickering effect.
The icon is hidden for just long enough for you to be able to notice it.
The actions related to the card (accessible through swiping) also flicker similarly, and at times display the totally wrong information such as another items icon and text. The actions are same for the whole duration of the rest timer.
Ive tried updating it each 5 seconds or so but it unfortunately ruins the whole thing and makes it very unintuitive. Its my best option at the moment though.
Is it possible to update the notification each second without causing the flicker?
If you want to show a notification with a timer, either counting up or down, that's a built-in feature for that. Here's some code I wrote that puts it all together for Android Wear:
https://github.com/danwallach/XStopwatch/blob/master/wear/src/main/java/org/dwallach/xstopwatch/NotificationHelper.java
Notably, you'll want your notification builder to do something like this:
builder.addAction(android.R.drawable.ic_media_pause, "", clickPendingIntent)
.setWhen(eventTime)
.setUsesChronometer(true)
.setShowWhen(true);
Related
So im making a android app in Unity an im trying to make a specific timer so the timer starts as soon as you go the the scene and also I want the numbers to scroll down then stop for a second then scroll again it would look something like this
5
6
00:14:57
8
9
and it would scroll down to the next number ten stop then the next number then stop
how to make a timer in unity with this behavior and look ?
There are plenity of ways to make a timer, I'm going to assume that that's not the trouble, what you are asking for is an animation that looks nice and works with the data of your timer.
You can have a FSM in the animator to make an animation between three text components so each second them will scroll up, once the upper text is outside the view, ui mask, you put them at the end and then change his text value to the next second and so on in a loop.
Another way to do this is the same I just wrote but using scripting and coroutines instead of the animator, I prefer this approaching since I have full control of what are appearing to the user and what are occurring behind in the code.
Background
There are some nice apps out there that show some layout on top , while the user is making a call or answering one (like "current caller id").
I need to create an app with the ability to show something on top , during a call, and allow it to be interactive.
The problem
Using broadcastReceiver ,foreground service and SYSTEM_ALERT permission, I've succeeded showing something on the screen during calls.
As long as the content being shown is static, I have no problems.
However, I've noticed that when I try to make the content being shown to be interactive , I face some problems:
Everything is jumpy and this includes not only animations, but also setting visibility to visible/gone. I hate to think how it would work like when I need to make things draggable.
Not sure if this is the reason, but using the SlidingDrawer make the entire width belong to the SlidingDrawer and you cannot click through it. This means that if its location is at the bottom, you can't touch the "answer" button when someone calls you.
The question
What is the reason for those problems?
How can I fix them and be able to show things right?
How do other apps handle it right ?
EDIT: about the SlidingDrawer , it seems that it has terrible bugs about its location and size, and the content area, even when it's not shown to the user and the user can see through, it cannot be touched through. Still, I don't know why, and how to fix it, and I also don't know why things are so jumpy compared to normal apps (probably because of over-drawing, but it's really really slow).
Maybe this question should be more general: how to make a floating window like on AirCalc, that can be moved easily yet still be quite fast.
For the dragging functionality, I've tried to get the layoutParams of the root view (which is of type WindowManager.LayoutParams ) that I show, update it and set it again, but for some reason it didn't do anything. Wonder what I'm doing wrong.
EDIT: it seems that i should be using windowManager.updateViewLayout for updating the layoutParams. Using this post , I've made it perfectly draggable.
Ok, I've come up to some conclusions about this, first to answer my original questions:
it's probably because of overdraw and the views i've used. I wanted to try out libraries that could replace the slidingDrawer , but each had a different problem. using simple views proved that the idea in general works.
in the case of visibility changes, it was jumpy because the size of the view wasn't able to fit using the current WindowManager.LayoutParams size.
slidingDrawaer does have issues since it uses the whole size it get when closed or opened.
now to the rest of the issues :
unable to drag ? instead of the regular setLayoutParams , use windowManager.updateViewLayout .
unable to touch outside of the view ? set its minimal size according to your needs. you can also set the window flags so that touch event would go through .
want to listen to calls events ? you can use the broadcastReceiver for triggering the showing of the app, but I suspect that hanging the call might cause the intent be received later sometimes. I think you can use telephonyManager and listen to events there, using the service you run in the foreground (that i've created just to make sure the app won't close in the middle).
if anyone else has questions, i can help.
I have done live user testing for a list in my app, and have come to an interesting puzzle.
A list, specifically a single-column table in iOS, may often have a swipe right gesture for more actions, like the twitter app and mail app, and a million other apps. But when important functionality is embedded in the UI beyond that action, and a user cannot figure it out, the only thing that comes to mind to alleviate that is something like the accessory button, ie. a right-pointing triangle or chevron button.
There is probably another way but it's not coming to me. Maybe making the rows taller than normal?
This was meant as a comment but was rejected as too-long.
So after thinking more about this, the ideal solution is a visual clue, rather than painfully obvious text saying "swipe a row for more options". Perhaps when a list (UITableView, etc) is shown and rows (UITableViewCell, etc) are created and added, then as they appear an animation begins of the main visible content sliding into place in the OPPOSITE direction of the desired swipe animation, with a minimal visual indicator afterward, reminding the user that the content is moveable!
Sound good? Optionally, immediately before the animation begins, any underlying content may be shown for a split second (if its supposed to appear underneath). Sweet!
The main activity of my app is defined in the Android manifest file with the following attribute:
android:theme="#style/Theme.Translucent.NoTitleBar"
This makes the activity transparent, which in turn makes it possible to control the transparency of my app in code by manipulating the main View object (e.g., by invoking setVisibility(View.INVISIBLE) on the main view). This works fine.
However, one undesirable consequence of this approach is that when the app is launched there is no visible response until my main View is displayed. Normally, the default black background of an app's main activity is immediately visible when an app is launched, which provides immediate confirmation that the app is starting to run in response to the user tapping its icon in the launcher. But with a transparent background, the user continues to look through the background at the display from which the app is being launched until the main view is displayed, and so it appears (during that interval) as if nothing has occurred.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds. While this is not a disaster, I'd prefer an immediate response so that the user is not left wondering whether the app was in fact triggered.
I have tried removing the transparent theme, which results in immediate confirmation via a black background, as usual. However, I've been unable to set the activity background to transparent in code once the app has been initialized.
I've invoked setTheme() on the activity just prior to calling setContentView() for the first time, passing it a transparent theme, but this does not make the activity transparent.
I've also tried this in onCreate() (again, just prior to calling setContentView()):
ColorDrawable transparentDrawable = new ColorDrawable(Color.TRANSPARENT);
getWindow().setBackgroundDrawable(transparentDrawable);
This also appears to have no effect.
I've also tried using a theme in my manifest that has android:windowBackground set to a drawable that is a mostly transparent PNG, but with some text (e.g., the app's name) superimposed on the transparent background that would provide a cue to the user that the app was loading. Unfortunately, the moment I use a drawable as part of the theme, the background fails to display at all until after the main view is initialized.
All time-consuming initializations are already being done in a worker thread, so I'm not looking for advice on how to accomplish that. The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds.
It should come up in milliseconds. Make sure you are not doing excessive work on the main application thread.
The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Then initially display something else that is cheaper to bring up (e.g., ProgressBar), replacing it with your regular UI when it is ready.
I've upvoted CommonsWare's answer, because he pointed me in the right direction, which is away from trying to change the transparency of the main activity after it is launched (something I'm beginning to suspect cannot be easily done).
However, that advice cannot itself be the accepted answer, given that it is only a pointer in the right direction.
The answer I decided upon, given this guidance, was to create a splash display. However, I could not find a truly good android splash example anywhere. So, I devised one, and it is working very well for me, and completely solves my problem.
Because creating a splash display is a more general question than the one I started out with, I have placed my detailed description of how that can be done as an answer to a question about how to implement a splash screen, and have linked to that answer below:
Create a true splash screen
sorry for the confusing title. I will try to explain my problem.
My app displays some content day-wise in a ListView. The user is able to switch days back and forth (e.g. by swiping his finger to the left/right). Now I want to implement some nice transition effect (like the new Android market has).
The problem is, that the content is generated dynamically and it can take a while to load. Also you can move (theoretically) infinite days to to past or to the future.
How can I implement a nice looking transition that is responsive and also tells the user, that some work is done in the background.
Just to clarify, I'm not asking how a ListView or an AsyncTask works, but rather for design concepts for my idea.
Thanks in advance.
If I understand correctly what you mean, I think you should try and preload in background the previous and following page, and keep them in memory ready to come in with the swipe.
Every time you change day you would recycle one page of data to load a new one (in one direction or another).
Obviously the user can still swipe too fast and you won't have time to preload things, but in that case I don't think you can do anything better than transitioning in the page with a nice spinner in it (not a blocking dialog).