Currently making an app that's made to be used in warehouses, since 60% of warehouse workers there use PDA scanners instead of phone, Expo's Camera scanner isn't good enough, and I am trying to figure out the most optimal way to handle those types of scanners, currently mostly the keyboard type ones
So far I tried react-native-keyevent combined with react-native-keyevent-expo-config-plugin, did not work, was just ignored in development and it crashed the test production...
Tried react-native-keyevent by itself after ejecting expo, was still breaking...
The only thing that worked so far was autofocused input that triggers a function with every onChangeText and that function refocuses on it, the issue: after pressing anywhere else, user would have to manually re press the input, ofc I could make it into an indicator whether the user "paused" the scans and make it into a kind of safety feature (if you can't fix it, it's a feature) but since there sure is a lot of pressing around included due to a lot of functionalities included to ease the work, it seems that having to press a "button" aka the input every time you want to continue the scanning work seems a bit off, especially since the purpose of use of PDA scanners over phone cameras is speed
Related
First off, this has never happened before on any other android device I've used (multiple devices have been tried and tested before this).
Now I have an app that I have worked on for a little over a year now, it is called AutomatedId (on the app store) and it has worked quite well for my company for quite some time.
Recently I have been given a device to add compatibility to the app (specifically for reading UHF tags) but that isn't the problem.
The problem comes whenever you open the app, the screen stops reading inputs completely, as well as buttons cease to function. I turned on developer options to see the screen inputs and as i suspected, it completely stops and does not read any of the inputs after the app is opened. Clicks don't work, buttons don't work, keyboard doesn't open, hardware buttons on the device stop working. It's a mess, does anyone know what could have caused this?
This is a S98 from here: http://www.wepoy.com/product_view_18.html
moved my comment to the answer as you said. This may be due to memory leak. Here are some references that may help you fix them: Fixing-Memory-Leaks-in-Android-Studio & use this library from square to detect memory leaks early: leakcanary
developer.chrome.com/apps/getstarted_arc#bestpractices
The ARC allows you to execute native android apps through the chrome browser by wrapping a chrome app around it.(As far as I can tell)
I am re-factoring an Android app to work well on Chrome. The first thing I need to do is to make the back arrow enabled at all times on the top left as shown below.
This is the program that allows Native android apps to run through chrome. I think the answer to my question lies somewhere in "Additional Metadata", or in the source code?
Add {"disableAutoBackButton": "true"} to the metadata. That will enable the back button within an activity. I've found that with my app that has multiple activities, though, it doesn't work to return to my main activity from my settings activity. It could be that I'm doing something wrong with the way I'm handling activities, I guess, but it works on all physical devices.
{"sleepOnBlur":false,"disableAutoBackButton":true}
please supply the above metadata before you download the zip or launch app from the arc welder
the first param prevents excessive pause/resume and also supposed to fix short black screen flash occurring occassionally in some of the apps.
the second params adds persistance back button on top left hence helping to avoid extra code required because of absence of back button in some screens(mostly the first screen)
I'm quite new to Android programming but familiar with C/C++ and Linux enough to program a few stuff. In my next project, I've to run some native application (Linux applications) under Android.
The executable I'm calling is using the framebuffer device to produce screen output. When I try to just call the program the output of the program is lost because Android is redrawing the screen, thus overwriting the framebuffer.
In order to prevent this, I made a "stubbing" Android program, which actually has no window design (just a black screen) but calls my program. This is working good to some extend; however, whenever I rotate the screen, or some Tattoo notification comes, Android redraws the screen and we're back to frame #1...
Thus, I wondered if there is a "low level" API or something, which can prevent Android from using the screen at all, as long as I release it. Shortly, like a WakeLock preventing phone from sleeping, I want a 'Lock' which will lock the screen (framebuffer device) completely. Does anyone know how can I achieve such functionality?
PS: This might have something to do with SurfaceFlinger, but I've read somewhere that it doesn't publish any API to user-level.
On Android the screen belongs to SurfaceFlinger.
The executable I'm calling is using the framebuffer device to produce screen output.
That's not supported.
Thus, I wondered if there is a "low level" API or something, which can prevent Android from using the screen at all, as long as I release it.
Nothing that is supported at the SDK or NDK levels. You are welcome to create your own custom firmware that does whatever you want, and load that custom firmware on your own device.
Otherwise, please use a supported means for interacting with the screen (e.g., OpenGL natively in C/C++).
I looked around and although there are many related questions I didn't see one that answers my exact question:
I would like to create an app that runs in the background that provides the exact same functionality as the hard coded 'Back' button in all cases.
The reason? I (for example) have a Droid X, and it is BIG. it makes it extremely hard to use one-handed and having a swipe gesture function as a back button (like in Palm Pre for example) would greatly increase the ease of use.
as far as I'm concerned the app could just be one simple class that contains:
1) a listener for the 'back' swipe
2) a call to the physical hard button itself
Is this possible? are there built in APIs for the hard coded buttons that would allow me to call them without actually pressing them?
Again - I'm not interested in overriding the button, I'm interested in making a software call to it - or failing that, in emulating it's behavior in any and all states and other apps!
Please forgive the naivete of this post. I am a very novice programmer and really I just want to know whether this is possible before I start to devote myself to trying to build it.
Thank you,
b
Is this possible?
By writing your own firmware, yes. Via an Android SDK application, no.
I'm looking for a way to grab trackball events while the screen is off, preferrably on a N1. I'm building my own music player and would love to add the feature to skip songs by trackball press, without having to unlock my device everytime.
I've found TrackBallSkip, however the source code has been taken down and integrated into CyanogenMod. I fear that I may need to do something exotic to my phone (root it, mod it, whatever). While this isn't a problem, I would be happier if I could freely share my Music player.
Can anyone confirm that I'll need to mod the home to get access to this functionality? Or can I just straight code it (if so, any pointers in the right direction would be amazing).
Thanks!
I found where Cyanogen put TrackBallSkip into their source base (this commit). It appears to reside in phone/com/android/internal/policy/impl/PhoneWindowManager.java which means it can't be implemented without modding the firmware (since the related package resides in /system).