I have a Oneplus 6 and it has this super cool functionality wherein I can draw certain gestures on the turned off screen and it opens up apps and other stuff.
For example: drawing a circle switches on the flashlight, drawing an S opens the camera and a few others.
I also noticed that other phones do not have this functionality and wanted to build an app for the same.
I searched across the web and couldn't find a solution. The majority of the posts gave the following insights:
It couldn't be done since touch recognizer is off when screen is off.
We might have to alter the kernel for this and should be done from a manufacturer's standpoint.
Turn the screen black and recognize gesture. (Only works on OLED displays and its not what i want).
This is my use-case. If anyone has any knowledge on this matter please let me know how it can be done. Thanks in advance for the help.
PS - There are a lot of posts with this same topic. Please don't repeat those answers. If it's a NO please specify the exact reason why.
Related
Apologies for an 'open' question, but can anyone provider pointers on how to 'dock' my app to the Android Wear watch face?
Essentially, I want users of the application to be able to swipe left to right (or vice-versa) from the edge of the screen to open the application, compared to having to scroll the list of applications after tapping the watch face.
I've seen this implemented in another wear app, but don't know the right terminology to produce meaningful results in Google. Is it a wallpaper service, specific view type, touch listerner service etc?
Many thanks.
You can't receive touch events inside the WatchFaceService, touch delivery is disabled.
I can't say for sure how the app you saw implemented the desired behavior, but it probably did by inserting views directly into the WindowManager from a Service.
Checkout this youtube video: https://www.youtube.com/watch?v=S3vHjxonOeg
I don't know how well the Standout library does its job, but it should give you enough examples to figure out yourself, how to add views to the WindowManager.
In my j2me blackberry application, I want to open editfield to enter text when user clicks on search icon. I have search icon added at the top right corner, when user clicks on it, I want to open basiceditfield with animating from right to left. I want Animation should be like default search on main screen in blackberry. How to do this? Is it possible?
You can do almost anything with the Blackberry Ui, if you understand it and are prepared to put the time in. But what you see when you press the magnifying glass is something that someone has spent a lot of time doing. There is API for doing anything like that (at least not one I have found). So if you are not experienced doing BlackBerry Ui, as I suspect is the case here, then I would suggest that replicating what the BB engineers have done with the animation from the search icon on the Home screen to the search screen, is too difficult to justify.
A lot of these sorts of things are, in my opinion, just gloss. They do not make the application any easier to use, just make it look flash. Personally, I would spend your time on making sure your application works well, rather than making it look flashy.
I do recommend using the screen transition animations as a way of moving from one screen to another. These are fairly easy to use and when used correctly, provide a good visual clue to your user regarding the flow through your application. I also suggest you spend some time making sure your assets (icons etc.) look good, on all the various sizes of BB that you are developing for.
I'm looking to add two finger "fluid swiping" to my app. Anyone who has used the week view in the Calendar app that comes with OSX will have seen what I'm trying to do.
I have a scroll view, and I want to be able to use swipe gestures and scrolling to move the content view in the horizontal axis of my NSScrollView, ie a day or a week.
The video from WWDC 2011 titled "Scrolling, Swiping, Dragging: Now with more animation" was quite useful, and looks like it will be able to explain what I want to do, but unfortunately the sample code for PictureSwiper isn't provided with the video.
I'm aware that a newer version of PictureSwiper is avaliable, but it uses NSPageController and I'm really looking for the older Lion 10.7 way of handling things as I can't use NSPageController. Is it still possible to find the old PictureSwiper somewhere?
If not could someone explain how the PictureSwiper sample on Lion worked? I'm aware of the App note https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html (search for "scrollWheel:") but that has only gone part of the way to explaining the kind of functionality I am after.
Many thanks for any help.
David.
For anyone looking to this for an answer I eventually used one of my "Developer Technical Support" queries that came with my paid Dev account to ask for the old code. A few days latter an Apple engineer emailed me the old Picture Swiper.
Now that I have seen the code the App note makes complete sense! Picture Swiper moves CALayers around, but in my case I just use NSClipView's scrollToPoint:.
Within the scroll handler I just do something like: (gestureAmount * columnWidth) + currentColumnIndexOffset.
Seems to work!
I am debating whether to hide or not to hide the system tray in a Windows Phone 7 application. I've not found any general suggestions on this issue -the official Windows Phone design guidelines don't address this issue at all - except for Jeff Wilcox's blog post who suggested that he personally likes to see the system tray in applications. I'd like some general advice on this issue from other Windows Phone developers.
Some reasons for showing the system tray are
Doesn't take up that much space
Users may want to see it at times
Reasons for hiding it are
You can't control its background: unless you're using PhoneBackgroundBrush as the background the top row will stand out
Lots of widely used / official apps already hide it: all games as well as the official Facebook and Twitter app.
I'd appreciate all advice on this.
Transparency and colors are now possible with Mango by setting its BackgroundColor and Opacity :
shell:SystemTray.IsVisible="True"
shell:SystemTray.BackgroundColor="Transparent"
shell:SystemTray.Opacity="0"
I would say by default show it unless it really gets in the way in a way you can't workaround, especially if its an app and not a game.
I would say it depends on the application/game you are writing
If the app needs a network connection or if you will be in the application for a long period of time show it so the user can keep an eye on network and battery.
If you need the extra screen space (for a game?), and you rarely need network hide it.
Or... I guess you leave it up-to the user and give them a setting to programatically hide/show it.
I think its best to use the tray in applications that are tools or utilities. Typically these users would prefer more info than less when they're using applications on the phone (battery, network, time).
Also adding the tray in there tends to make the application look more native on the phone (according to me and others I've asked), which is a big plus because the user associates your app as if it was built with the phone OS.
But if the application is a game, media, etc. type of application I recommend you take it off, especially on panorama because it takes away from the intended design. Also these types of applications focus on the content and seeing multiple little icons at the top can take away from the experience.
Really to me the space it occupies isn't really THAT much, so that shouldn't be too much of an issue. But rather the purpose of the app as stated above.
I do like the suggestions that have been given as far as giving the user the choice. Check out this code:
bool ShowTray;
//ASK USER WHAT THEY WANT
//ShowTray = true or false;
SystemTray.IsVisible = ShowTray;
I've been reluctantly hiding, at least on any view where I have a background image; otherwise it looks too strange to me. I've been considering a setting in my app that would allow the user to choose, and persisting that to isolated storage.
Also considering maybe having the top of the screen in phone background brush color and have it fade / blend into another color or background image. Not sure how well that would turn out but as long as it is not a cheesy looking gradient effect, perhaps.
I'm hoping eventually MS will soon add support for transparency in the system tray or otherwise help address this issue. As a user I wish that I could force the system tray to always be visible across all apps, but as a developer I realize that the visual effect often doesn't look good.
Perhaps if the community came up with a new UX metaphor where maybe double-tapping in the system tray area would toggle whether it is visible. A single tap could perhaps start to animate / pop / hint at the system tray...
I have a question about the windows mobile development.
I created a mobile form on the windows mobile 6.0 test project. But that example form slightly larger than the vertically normal pocketpc forms. I now everybody said you can press the scrollbar for accessing bottom or any location of the form.
But i need to use the finger for easy navigating form areas. This kind of iphone :)
Is it possible ? how can i make this ?
Windows Mobile 6.5 adds gesture support, that is supposed to allow such functionality for finger control. Of course, your code has to take advantage of it.
You can also write your own, which isn't difficult, but still cumbersome.
My answer could be classified as subjective. I try to now show the scroll bar when possible for just that reason. On most devices that have touch screen, you can scroll using you finger (and I'm a somewhat large guy -- 6'3" with farmer kid hands).
But if you are displaying a grid, that isn't always possible. The results can go off the screen very easily. Oh well, grab a pen and hit the scrollbar.
Other screen elements that can help: tab control. separate your controls into groups and put each group on a separate tab. I also do a lot of wizards with LARGE next and previous buttons.
But in all of this, if it is designed to be stylus free, just pray the user doesn't have to type anything using the screen soft keyboard. That just doesn't work with a finger.