I just wanted to make clear. I am using accelerometer in my app, So do we need to add any other framework or method to receive iPhone5s's M7 co-processor data? Is that enough of using CoreMotion framework with Method
-(void)startAccelerometerUpdatesToQueue:(NSOperationQueue *)queue withHandler:(CMAccelerometerHandler)handler;
to receive data from M7 co-processor?Or am I need to include any extra method or framework to get data in iPhone 5s?
Thanks in Advance.
As said here:
The Apple M7 and M8 co-processors collect, process, and store sensor
data even if the device is asleep, and applications can retrieve data
when the device is powered up again. This reduces power draw of the
device and saves battery life.
So you don't need to add any other framework.
You can detect the M7 equipped device using [CMMotionActivityManager isActivityAvailable] - check the official documentation.
Related
I’m trying to retrieve raw PPG data from my Fossil Gen6 smartwatch, like other
developers who have posted questions below.
Android Wear: How to get raw PPG data?
What is the best way to save and transfer smartwatch sensor data on Android Wear OS (i.e. as CSV)?
After having finished reading through existing relevant posts, I gave it a try to retrieve raw PPG data via SensorEventListener.
However, unfortunately, my Fossil Gen6 wouldn’t return valid numbers!
To do double-check, I also installed the following app, which is a kind of PPG sensor tester app, in the Fossil Gen 6.
https://play.google.com/store/apps/details?id=io.kuprel.heart_monitor
And then, here’s what I got from the app!!
smartwatch screen
I guess the way to collect raw PPG data of Fossil Gen 6 differs from the previous versions…
Perhaps, some kind of access restriction to the PPG sensor value may have been applied
in the Fossil Gen 6 series.
So, please tell me the proper way to retrieve raw PPG data from Fossil Gen 6.
Thanks in advance.
Using the RadiusNetworks Proximity Kit, I have created a kit. Within the kit, I have created a region and registered my dev beacon. Next, I have attached key/value attributes to the beacon. My question is, once synched are these attributes physically stored on the beacon?
This article confuses me. Per this article:
They don't deliver anything. They simply broadcast a few identifiers.
Beacons broadcast a UUID, Major Value, and Minor Value. No user
consumable content is broadcast, just these IDs.
Along with the other info (UUID, major and minor versions), don’t these beacons also broadcast the key/value pairs?
iBeacons can only transmit one type of data: the UUID number. Beacons using the new Eddystone standard can transmit three types of data: UID (similar to UUID), URL (website addresses) and TLM (telemetry, such as temperature and beacon battery level). Standard beacons don't have any memory to store arbitrary data, but you could work around that by using the Lightblue Bean or building a custom beacon from Raspberry Pi. Like already mentioned, another option would be to use a backend, where you store and retrieve the data. We did a museum application that functioned with iBeacons using our Proximi.io platform, which is able to store the data for temporary offline mode, and re-syncs, when Internet access becomes available again. A third option would be to just build in all the data into the application.
Looking at the Proximity Kit Documentation, step 2 of the lifecycle says that your app will sync with their back end and that your "region data and configuration is cached and can be updated in the background."
I believe that your key/value pairs are stored in the cloud (and synced to your mobile device), and not stored on the beacon (since there is no way for their back end to connect to a beacon).
Background: I have an app which runs on an Android handheld (phone) but whose main purpose is to interact with an Android Wear watch. Correspondingly, the main source of data in the app is the wearable (not the handheld). I'm not currently using the DataApi to send this data from the wearable to the handheld; I had some issues with its reliability in the early days of Android Wear, so I rolled my own using the MessageApi.
Separately, I also cache the data I receive from the wearable in a SQLite database (on the handheld), so that my app has something to work with when the devices aren't connected.
Both of these pieces are working OK, but involve quite a bit of code. My question is, could the DataApi replace both my messaging layer and my local cache?
Obviously, the answer to the first half should be yes. This is what the DataApi is for, and in testing recently, it seems to have stabilized considerably since I first tried it out.
The second half is much less obvious. On paper, it looks like it could; the DataApi includes methods like getDataItem() which, apparently, can be used to retrieve data items which were synced previously. But this isn't its main function - is this aspect reliable enough to, well, rely upon for my app's main data storage?
Yes. DataApi actually uses sqlite to persist data on both devices. You are duplicating efforts, if you are using MessageApi and your own persistence.
i do not suggest using data api for data cache, because
1. data api queue cache has space limit, last time my test result is about 10MB
2. data api can not detect each data item if you put the same data content
3. data api may be deleted after use the item.
I wanted to know what NFC Execution environment means actually. In forum documents it is described as "An environment, either built into the NFCC or connected to the NFCC, where NFC applications are executed. The NFCEE may be included in entities with various form factors, some of which can be removable or replaceable.". But the Device Host(an application microprocessor like OMAP or Snapdragon) is the one which interacts with NFCC, as per my understanding in the mobile environment. Can anyone give me a example of what NFCEE can be - I mean is it another hardware module(if yes, which) or an android library to execute apps? What does "form factor" refer to?
The Execution Environment is in most cases a hardware module.
Newer SIM cards have a pin to connect the SIM to the NFC chip. Inside the SIM an application (payment for example) can run in a secure environment and talk to the NFC chip. Payment goes from a sales terminal through the NFC chip directly into the SIM without ever passing data through the application processor. So there is no easy way for malware to monitor or modify the payment process. That's a simplified view of the secure aspect.
Other execution environments are:
Embedded Secure Elements. These are in a nutshell SIM cards that are in the same package as the NFC controller chip. Your Android Phone most likely has one of these, called the SmartMX chip.
SWP (Single Wire Protocol) enabled SD-Cards. Same thing as a SIM, but in the form factor of an SD card.
The concept doesn't end here. There are for example experiments to move the execution environment to the application processor. For ARM CPUs there is the TrustZone extension which allows to execute code on the main CPU while still beeing secure.
In the Android API Execution Environments do two things:
they allow you to enable or disable the secure element by setting a route. The route configures when the secure element is active (e.g. has access to the NFC chip) and when disabled. Currently there are two routes in use: Route off (turns off the entire EE) and Route_OnWhenScreenOn (EE active when screen is on and unlocked).
For secure elements that are connected exclusively to the NFC chip (embedded secure elements) the Execution Environment also offers a secure way to exchange data from the application processor to the embedded secure element. This is used to install applications within the embedded secure element (among other things).
That's it in a nutshell.
I want to make a program for a restaurant, to hold foods and store customer recipe. What is the best way to store data? (core data - sqlite - ...)
You will find a conversation about core data vs. sqlite here. But, with iOS 5.0 you get the added benefit of being able to use iCloud file-sync for free if you're using Core Data. If you're using SQLite directly it'll have to be a lot of manual tinkering and implementation to get it to sync across iCloud.