Hi,
I am trying to put a code together to control the refresh behavior of the e-ink screen. The final goal is to have a drop-in library for app developers to help making their app more e-ink friendly.
The code works already for the PRS-T1, but needs a different driver for the Nook Touch (N2EpdController included).
My one and only beta tester gets the famous "There is a problem parsing the package" error. Pls find enclosed the sources.
I would be grateful if someone could fix possible Eclipse setting or other errors.
Hi,
I have some interest in adapting apps to the eink screen, so I will try to help with this. Unfortunately, I cannot post in the dev forums yet.
When you get error installing apps via android UI, it is useful to do via "adb install" to be able to know the error cause. The message was "INSTALL_FAILED_OLDER_SDK", which I solved by lowering the android:minSdkVersion parameter in Manifest. Then, the app installed and ran fine, but didn't do the desired effect yet. I will check the code now...
---------- Post added at 02:41 AM ---------- Previous post was at 01:53 AM ----------
I see that you're trying to use enterA2Mode() for the nook (btw, there is a typo at NoRefreshEnablerActivity.java:29, it should read EINK_NOOK). I've been playing around with this some time ago when I started developing a fast e-ink drawing app for the NST, you can see it here: https://github.com/marspeople/E-Paper (WIP).
With few testing I've done, I guess the 1-bit mode (A2) setting is not applied globally: it should take effect only in the View from which it is called. I haven't investigated further to try to use it globally.
Hi marspeople,
Thanks for pointing out the type, it should read
} else if (DeviceInfo.EINK_NOOK)
Regarding the global value of mode setting. From what I understand, A2 is a permanent mode, so whatever function or app is setting the updatemode, it is kept. With the PRS-T1, it is reset by calling any stock (Sony) app. For the Nook I don't know..
Good luck in compiling, hopefully we come to a version which works on both devices. Then I can proceed to dynamically change the updatemode within an app.
Yes, the A2 mode is kept until any process resets the EPD. Using logcat, I noticed several epd_reset_region messages appearing automatically when I close your app to go back to the launcher. It seems the system overrides the EPD setting, making impossible to use A2 system-wide (at least by this method).
However, if you want A2 just for an app, calling enterA2mode() will probably work, as I used in my own app above.
Can you send me your apk?
salsichad2 said:
Can you send me your apk?
Click to expand...
Click to collapse
You mean the apk for "NoRefresh" or my drawing app?
Hi marspeople,
I would be most interested to know why the initial source code does compile ok, works on the PRS-T1 and does not install on the Nook Touch + the fixes.
With this knowledge I can write either an app to set refresh modes or within apps.
Did you succeed to compile and install on Nook?
Hi again,
in your N2EpdController.java
Code:
83: mtSetRegion.invoke(null, "aarddict", enumsRegion[region], regionParams, enumsMode[mode]);
I would like to replace the hardcoded "aarddict" by something dynamic.
What would be the correct function to infer the wanted name?
Code:
activity.class.getName()
this.getClass().toString()
.. ?
bardo8430 said:
Hi marspeople,
I would be most interested to know why the initial source code does compile ok, works on the PRS-T1 and does not install on the Nook Touch + the fixes.
With this knowledge I can write either an app to set refresh modes or within apps.
Did you succeed to compile and install on Nook?
Click to expand...
Click to collapse
Yes, sorry about the confusion, but I managed to do it, despite the A2 mode didn't work. What I did was just edit the AndroidManifest.xml, changing the android:minSdkVersion parameter to 7 (since the NST runs Android 2.1).
Good luck finding out how to set A2 mode permanently. I guess you don't have a Nook, so feel free to ask me for testing purposes.
Since the Nook A2 mode seems to be overridden when switching foreground activity, I've tried another approach with a background service which toggles A2 mode when requested by user. This way, the foreground activity isn't switched and "fast refreshing" mode works (until you change activity).
This fast refresh mode (called A2) is only possible because it uses only 1-bit depth, i.e, just black on white, meaning you can't see grayscale pictures but it's good enough for black text on white background and scrolling. I have not "created it", it is built-in from the device (you can test using the stock reader, it is activated when holding a page button). What I implemented is a way to activate and deactivate it at user will from inside any app.
Thanks to dairyknight for his N2EpdController class, which made this possible.
Thanks to bardo8430 for bringing the idea.
Thanks to AndroSS source code for screenshots used in automatic contrast.
Changelog:
01/Mar: Now when you launch the app and it is already running, it will activate NoRefresh mode. So you can also use an activation shortcut to the app using NookTouchTools (i.e. B&N's book icon at top left corner).
02/Mar: Improve activation shortcut to perform toggle between modes. Tap gestures aren't needed anymore (use "-noGestures" apk version if you don't want them).
04/Mar: Got rid of initial ghosting by redrawing the screen after activating A2.
04/Mar (2): Minor improvement of removing ghosting at screen edges.
12/Mar (Beta): Now you can adjust contrast in A2 mode. Images shouldn't be dark or black anymore if you raise the contrast a bit.
22/May: Completely redesigned version 2.0:
- Several options can be customized via settings screen.
- NoRefresh can be toggled by manual app shortcut, tap gestures or automatically according to screen animation (new).
- New App Whitelist to avoid unwanted activation in specific apps (except for manual mode).
- Background service can be launched at boot.
- Small improvements and tweaks.
- Custom app icon (finally )
06/Jun: Fix crash on empty whitelist
08/Jul: (Version 2.1)
- Automatic contrast when activating NoRefresh, according to total "brightness" of the screen (simple algorithm). This should ask you for root permission.
- Also supports manual setting in specific situations (customizable).
- Fix possible crash at startup.
26/Jul: (Version 2.2)
- Fix contrast setting behaviour
06/Dec:
- Alternative version with fixed compatibility for FW 1.2.0 available at https://github.com/marspeople/NoRefreshToggle/downloads
First Video: http://youtu.be/6pBPsyno5PY
Other Video: http://youtu.be/kBbl6egyPsQ
Another demo: http://youtu.be/5b7JjllImjM
Repository: https://github.com/marspeople/NoRefreshToggle
Great to see that it works on the Nook! Good job.
When I try to compile on Eclipse, I have to remove the below Override:
//@Override
public boolean onTouch(View v, MotionEvent event) {
otherwise I get an error: The method onTouch(View, MotionEvent) of type A2Service must override a superclass method
When I compile with this mod and run the app, nothing happens after using your gestures. Except that I tap on other icons which then try to launch other apps.
Should NoRefreshToggle keep the focus?
I have a suspicion: The PRS-T1 needs to call a function of the Sony library with extended parameters to pass the updatemode. ANY function carrying the mUpdateMode parameter would do - but it must be called. Which might be the problem here. In the used EinkListView.java, a lot of "injection" functions like below are defined.
Code:
@Override
public void scrollTo(int x, int y) {
try {
Method invalidateMethod = super.getClass().getMethod("scrollTo",
int.class, int.class, int.class);
invalidateMethod.invoke(this, x, y , mUpdateMode);
} catch(Exception e) {
e.printStackTrace();
}
But your code has neither a Listview, nor would any injection function trigger. I am afraid you would have to make the app use a ListView (or WebView).
Can you?
bardo8430 said:
Great to see that it works on the Nook! Good job.
When I try to compile on Eclipse, I have to remove the below Override:
//@Override
public boolean onTouch(View v, MotionEvent event) {
otherwise I get an error: The method onTouch(View, MotionEvent) of type A2Service must override a superclass method
When I compile with this mod and run the app, nothing happens after using your gestures. Except that I tap on other icons which then try to launch other apps.
Should NoRefreshToggle keep the focus?
Click to expand...
Click to collapse
Well, I noticed that problem of accidentally tapping unwanted widgets, I would recommend tapping on a free area of the screen. I could use an overlay button, but it would occasionally get in the way too. What do you mean by "keep the focus"?
---------- Post added at 09:13 PM ---------- Previous post was at 09:05 PM ----------
bardo8430 said:
I have a suspicion: The PRS-T1 needs to call a function of the Sony library with extended parameters to pass the updatemode. ANY function carrying the mUpdateMode parameter would do - but it must be called. Which might be the problem here. In the used EinkListView.java, a lot of "injection" functions like below are defined.
Code:
@Override
public void scrollTo(int x, int y) {
try {
Method invalidateMethod = super.getClass().getMethod("scrollTo",
int.class, int.class, int.class);
invalidateMethod.invoke(this, x, y , mUpdateMode);
} catch(Exception e) {
e.printStackTrace();
}
But your code has neither a Listview, nor would any injection function trigger. I am afraid you would have to make the app use a ListView (or WebView).
Can you?
Click to expand...
Click to collapse
Well, to capture touch events I've used a dummy View which is added to an overlay (see A2Service.java:43). Despite being an android Service instead of Activity, maybe you can instantiate your ListView there and hopefully it will work.
Thanks for the hint on the dummy view, will try.
"keep the focus"?: window manager speak, I mean that a tap stays within your app and does not act on the icons below.
bardo8430 said:
Thanks for the hint on the dummy view, will try.
"keep the focus"?: window manager speak, I mean that a tap stays within your app and does not act on the icons below.
Click to expand...
Click to collapse
Since I'm using a transparent overlay, I have to let touch events pass through, otherwise only my app would see them.
PS: I've added a demo video at a previous post.
I've been trying to improve the functionality of the app by changing from this manual toggle approach to something like: fast mode is triggered (a bit after) when user starts dragging his finger on the screen and restored when released.
However, I've been searching how to do this with no success so far. The invisible overlay that detects touch events currently is only able to capture MotionEvent.ACTION_OUTSIDE event type, which is useful to detect a tap, but can't deal with a drag. I also need that the drag is passed normally to the app below (to perform scrolling or whatever).
I've found this page (http://stackoverflow.com/questions/8073803/android-multi-touch-and-type-system-overlay) in which is proposed a solution that can detect a drag but can't pass it to the app below.
The code is now here: https://github.com/marspeople/NoRefreshToggle . I would appreciate any help from developers.
Maybe it can be run every 1 second when screen is on. I mean nook is not locked. I don't think that changing one parameter would eat battery. Is it worth a try?
Hi marspeople,
thanks again for taking this. My initial intention was to help app developers with no e-ink experience to easily adapt their code. Doing these things inside an app is much easier but needs access to the source.
See the related question on stackoverflow:
http://stackoverflow.com/questions/9391710/adapt-scrolling-swiping-to-e-ink-screens
The external app was used as a mere demonstrator to have it work on the NST and PRS-T1. Good to have a repository for it now.
marspeople said:
Ok, I think I've got it.
Since the Nook A2 mode seems to be overridden when switching foreground activity, I've tried another approach with a background service which toggles A2 mode when requested by user via a touch gesture. This way, the foreground activity isn't switched and "fast refreshing" mode works (until you change activity).
The activation gestures I'm currently using (unfortunately, it seems you can't use hardware keys using this approach) are:
- 4 "downward-right" taps (each tap must be done to the right and below the previous one) to activate (A2 mode)
- 4 "upward-left" taps to deactivate (Normal mode)
Video: http://youtu.be/6pBPsyno5PY
Here is the source code and a apk. bardo8430, I believe it would be easy to port this to the PRS-T1.
Click to expand...
Click to collapse
Noob question.
So I just install the apk and run it and I have Norefresh.
dark_hawk said:
Noob question.
So I just install the apk and run it and I have Norefresh.
Click to expand...
Click to collapse
yes, just open the norefresh app, and like the youtube video tap the screen from top left to bottom right 4 point
but i think the trade off is the screen go black&white with no grayscale (at lease for me)
PSV Review (WiFi):
Rough Draft Copy, just to jot some points down, will organize and revise later, mostly about Vita Pros and Cons, not a game experience review
Pros:
- Great HW quality, solid feeling dual joy-sticks, better than its predecessor
- Quality screen OLED 5” 960x544 (I think OLED has become common place going forward since 2011, where the prices of OLED have fallen enough to be affordable on sub ~5” screens.)
- Responsive touch screen (Capacitive) (Popularized by the iPhone, Capacitive touch screens have become common place for brand name devices for the pass 2-3 years)
- Responsive Gaming action, no lag felt during game play in all games including Wipeout, StarDust Delta (though it’s the least you can expect from a custom tailored game SW and HW solution, unlike generic solutions like Windows, Android solutions where hardware resources available on the device are unknown to the SW developer)
- Lots of hardware controls (Gyro, Accel, and your regular HW buttons)
- Light Weight, easy to hold for extend periods of time (on the flip side, this could mean small battery, and explain the 3-5 hr battery life, since the battery is almost always the most physically dense thus heavy component of a system)
- Loud enough speaker (when not covered by finger)
-CONs:
- Hardware: The SGX543CPU is from 2009 (probably reasonable for a $250 device)
- Hardware: No GPS (probably reasonable for a $250 device)
- Packaging: Typical Sony package, bare essentials, no free bonuses like cheap sleeve common with other manufacturers
- Hardware: Backtouch screen is not 1:1 with the front, due to the Sony sticker offsetting the back touch screen by a couple millimeters up, when you compare by touching the front and back touch screen together with your fingers clamped to approx the same place, you’ll notice the back touch is offset by a few millimeters above the front touch screen. This means the backtouch is not exactly intuitive when used in reference to what you see in the front.
- Game: Wipeout: In Wipeout control mode, moving right finger at many times hits the right d-pad up, reversing the ship unexpectedly, This means the Right D-PAD to a little too close to the action buttons.
- OS: BUG: instability on OS screens, ie: settings, power down
- OS: BUG: Poor automatic WiFi Access Point selection. Vita will automatically erroneously pick the access point with worse signal
- Hardware: speaker placement, causes sound to go in and out every time the finger moves to hit different buttons, inadverdently covering the speaker, recommend bottom placement to avoid accidental covering
- OS: BUG: Bluetooth Stereo a2dp doesn’t reconnect upon device resume
----- poor game sound quality when Party voice is enabled
------have to manually reconnect to headphones
- OS: Interface: interface is very touch dependent, this was the same as Sony’s other newly converted touch devices, they tend to abandon all hardware button controls and force touch screen navigation as if the developers got too carried away by its discovery one day. There are many GUI instances where HW buttons still make more sense even in the presence of a touch screen. Like when there is only 1 button available to press (ie: ok) that should be equally accessible by our familiar X button, practically speaking it’s silly to completely abandon the HW interface. Lazy interface programming
- OS: Interface: Double tapping apps. In all apps/games, to access them, you first have to click on the icon on the app drawer, and then again click on the start button of the program to start the program.. I understand that some gaming information (ie: website, addons) is put in front but given the rarity of usage, couldn’t they be put into the main game screen? Other apps such as settings, friends, party, where there isn’t any other options on the front screen, what is the point in forcing the user to double tap?
- OS: Integration: Party, group apps, Friends, trophies, I’m still confused as to which app to launch for what purpose. These separate programs could have been integrated into one social app, where you can see your friends, select them to text or group chat or trophies.
This gated unintegrated experience forces a lot of guesswork and wasted load times between related apps that otherwise should have been an easy all-in-one integrated experience like other mobile social apps.
- OS: Interface: quick program switch, not allowing the top bar swipe gesture to pull down the list of open apps was a missed opportunity for quick app switch and WiFi on/off switching. The PSV seems to force the Playstation button on users to switch out of apps. Unfortunately, Sony is forcing the touch screen when it makes sense to allow HW button and forcing HW button, when it makes more sense to use the touch screen.
- OS: Interface: Cut and Paste: Again it seems pretty inconvenient whenever you want to move type something you’ve painstakingly typed on the touch pad to a different location, there is no way to do it. You are forced to retype what is already in front of you again. I would have accepted it even if the Copy clipboard was confined to pasting from the same program. For example, if you just see a non hyperlinked URL on the webpage that you’d want to go to in the browser, you’d literally have to manually type it in yourself. Or in the chat program if you want to refer to some text previously typed by copying the quote, again, you’d have to retype the whole passage manually. This might not be as big of an issue with an HW keyboard but when the device is dependent on a small touch screen keyboard, you’d want to make every effort to minimize any unnecessary typing.
By the year 2012, I would have expected Copy and Paste to be the most basic function across all text enabled devices.
- OS: Interface: Text cursor, not accessible by d-pad, forces touch access, but no text cursor handle like on Android and iPhone that allows easy cursor movement between characters. By the year 2012, I would have expected cursor control to have become a basic best practice across all touch enabled devices that have text cursors. (edit: cursor control is actually hidden, you have to press and hold the cursor for a second and the text field will magnify allowing you to drag and move the cursor back and forth. So this is good, but if only it wasn’t hidden to be found by accident.)
- Browser:
----------Double tap zoom is broken on many sites
----------No copy and paste
----------poor compatibility, even simple javascripts that are necessary to open certain webpages properly don’t work, for example I was unable to load the flyer from a simple futureshop webpage at all.
- OS: Interface: App Management:
There seems no way to organize the apps into folders, for example, Action games into one folder, puzzle games into other. On my android OS, I have 50 programs and games, none for which would be manageable if they were all just together in the app drawer, but thankfully with folders on the home screen, I was able to categorize them into their respective folders by functionality.
- OS: BUG:
Flight mode: with flight mode enabled, if you grant an app request for WiFi connection, the WiFi turns on, and the game proceeds. But BOTH the flight mode and WiFi icon remains active on the top bar even when the app has been closed. It appears the apps have no way of telling the OS what it’s done with the WiFi or that the OS should return the WiFi to its original state. In fact, after checking the Network settings, OS indicates flight mode is still enabled even though WiFi is also active. The redeeming factor is that upon closing the app, the WiFi icon does disappear (sometimes). But upon subsequent launch of the app, it no longer requests to enable the WiFi, it just does it automatically. The proper behavior should have been to ALWAYS ask for permission when Flight Mode is enabled, this could have serious implications for hospital settings where the WiFi gets inadvertently enabled without the user’s notice and permission. This is fairly poor hardware handling by the software
- OS: Functionality: Multitasking: The browser can not run without first closing the game. This means it's pretty hard to quickly reference for Walk-Throughs or cheat codes while you're playing a game without either first quitting or having a second device handy. It's completely understandable if games won't multi-task amongst other games, but when even the webbrowser doesn't work, essentially there is no multi-tasking, besides on built-in programs like Party, that needs it to be on for the Party Voice to work in game.
-Reviewer:
Last mobile console: NDS, last played 1 year ago, causal player of mobile games. Occasional PC gamer who enjoys some causal tablet gaming when bored.
Owned Sony devices:
Cameras: DSC-T9
Laptops: Vaio P
e-Readers: PRS-505, PRS-650, PRS-950
Gaming: PS2, PSV
What i was interested in is transfer game play between ps3 and the vita?
I thought that is what i saw on tv...
Any thoughts on that?
davidrules7778 said:
What i was interested in is transfer game play between ps3 and the vita?
I thought that is what i saw on tv...
Any thoughts on that?
Click to expand...
Click to collapse
Im curious about that too
Sent from my X10a using xda premium
buump bump proof
Buy an Xperia Play
Sent from my Nexus S using xda premium
I read that some peoples have issues with the touchscreen sensitivity. I've thinked i've got the same problem until i activate some developers options Options: "Show touches" and "Pointer location". Thereafter i realized that the touchscreen is perfectly responsive, the only issue is that when i click somewhere, my finger sometimes slip a bit and the touchscreen take it as a Swipe, then i have to click another time. The TF701 have a high density PPI (300) and it seem the touchscreen is not calibrated in accordance to that density.
By example (I don't know the real values!)
on my Motorola XOOM (150 PPI), the device need at least 30 pixels movement to detect a swipe = about 2/10 inches
on my TF701 (300 PPI), the device need at least 30 pixels movement to detect a swipe. = about 1/10 inches
What do you think about it?
Is it tunable by an application?
I found TouchScreenTune on the PlayStore but have never tested it since it's not marked as TF701 compatible, and i'm not root.
I found editing the following options makes a huge difference.
In the build.prop add the following lines:
Code:
# Improve Touch Pressure
touch.pressure.scale=0.001
ro.min.fling_velocity=90000
ro.max.fling_velocity=200000
Obviously the first line is just a comment
Also you can speed up browsing by enabling debugging mode in the browser by typing the following in the address bar
Code:
about:debug
Then go to the settings and the new debug menu and enable:
enable hardware accel
enable cpu upload path
enable light touch
Click to expand...
Click to collapse
Or just unlock and flash CROMi-X for all these and loads of other tweaks built in
Is there a way to change these settings without flashing a new ROM?
dutchguy said:
Is there a way to change these settings without flashing a new ROM?
Click to expand...
Click to collapse
Well you need to be rooted but yes just follow the instructions above. The browser set won't stick on a reboot though so you'll have to keep doing it.
Is it possible to call a Javascript function that exists within a WebView from Tasker? I tried calling a URL on the WebView of "javascript:FUNCTION_NAME()", but that did not seem to work.
This is a completely random example. Lets say, from Tasker, that I want to be able to change the background color of the body of the WebView.
In the webview, I have the code
JavaScript:
function ChangeBGColor(NewColor)
{
document.body.style.backgroundColor=NewColor;
}
I want to be able to call ChangeBGColor() from Tasker with a color.
I remember having this same question a while back and was unable to find a solution that didn't involve sending HTTP requests, so I came up with a really weird hacky solution. I'm not sure its going to work for your situation, but maybe it can give you some ideas.
On the web side- have a transparent div element that occupies a single pixel. Put it in a corner or somewhere you won't accidently touch it. Now, add an event listener to it like this:
element.addEventListener('touchend', (e)=> {
let x = e.changedTouches[0].clientX;
let y = e.changedTouches[0].clientY;
renderColor(x, y);
});
On the Tasker side- If you don't already have it, download AutoInput, which is plugin that was created by Joao Diaz before he took over development of Tasker, and its incredibly cheap for what it does. You can use it to simulate a swipe gesture that starts at that exact spot on the screen, and ends at the coordinates you specify. You now have a way to send two values from tasker to you Javascript with a possible range of your screen resolution.
This might be challenging if you want the full spectrum of colors, because ideally you would want 3 parameters with 256 possibe values (0 for 00 and 256 for FF), so you'll have to figure out a way to encode and decode your color. You could either dumb down the resolution of colors and then use some math involving the modulus operator, but a better way would be to send the data via two swipe gestures, which would give you 4 parameters to work with- so to send white with full opacity (FFFFFFFF), simulate a swipe starting at 0,0 and ending at 256, 256 (FF or 256 for your alpha value, and the same for red), have your Javascript function store that in a variable. Then, send the second swipe which in this case will be the same as the first, and you now have 4 values to give you your color. Keep in mind you'll want to offset everything by 1 or you wouldn't be able to send black, since swiping from 0,0 to 0,0 won't trigger anything.