Database Users

tip: how to vibrate

Code:
#include <windows.h>
#include <nled.h>
// from the platform builder <Pwinuser.h>
extern "C" {
BOOL WINAPI NLedGetDeviceInfo( UINT nInfoId, void *pOutput );
BOOL WINAPI NLedSetDevice( UINT nDeviceId, void *pInput );
};
void LedOn(int id)
{
NLED_SETTINGS_INFO settings;
settings.LedNum= id;
settings.OffOnBlink= 1;
NLedSetDevice(NLED_SETTINGS_INFO_ID, &settings);
}
void LedOff(int id)
{
NLED_SETTINGS_INFO settings;
settings.LedNum= id;
settings.OffOnBlink= 0;
NLedSetDevice(NLED_SETTINGS_INFO_ID, &settings);
}
int WINAPI WinMain( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
for (int i=0 ; i<10 ; i++)
{
LedOn(1);
Sleep(400);
LedOff(1);
Sleep(200);
}
return 0;
}
led '0' is the radio led
led '1' is the vibrator

Thanks for this tip!
I was just looking for a way to make the phone vibrate. We're doing applications for the deaf community so vibration is absolutely necessary!
/Christer

With settings.LedNum=0 i can do the things with the Radio LED.
But my MDA 2 has a third LED for Bluetooth. And when i query Device Info i get a count of two(starting at 0). But i can´t do something with the 3rd LED. Somebody knows why?
I also would like to know hot the let the first LED flash green and not Red?

Ok this thread is ancient, but I am resurrecting it to ask a relevant question. This is the method that I am currently using to vibrate. The problem is that when the cpu is being used for other tasks, this will tend to make it vibrate longer than expected. For instance if I switch screen orientation and they try this the vibration will be longer because other threads are doing some processing. The following:
LedOn(1);
Sleep(400);
LedOff(1);
is not a reliable method because if the CPU is busy more than 400ms may elapse between the two calls. Sometimes a lot more. Is it possible to use the blink mode for the vibrator, as in using 2 for the OffOnBlink value as in this msdn article?
http://msdn.microsoft.com/en-us/library/ms905326.aspx
So far all I can get it to do is vibrating without stopping. Any help would be appreciated. Thanks.

JKingDev said:
Ok this thread is ancient, but I am resurrecting it to ask a relevant question. This is the method that I am currently using to vibrate. The problem is that when the cpu is being used for other tasks, this will tend to make it vibrate longer than expected. For instance if I switch screen orientation and they try this the vibration will be longer because other threads are doing some processing. The following:
LedOn(1);
Sleep(400);
LedOff(1);
is not a reliable method because if the CPU is busy more than 400ms may elapse between the two calls. Sometimes a lot more. Is it possible to use the blink mode for the vibrator, as in using 2 for the OffOnBlink value as in this msdn article?
http://msdn.microsoft.com/en-us/library/ms905326.aspx
So far all I can get it to do is vibrating without stopping. Any help would be appreciated. Thanks.
Click to expand...
Click to collapse
actually putting the thread to sleep is kinda not recommended, i usually create another thread to vibrate and set it to sleep then stop the vibration and exit the thread.
maybe i can create a class for that, but it will be a C# class, not C++

anaadoul said:
actually putting the thread to sleep is kinda not recommended, i usually create another thread to vibrate and set it to sleep then stop the vibration and exit the thread.
maybe i can create a class for that, but it will be a C# class, not C++
Click to expand...
Click to collapse
I am not exactly sure what you mean by this. Do you do the exact same thing but all in another thread? Or do you start the vibration, create a new thread that just sleeps then stop the vibration when the thread returns? I got even worse results when trying it all in another thread.
Is there no other way to do this than start vibration then stop it after sleeping? There is no way to give it the duration you want?

make the phone go to sleep?

how can I get the phone go to sleep directly?
I have tried with this but it doesnt go to sleep instant:
Code:
if(wl == null){
pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
wl = pm.newWakeLock(PowerManager.ACQUIRE_CAUSES_WAKEUP | PowerManager.SCREEN_DIM_WAKE_LOCK, "alert");
wl.acquire();
myKL.disableKeyguard();
//...DO WORK...
wl.release();
myKL.reenableKeyguard();
The lockscreens opens again if I had it before but the screen doesnt sleep...

Wakelock problem?

hello
I'm the developer of myClock and now I have been hearing about that not every phone wakes the phone up when it needs when they have pressed snooze and the snooze should go of... mostly the bug have been on desire roms...
I use this code:
Code:
KeyguardManager myKM = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
myKL = myKM.newKeyguardLock("AlarmAlert");
pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
wl = pm.newWakeLock(PowerManager.ACQUIRE_CAUSES_WAKEUP | PowerManager.SCREEN_DIM_WAKE_LOCK, "AlarmAlert");
wl.acquire();
myKL.disableKeyguard();
//
//do work and then the user presses snooze
//
if(wl.isHeld())
wl.release();
myKL.reenableKeyguard();
//
//after a the snooze time I try to wake the phone up and then remove the lockscreen
//
wl.acquire();
myKL.disableKeyguard();
//
//do work and then the user presses snooze
//
so why is the phone not waking up on some phones but it do on others? its really wierd....
some that knows how I fix this?

Display update regularity weirdness @ 1Hz w/video example (code, not NoRefresh issue)

At it's core... a simple clock app. I'm firing off updates scheduled on each second. On each second, I read the time, then display the time. This is not complicated. And it works, just fine, on my phone. Tick, tick, tick and it looks like a clock. Why wouldn't it, right?
Ok, so the same code on the nook doesn't update regularly. Here's an early video:
http://www.youtube.com/watch?v=URRrYhumt1Y
You can see there's a "double beat". It's like every other update gets displayed for maybe 1.5 seconds. So the overall rate doesn't change, it's still two updates in two seconds, and no updates are missed.
These are being done with a regular myView.setText(), no fancy graphics or anything.
Now, here's more interesting data. If I run the updates twice as often, or five times as often, it changes nothing. I assume the screen/OS is internally detecting no pixels have changed, and so it does nothing. However, if I add, to a totally different view on the screen, an area where I'm toggling from some text to no text (from " " to "+", in actuality, so, a blinking plus sign) AND I run everything at five times a second then the seconds area updates with a steady one hertz beat, just like you would expect from a clock.
Additionally, if I run the code so it only updates every other second, it will click along very predictably at every other second. So it's not a "some code problem with every other update".
I wonder if there's some internal timer in the OS watching for screen updates, and managing them? Perhaps "pushing" the display with a toggling update every 200ms keeps it active and within some timeout limit?
Or are there some nook-specific calls on this?
Cheers,
Anders

I believe that some of the super-duper fast-mode or-whatever-you-call-it throws away some screen updates.
Are you using such a thing or a kernel with such a thing?

No, I'm not attempting any speedy-screen stuff in this code. In the video you can see the grey in the bar, so I'm not in any kind of a 1-bit mode. Because really, one update a second should be no problem.
But if it was throwing away an update... why would the update show up half a second later? I would expect it to skip displaying that second entirely, and so jump to the next.
NoRefresh is installed on this device, but not set to start at boot (and honestly, I don't think I've actually gotten NoRefresh working yet, busy with other things). But I'll uninstall it to be sure and retest.
Is it possible some kind of low-power mode / sleep mode is kicking in? It wakes up half a second later, realizes it has an update, stays away for the next half second, makes the NEXT update (on time) then goes back to sleep after a 0.9ish seconds?
Anders

Yep, even after uninstalling NoRefresh, and rebooting, the behavior is the same. So that's definitely not related.
And running the normal updates to the screen at both 2Hz and 5Hz have the same result, so it's not related to the number of times the updates are called.
Anders

Here's an interesting video... watching the ADB output click along at a clean 1Hz, and the screen updates clearly not synced with the actual writes to the screen.
http://www.youtube.com/watch?v=sL299EUH3T0
Again, all on "stock" system, no special video modes / refresh / magic enabled.
Anders

Actually, I have run into this.
There's no documentation on modes or theory of operating a frame buffer for eInk.
I ran into this on the time display on my audio recorder app.
I ended up using a DL region in my app.
I'll have to look closer into how bad it looks without that.
Are those numbers a TextView or an ImageView?
If it isn't a TextView try one to see if it works better.
There may be slowness in caching/using images.

More questions:
Are you using Timer & TimerTask?
Are you using runOnUiThread?
I wrote a demo app that counts.
It works fine by itself on stock 1.2.1

Renate NST said:
Actually, I have run into this.
There's no documentation on modes or theory of operating a frame buffer for eInk.
I ran into this on the time display on my audio recorder app.
I ended up using a DL region in my app.
I'll have to look closer into how bad it looks without that.
Click to expand...
Click to collapse
DL region? Not familiar with the acronym.
Are those numbers a TextView or an ImageView?
Click to expand...
Click to collapse
It's a text view. Just a big blocky TTF font. (Although the same issue is present using stock fonts).
Are you using Timer & TimerTask?
Are you using runOnUiThread?
Click to expand...
Click to collapse
Using scheduled handlers. They are triggering normally, since A] the ADB output is firing at nice one second intervals, and B] the SystemClock.uptimeMillis shows a 1000 count between each wake up. It's off by one or two millis which is understandable given that it's not a hard-realtime system.
But I'm not familiar with Timer and runOnUiThread, so I'll google those and do some reading.
(In the below code, the "nookPing" area is a tiny spot where I just toggle some pixels. If I do this and run the whole thing at faster than 1Hz, the seconds digit updates on schedule. Turn off this toggling, (which is in a totally unrelated textarea) and back to wonky updates, even at the same update rate. )
Code:
// //////////////////////////////////////////////////////////////////////////////////////////////////
// The Tick task itself /////////////////////////////////////////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////////////////////////
private Handler mHandler = new Handler();
private Runnable mUpdateTimeTask = new Runnable() {
public void run() {
Log.d(TAG, "---------------------Tick Called: " +String.valueOf(SystemClock.uptimeMillis()) );
Log.d(TAG, "---------------------");
updateTimeOnScreen();
scheduleNextScreenUpdate();
}
};
// //////////////////////////////////////////////////////////////////////////////////////////////////
// Schedule next update /////////////////////////////////////////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////////////////////////
private void scheduleNextScreenUpdate()
{
mHandler.removeCallbacks(mUpdateTimeTask);
mHandler.postAtTime(mUpdateTimeTask,UtilitiesTime.calculateNextScreenUpdateTime());
}
// //////////////////////////////////////////////////////////////////////////////////////////////////
// Show the time ////////////////////////////////////////////////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////////////////////////
static int nookPing=0;
private void updateTimeOnScreen() {
String hhmm;
int militaryhours,hour;
int minutes;
int seconds;
int tenths;
int milliseconds;
Calendar rightNow = Calendar.getInstance();
militaryhours=rightNow.get(Calendar.HOUR_OF_DAY);
hour=rightNow.get(Calendar.HOUR);
minutes=rightNow.get(Calendar.MINUTE);
seconds=rightNow.get(Calendar.SECOND);
milliseconds=rightNow.get(Calendar.MILLISECOND);
tenths=milliseconds/100;
SharedPreferences settings = PreferenceManager.getDefaultSharedPreferences(getBaseContext());
if(true==settings.getBoolean("appSettingNookPingActive", false))
{
if(0==nookPing)
{
nookPing=1;
nookPingView.setText(".");
//nookPingView.setText(" ");
}
else{
nookPing=0;
nookPingView.setText(" ");
}
}
else{
nookPingView.setText(" ");
}
if(Configuration.ORIENTATION_PORTRAIT==getScreenOrientation())
{
if(1==MainActivity.appSettingMilitaryTimeFlag)
{
hhmm=String.format(Locale.US,"%02d:%02d",militaryhours, minutes);
}
else{
if(0==hour)
hour=12;
hhmm=String.format("%2d:%02d",hour, minutes);
}
}
else
{
if(1==MainActivity.appSettingMilitaryTimeFlag)
{
hhmm=String.format("%02d\n--\n%02d",militaryhours, minutes);
}
else{
if(0==hour)
hour=12;
hhmm=String.format("%2d\n--\n%02d",hour, minutes);
}
}
int secondsTens=seconds/10;
int secondsOnes=seconds%10;
secondsLeftView.setText(String.format("%d",secondsTens));
secondsRightView.setText(String.format("%d",secondsOnes));
hhmmView.setText(hhmm);
}

MotionEvent.ACTION_CANCEL is blocking subsequent ACTION_UP on my button

Hey guys,
I am not getting any response on Stack Overflow so I thought I would try here.
At this point I am suspicious that it is a Samsung device specific problem. A very basic app with just a single button produces the same issue on my S4 development device.
Here is me SO question:
I have a button on one of my fragments, that sits inside a relative layout.
It's a rather large button, and when I fat finger it I get a ACTION_CANCEL motion event rather than ACTION_DOWN (it works perfectly fine with finger tips). This prevents it from registering the subsequent ACTION_UP (I assume the view's parent is taking over). I tried using the requestDisallowInterceptTouchEvent() method on the parent, to no avail.
Here is my onTouch implementation:
Code:
@Override
public boolean onTouch(View view, MotionEvent event) {
//debugging
Log.v("TOUCH EVENT", event.toString());
int action = event.getAction();
if (action == MotionEvent.ACTION_DOWN) {
mButton.getParent().requestDisallowInterceptTouchEvent(true);
//Do stuff...
return true;
} else if (action == MotionEvent.ACTION_UP) {
//Do other stuff...
return true;
} else if (action == MotionEvent.ACTION_CANCEL){
return false;
//Toast.makeText(context, "Your thumb is too fat.", Toast.LENGTH_SHORT).show();
}
return false;
}
Note that the button also uses custom background resources. I start an AsyncTask when the button is pressed and the background changes based on the progress of that task. I'm not sure if that has anything to do with the problem or not.
EDIT: I walked all the way up the View hierarchy to ViewRootImpl, and still no luck in calling requestDisallowInterceptTouchEvent() on it. Weird thing is this shows in the log when my button sticks:
Code:
08-26 11:06:15.287: D/ViewRootImpl(5428): [ViewRootImpl] action cancel - 1, s:31 s(atmel):-1.0 eccen:1.3333334
So obviously it seems that the action is either being cancelled before it even gets inside the ViewRootImpl or right after. How is this even possible?
Update: Still no progress on this... anyone?

masterjeff said:
Hey guys,
I am not getting any response on Stack Overflow so I thought I would try here.
At this point I am suspicious that it is a Samsung device specific problem. A very basic app with just a single button produces the same issue on my S4 development device.
Here is me SO question:
I have a button on one of my fragments, that sits inside a relative layout.
It's a rather large button, and when I fat finger it I get a ACTION_CANCEL motion event rather than ACTION_DOWN (it works perfectly fine with finger tips). This prevents it from registering the subsequent ACTION_UP (I assume the view's parent is taking over). I tried using the requestDisallowInterceptTouchEvent() method on the parent, to no avail.
Here is my onTouch implementation:
Code:
@Override
public boolean onTouch(View view, MotionEvent event) {
//debugging
Log.v("TOUCH EVENT", event.toString());
int action = event.getAction();
if (action == MotionEvent.ACTION_DOWN) {
mButton.getParent().requestDisallowInterceptTouchEvent(true);
//Do stuff...
return true;
} else if (action == MotionEvent.ACTION_UP) {
//Do other stuff...
return true;
} else if (action == MotionEvent.ACTION_CANCEL){
return false;
//Toast.makeText(context, "Your thumb is too fat.", Toast.LENGTH_SHORT).show();
}
return false;
}
Note that the button also uses custom background resources. I start an AsyncTask when the button is pressed and the background changes based on the progress of that task. I'm not sure if that has anything to do with the problem or not.
EDIT: I walked all the way up the View hierarchy to ViewRootImpl, and still no luck in calling requestDisallowInterceptTouchEvent() on it. Weird thing is this shows in the log when my button sticks:
Code:
08-26 11:06:15.287: D/ViewRootImpl(5428): [ViewRootImpl] action cancel - 1, s:31 s(atmel):-1.0 eccen:1.3333334
So obviously it seems that the action is either being cancelled before it even gets inside the ViewRootImpl or right after. How is this even possible?
Update: Still no progress on this... anyone?
Click to expand...
Click to collapse
Mmmh strange problem you've got there... Just an idea, maybe try to always return true in your onTouchEvent() method since you may be losing the event when an ACTION_MOVE event comes up and you return false. Other than that, could you show us your layout file? I doubt the change in background color has any effect on this, but it could be that some part of your layout is causing this.

SimplicityApks said:
Mmmh strange problem you've got there... Just an idea, maybe try to always return true in your onTouchEvent() method since you may be losing the event when an ACTION_MOVE event comes up and you return false. Other than that, could you show us your layout file? I doubt the change in background color has any effect on this, but it could be that some part of your layout is causing this.
Click to expand...
Click to collapse
Does anyone have a solution to this yet? More specifically, I think it's the Samsung's own implementation of ViewRootImpl that is causing this problem. I've been trying to figure out for a long time how to either pre-empt ViewRootImpl to intercept MotionEvents, or completely override ViewRootImpl. I found no success in either of these.
I also thought about reading from /dev/input/eventX directly, but this isn't feasible since it requires the phone to be rooted first. For myself it's ok, but if I'm writing an app for other devices that's not a solution.
Can someone from Samsung help?