I have a mobile IOS application which is basically group chat oriented. I was wondering if I can make it beacon-enabled app. With other words, application which can detect beacons, determine id, receive short ads etc. I am quite new to beacons, still reading a lot about it. I found this article which makes me believe that maybe it is possible to achieve my goal.
I want my app, except for its original functionality, to be able to:
Detect a beacon (even if app is in background, without the need to have been paired or whatever)
Receive simple ads by the beacon (while using the app in a certain mode, to be able to project the ads on phone's screen)
Read some real-time info(if required by the user) like: speed(if moving beacon), temperature etc.
In order to achieve all that I would like not to disturb the end user by making him download additional stuff related to the beacon. I want him to have my app and that's all.
You can monitor for beacons while your app is in the background. You can do this by using the CoreLocation Framework or by using a framework of your beacon supplier. (e.g. Estimote)
To the ads: The beacon will only deliver its pre configured ids. (UUID + Major + Minor). If you want to receive ads, you must have a Webservice that will get your beacon ids and return you the ad to display.
(If the ads never change, you can put them directly into your app without a webservice)
How you will show the ads in your app is completely open to you.
I don't really understand what you mean with real-time-info. There are beacons that also send you TLM. So you can get the temperature and the battery level of the beacon. I've never seen moving beacons or beacons that can transmit their speed.
Some useful links:
https://developer.apple.com/ibeacon/
https://xamoom.com/en/2016/07/ibeacon-for-developers/
Related
First, forgive my complete ignorance. I've tried to research this, but I clearly don't know the correct terminology for what I'm trying to accomplish.
I'm trying to set up NFC chips that link to separate, unique profiles. The profiles will be to a web app, but I want to hide the hyperlink to prevent someone from being able to copy the direct link to the profile and put it into another NFC Chip.
Example: A Plastic Business Card with an NFC chip that takes someone to a unique web app profile on their phone. I want to make sure someone can't create a new card and copy/paste the profile link into the new card on their own.
Note: The NFC Chip at this current moment will NOT be used for contactless payments.
Thanks.
So first point, security on NFC is hard, you can make it more difficult but not impossible to get the data from the card depending on how tightly you can control access to readers etc.
But from the sounds of it you are looking just to prevent casual copying.
It also sounds that you want the reading device to be a reading device.
So there are various techniques you can use to prevent casual copying, below I'll list a few in some order of complication (some can be used in combination with others):-
There is a common theme and drawbacks to some of these techniques.
You have to write your own phone App and get it to display the web App in it's own webview as you do not want the URL shown in a standard web browsers address bar.
Any protections you put in the phone App can be extracted from it by reverse engineering the phone App.
Use a NFC Tag like the Ntag21x range that has read password protection. You would write a phone App that knows the password to read the URL and then the App displays it
Encrypt the data on the card using standard encryption method and write an phone App that knows how to decrypt it and has the encryption keys to read the URL
Don't use a standard data format like Ndef but use your own data format again you phone app needs to know how you formatted the data to display
You can make reverse engineering of item 1 and 2 harder by not storing the "secrets" in the App itself but have it get it across the network at run time, but getting the secret can be reverse engineered or sniffed from the network.
I am developing Android Wear app that uses activity recognition to see if a user(office worker) have been in a still position for a certain time (if the user have been on their desk for too long), if so, it pushes notification, telling user to take a short break, and take a walk . I have followed a couple of ActivityRecognition tutorials aimed for handheld devices. After implementing code, during initial test the app on my watch does seem to recognise activities that I am undertaking with some minor issues. However, on stackoverflow I read that since android wear does not have dedicated ActivityDetection API, it will misbehave. Someone instead suggested to use accelerometer data for motion detection. On the other hand there is Google Fit API. Since I am new to android wear development I am not sure what is the right way to go. Could you please give me an advise on what is the right way to go in terms of tracking user motion, and if using ActivityRecognition for wear is reliable? Or should I try to make use of Google Fit API?
Google Fit API is commonly use to let users control their fitness data. If you want to push notification once a user is still in the same position for a certain time, I think you can use this API whenever a specific data source or data type is updated on the fitness store. Check on this documentation.
However, I have found this related SO question regarding Android activity recognition on wearables. I guess you already checked this link and I agreed on using accelerometer data to monitor the motion of a device.
The following code shows you how to get an instance of the default acceleration sensor:
private SensorManager mSensorManager;
private Sensor mSensor;
...
mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
Hope this helps!
Is it possible to get the amount of times an URL is received by a device from the proximity beacon API? I want to know what the click through ratio is of the broadcasted URL.
That depends. If you write your own app that scans for Eddystone-URL beacons and triggers some content (e.g., the web page itself) off of that, then naturally you're in full control and can implement this kind of analytics. Though it'll only apply to people which installed the app.
If you rely on Chrome for iOS, or the Physical Web iOS and Android apps to discover the Eddystone-URL beacons, then these apps do not provide any such numbers.
However, both Chrome for iOS and the Physical Web apps do fetch some metadata about the URL they detect, such as the page title and page description, without the user first clicking on the link. So there's a slim possibility that you could filter such requests out (they will be made by the Physical Web Service, or some similar "bot"), separate them from the actual visits, and do analytics based on that. Most likely however, this "bot," or the proxying service (which is there precisely to prevent this kind of tracking, and protect the user's privacy), will also do some caching, so you'll see fewer requests than the actual number of times the URL is received by the device.
And finally, dropping to a lower level, a note: most beacons are uni-directional, i.e., they broadcast information, but don't receive any information back, so beacons themselves usually can't count the number of packets on the receiving end. (I guess you could technically use the Bluetooth "scan response" mechanism to do that, but it would require custom beacon hardware/firmware.)
Unfortunately, no, it will not do this by itself.
Google's Proximity Beacon Api is a server-side system that stores metadata about beacons (location, battery level, etc) It requires you to add special client code integrated with your app to submit detection data.
Similarly, detecting Eddystone-URL beacons generally requires you to add custom code to your app to do the detections and and present the URL to the user. (The only exception to this is for some Chrome for iOS users with the Chrome Today widget enabled, and no public system provides click through rates.)
Since your app must present the URL itself you really have to roll your own solution to this problem.
If I understand right, you should be able to achieve this by Google analytics campaign. Setup a campaign, add campaign url to ibeacon url and you should be able to check the details analytics through Google analytics.
I'd like to know if it's possible to access personal information supplied within an app on a user's device and transmit that information on approach?
Example: Customer has my coffee shop app installed on their device and is logged into their account (where they have provided their first name). As they enter the shop, the barista can see their name on a tablet behind the counter and greet them by their name.
If so, can anyone point me in the direction of a demo or example?
Yes, that is possible, but it has to be done entirely in your app.
app detects the iBeacon
app sends the name (likely entered in the
app settings) to some sort of service (rest api, web service,
etc...)
the app that the barista has access to is notified of the
person approaching.
For a demo app you probably want to look at push notifications really, the iBeacon side is pretty boring for this use case.
As a total aside, make sure this sort of thing is opt-in - this could be creepy, and people don't like creepy.
After going through lots of codes provided over the internet, I am still unable to list my SMS app in default Android kitkat version. I don't know whether it can be done by adding permissions to the manifest file or through .java code.
The only thing I want is to, provide me some to-the-point code which I can make a new blank project(ABC), set the code in and that should set my app (ABC) the default sms app.
You can't directly set your app to be default, that would be a nasty security risk. What you can do is to signal to the user that you want your status to be changed and the user will decide:
Intent intent = new Intent(Telephony.Sms.Intents.ACTION_CHANGE_DEFAULT);
intent.putExtra(Telephony.Sms.Intents.EXTRA_PACKAGE_NAME, activity.getPackageName());
activity.startActivity(intent);
However, to be eligible for becoming a default SMS app, you have to implement all of the functionality required from such an app, and this includes the handling of all SMS/MMS related functionality (sending and receiving, notifications, etc). This practically means that you have to rewrite the complete related functionality of the phone, including all receivers, intents, filters and code (and you should be aware that SMS and especially MMS handling is not part of the system, it requires quite a lot of your own code). And this is also the reason why you won't be able to receive an answer that fits into the confines of a SO answer. Way too much code: basically, a complete app.
There is no way out: if you want the user to replace the default SMS app, the user will rightfully expect that whatever app they choose will continue to support all of the functionality. Unless you provide all that, your app will not be listed among the eligible ones and the intent above will not work.
The Android Developers blog of Google has an article titled Getting Your SMS Apps Ready for KitKat that gives you the very first steps in learning what's expected from you in this scenario.