Is it possible to persist a Bluetooth LE connection on browser refresh? Or at least minimize the pairing time?
Eventually navigator.permissions.query would support this. Sample code from Web Bluetooth Specification
navigator.permissions.query({
name: "bluetooth",
deviceId: sessionStorage.lastDevice,
}).then(result => {
if (result.devices.length == 1) {
return result.devices[0];
} else {
throw new DOMException("Lost permission", "NotFoundError");
}
}).then(...);
However, no browser currently implements this.
As of Q3 2017 the chromium implementation is actively working on Web Bluetooth but not this feature.
I recently implemented a new permissions backend as well as two APIs that will enable previously permitted Bluetooth devices to be used.
The new permissions backend is implemented behind the chrome://flags/#enable-web-bluetooth-new-permissions-backend. The new backend will persist device permissions granted through requestDevice() until the permission is reset in Site Settings or the Page Info dialog box.
The getDevices() and watchAdvertisements() are implemented behind the chrome://flags/#enable-experimental-web-platform-features flag for Chrome 85.0.4165.0 or greater. The recommended use of these APIs is to use getDevices() to retrieve an array of permitted BluetoothDevices and then calling watchAdvertisements() on these devices to start a scan. When advertisement packets are detected from the devices, the advertisementreceived Event will be fired on the device that it corresponds to. At this point, the Bluetooth device is in range and can be connected to.
Please give this new feature a try, and file any bugs at https://crbug.com using the Blink>Bluetooth component.
Related
Reading call log is the basic feature of my app, but i dont know which option to select among the following in the list in the declaration form.
Default SMS handler
Default Phone handler
Default Assistant handler
Transactional backup and restore for users and archive for enterprise (time-limited/non-continuous)
Enterprise archive, CRM, and device management
Caller ID, spam detection, and blocking
Connected device companion apps (for example, smartwatch or automotive)
Cross-device synchronization or transfer of SMS or calls
SMS-based financial transactions and related activity where access is restricted to financial SMS transactions (for example, 5-digit messages)
SMS based money management
Proxy calls
Services - Carrier
Services - OEM
Device Automation
Physical safety / emergency alert apps (e.g., senior safety)
Call-based OTP account verification
Using SMS_CB_RECEIVED for customer communications (e.g., Smart Zone Cast service)
Write and Show Call History in Dialer
In-vehicle hands-free use or projected display
Anti-SMS Phishing
Since its only write and show call history in dialer option thats close to my requirement, i selected this, but now i got thefollowing email from google.
Google Play
Developer update
Hi Developers at Bot Entity, Thanks for contacting the Google Play
team about your app Whatsupp Direct, com.whatsappdirect.wd. Publishing
Status Publishing status: Rejected After review, your app has been
rejected and wasn't published due to a policy violation. If you
submitted an update, the previous version of your app is still
available on Google Play. Issue: Violation of Permissions policy After
reviewing your app, we found that it doesn’t qualify to use the
requested permissions for the following reason(s): App is using
unnecessary permissions When you submitted your app, you specified
your app's core functionality as follows: Write and Show Call History
in Dialer. However, based on the permitted uses, your app is only
allowed to access the following permissions: WRITE_CALL_LOG. Please
remove the following permission(s) from your app: READ_CALL_LOG.
now how do i get READ_CALL_LOG in the list??
I am developing an iOS app for Phantom 4 Pro, using the DJI SDK for iOS.
In my app, I need to ensure that my user's entire private data, such as Photos, Videos, Location, Flight plan, etc should remain local, and should not get shared to anyone without user's discretion.
For achieving this, I went through the API Reference, and found the class DJILDMManager, which mentions that by enabling the local data mode, the most appropriate for users that have very stringent data requirements.
Here, I need to know what minimal information could still get shared to DJI (or anywhere else), when I have the Local Data Mode Enabled.
More Information
Even with Local Data Mode (LDM) enabled successfully, I have observed the following network requests from the app for creating HTTP tunnels:
CONNECT mydjiflight.dji.com:443 HTTP/1.1
CONNECT active.dji.com:443 HTTP/1.1
CONNECT api.dji-services.com:443 HTTP/1.1
CONNECT flysafe-api.dji.com:443 HTTP/1.1
I would appreciate your inputs regarding these requests, as I am not sure if they are capturing drone's data, but app does seems to reach out for DJI servers in LDM enabled mode.
To monitor the status of LDM becoming supported listen to the notification that LDM Manager posts when the supported status changes. From here you can then enable LDM and continue on with the workflow of your app. Note that until LDM is enabled you may still see networking requests and after LDM enables you may see one request for registration.
[[NSNotificationCenter defaultCenter] addObserverForName:DJILDMManagerSupportedChangedNotification object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
if([[DJISDKManager ldmManager] isLDMSupported]) {
if (![[DJISDKManager ldmManager] enableLDM]) {
NSLog(#"LDM Enabled");
} else {
NSLog(#"LDM Disabled");
}
} else {
NSLog(#"LDM Not Supported");
}
}];
With LDM enabled (make sure to check first if supported in your region) the only communication that will go through to our servers is the registration.
Registration sends basic statistical information such as device type and verifies that the app key used is valid.
This happens once with our server and is then cached locally.
It may happen again after if the cache is not usable, but only once per app launch.
Registration doesn't send Photos, Videos, Location or Flight plans.
Nothing else is sent after LDM is activated.
Keep in mind that with LDM on, you won't get many of the online features including updated GEO features.
I am unable to cast with my styled receiver from chrome browser.
I have an unpublished styled receiver chromecast app. The "preview" button works fine. My testing device is registered with status "ready for testing". The send serial number checkbox is checked from my android app (OS X app never finds chromecast, so I cannot verify with another app).
Setting the app ID to be my application ID (which seems to be an 8 digit number in the SDK developer console) throws a session error when I try to connect. Changing this back to the default app ID has success. I registered a second identical application and tried with that ID as well.
What could have gone wrong? I am unable to connect to the debugging console, but I read on SO that you need a custom receiver (not styled receiver) to connect.
I am able to connect to the custom receiver as defined in this sample receiver as well.
Is there no testing for styled receivers?
Note that there is one oddity about my setup, and that is that the chromecast is connecting to a wifi network that has been shared by my macbook, not a normal router.
You don't need a custom receiver to be able to debug, using your own Styled receiver is adequate (you basically need to have your own App Id). I would suggest you double check your serial number; take a photo and enlarge that to make sure it was read correctly.
Solution was use a router instead of sharing internet access via Wi-Fi from my macbook. Re-checked the send serial number box, restarted device and everything worked.
I'm using the code from this article, with phonegap app.
http://blogs.msdn.com/b/glengordon/archive/2011/12/02/phonegap-on-wp7-tip-3-sending-sms-and-intro-to-plugins.aspx
The plugin works all fine, but when the SMS is sent, I want to return to my app automatically. Is this possible? If its possible to send an SMS without go to the default integrated sender, it could be even better.
I'm a newbie to C# and windows phone apps - please help me ;)
there is no way to avoid the integrated SMS sender due to security reasons. User will return to your app after hitting the Back button on the SMS conversation page (that is esured automatically because of the stack-controlled nature of paging in WP7, but will not return after hitting the home button (again, this behavior cannot be prevented in any way) and your app will be suspended (possible to return to it by holding the back button and choosing it).
I'm trying to develop J2ME SMS applications (on Symbian, but that's not important).
I tried with the simplest app that sends a SMS when it receives one.
It is completely based on the example provided by JSR-205:
The base class is made implementing MessageListener.
Then the following methods are implemented (I left out all try/catch for simplicity).
I have two problems:
it doesn't work
I don't know how to debug it in Netbeans7.1
In particular I'm interested in an answer to the second question: how can I emulate an SMS reception in Netbeans7.1 in order to set a breakpoint in notifyIncomingMessage method?
public class Example extends MIDlet implements MessageListener {
public void startApp() {
messconn = (MessageConnection)Connector.open("sms://:6222");
messconn.setMessageListener(this);
reader = new Reader();
new Thread(reader).start();
}
public void notifyIncomingMessage(MessageConnection conn) {
conn = (MessageConnection)Connector.open("sms://+39xxxyyyyyyyy");
TextMessage msg = (TextMessage)conn.newMessage("Hello");
conn.send(msg);
}
}
class Reader implements Runnable {
public void run() {
wait();
}
}
The J2ME Wireless Toolkit 2.0 supports WMA 1.1, allowing application developers to easily emulate sending and receiving SMS and CBS messages between multiple device emulators based on MIDP 2.0.So you can use The J2ME Wireless Toolkit WMA Console.
The console emulates a simple wireless messaging device. Each console instance - you can run more than one console at a time - is identified in its title bar by a unique number, referred to as its phone number to reflect the way a real device works. The first console is assigned the number 5550000 by default. If you immediately open a second console, it is assigned the number 5550001, and so on.
To use the console, start the toolkit's Preferences application, choose the API Availability tab, and make sure that the Wireless Messaging API is checked. Now run the Utilities application and on the right side of the window press the Open Console button. (You can also get to the Preferences and Utilities applications from menu items in the KToolbar application.)
To send a message from a console, press either the Send SMS or Send CBS button. The resulting dialog has two pages, one for text messages and one for binary messages. The SMS dialog lists the numbers of all console and emulator instances (collectively referred to as clients) currently running. Select the desired clients, enter the port number to which the message is to be sent, and either type the text message or select the binary file you want to send, then press the Send button. The CBS dialog is a bit simpler since the message will be broadcast to all known clients - supply a message identifier (a number) and the text or file to send, and press the Send button.
The console's main window lists the messages it sends and receives. You can use two console instances to chat with yourself, but it's much more interesting to involve an application in the conversation, so that you can verify that the application is sending and receiving messages correctly.
EDIT1:
In netbeans you can start WMA console from Tools | Java Platform | | Tools & Extensions | Open Utilities. Note that not all SDKs support this.On the other hand Go to your J2ME platform installed directory and search for some files look like utils.exe then double click on it.
EDIT2:
If you have problem yet,you can try other platforms.I have sony ericsson sdk 2.5.0.6 and it is easily to find "utils.exe" in it's installed directory.
You can see good tutorials and notes in references.
References:
Mobile P2P messaging, Part 1
The Wireless Messaging API
The J2ME Wireless Toolkit WMA Console
tebyan.net