I am trying to create an app using Powerapps where I need to interact with beacons ( their brand is Minew).
I want to start with something basic, like get a notification when the beacon is detected. Is it possible? If so, how?
As #davidgyoung mentioned, the simple answer is no. The most complex answer is it depends on whether the beacon can be exposed to the world (Internet) as a custom connector - there's currently no way to use bluetooth, for example, for communication between PowerApps and the external world.
If the beacon is Internet-connected, then it may be possible to use whatever the beacon is detecting (time, temperature, etc.) as a trigger in the custom connector. Once that is done, then you could create a flow that is started based on that trigger, and the flow can send a push notification to PowerApps (or the flow can store the notification in some data source, and PowerApps can poll for new notifications). You'll also need to manage subscriptions (which apps / users can listen to which notifications from the beacons).
So, this may technically be possible (depending on the capability of the Minew, which I don't know), but it will involve some work to get it done.
It's always hard to authoritatively say something is not possible (somebody can always build a way later and then prove you wrong!) but in years of professional beacon work, I have never heard of anybody using the Powerapps platform to build beacon apps. While I highly suspect that "no" is the simple answer to this question, I would welcome anyone knowing otherwise to provide another answer.
First off I should be up front that my level of knowledge is currently zero so I am doing as much research as I can for myself and have the books to hand.
I've read through the following article as I believe it relates to my question https://freeswitch.org/confluence/display/FREESWITCH/XML+Dialplan
My research leads me to believe I am required to create a dial lpan to initiate two phone calls, one to the users extension number and one to the external phone and then bridge these two calls together. The freeswitch server will have multiple domains and share the same extensions across the domains. I will have at the time of the 'click to call' all the information about the user, his domain and the phone on his desk.
Can anyone point me in the right direction for this functionality. I hope I have the right idea but potentially click to call doesn't even work the way I think it does.
I appreciate this may actually be impossible to answer with the info I have provided but I don't yet know that or I genuinely have my approach completely back to front.
Here's hoping someone has a dial plan I can cut and paste and replace some variables and voila. But that is probably wishful thinking.
I am working on a family networking app for Android that enables family members to share their location and track location of others simultaneously. You can suppose that this app is similar with Life360 or Sygic Family Locator. At first, I determined to use a MBaaS and then I completed its coding by using Parse. However, I realized that although a user read and write geolocation data per minute (of course, in some cases geolocation data is sent less frequently), the request traffic exceeds my forward-looking expectations. For this reason, I want to develop a well-grounded system but I have some doubts about whether Parse can still do its duty if number of users increases to 100-500k.
Considering all these, I am looking for an alternative method/service to set such a system. I think using a backend service like Parse is a moderate solution but not the best one. What are the possible ways to achieve this from bad to good? To exemplify, one of my friends say that I can use Sinch which is an instant messaging service in background between users that set the price considering number of active users. Nevertheless, it sounds weird to me, I have never seen such a usage of an instant messaging service as he said.
Your comments and suggestions will be highly appreciated. Thank you in advance.
Well sinch wouldn't handle location updates or storing of location data, that would be parse you are asking about.
And since you implied that the requests would be to much for your username maybe I wrongly assumed price was the problem with parse.
But to answer your question about sending location data I would probably throttle it if I where you to aile or so. No need for family members to know down to the feet in realtime. if there is a need for that I would probably inement a request method instead and ask the user for location when someone is interested.
Update: this question is specifically about protecting (encipher / obfuscate) the content client side vs. doing it before transmission from the server. What are the pros / cons on going in an approach like itune's one - in which the files aren't ciphered / obfuscated before transmission.
As I added in my note in the original question, there are contracts in place that we need to comply to (as its the case for most services that implement drm). We push for drm free, and most content providers deals are on it, but that doesn't free us of obligations already in place.
I recently read some information regarding how itunes / fairplay approaches drm, and didn't expect to see the server actually serves the files without any protection.
The quote in this answer seems to capture the spirit of the issue.
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to use.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
An extra bit of info: client environment is adobe air, multiple content types involved (music, video, flash apps, images).
So, is it reasonable to do like itune's fairplay and protect the media client side.
Note: I think unbreakable DRM is an unsolvable problem and as most looking for an answer to this, the need for it relates to it already being in a contract with content providers ... in the likes of reasonable best effort.
I think you might be missing something here. Users hate, hate, hate, HATE DRM. That's why no media company ever gets any traction when they try to use it.
The kicker here is that the contract says "reasonable best effort", and I haven't the faintest idea of what that will mean in a court of law.
What you want to do is make your client happy with the DRM you put on. I don't know what your client thinks DRM is, can do, costs in resources, or if your client is actually aware that DRM can be really annoying. You would have to answer that. You can try to educate the client, but that could be seen as trying to explain away substandard work.
If the client is not happy, the next fallback position is to get paid without litigation, and for that to happen, the contract has to be reasonably clear. Unfortunately, "reasonable best effort" isn't clear, so you might wind up in court. You may be able to renegotiate parts of the contract in the client's favor, or you may not.
If all else fails, you hope to win the court case.
I am not a lawyer, and this is not legal advice. I do see this as more of a question of expectations and possible legal interpretation than a technical question. I don't think we can help you here. You should consult with a lawyer who specializes in this sort of thing, and I don't even know what speciality to recommend. If you're in the US, call your local Bar Association and ask for a referral.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
Files being tied to the user requires some method of verifying that there is a user. What happens when your verification server goes down (or is discontinued, as Wal-Mart did)?
There is no level of DRM that doesn't affect at least some "honest users".
Data can be copied
As long as client hardware, standalone, can not distinguish between a "good" and a "bad" copy, you will end up limiting all general copies, and copy mechanisms. Most DRM companies deal with this fact by a telling me how much this technology sets me free. Almost as if people would start to believe when they hear the same thing often enough...
Code can't be protected on the client. Protecting code on the server is a largely solved problem. Protecting code on the client isn't. All current approaches come with stingy restrictions.
Impact works in subtle ways. At the very least, you have the additional cost of implementing client-side-DRM (and all follow-up cost, including the horde of "DMCA"-shouting lawyer gorillas) It is hard to prove that you will offset this cost with the increased revenue.
It's not just about code and crypto. Once you implement client-side DRM, you unleash a chain of events in Marketing, Public Relations and Legal. A long as they don't stop to alienate users, you don't need to bother.
To answer the question "is it reasonable", you have to be clear when you use the word "protect" what you're trying to protect against...
For example, are you trying to:
authorized users from using their downloaded content via your app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
authorized users from using their downloaded content via any app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
unauthorized users from using content received from authorized users via your app?
unauthorized users from using content received from authorized users via any app?
known users from accessing unpurchased/unauthorized content from the media library on your server via your app?
known users from accessing unpurchased/unauthorized content from the media library on your server via any app?
unknown users from accessing the media library on your server via your app?
unknown users from accessing the media library on your server via any app?
etc...
"Any app" in the above can include things like:
other player programs designed to interoperate/cooperate with your site (e.g. for flickr)
programs designed to convert content to other formats, possibly non-DRM formats
hostile programs designed to
From the article you linked, you can start to see some of the possible limitations of applying the DRM client-side...
The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.
The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.
Neither of these approaches required breaking the DRM being applied, or even hacking any of the products involved; they could be done simply by passively observing the protocols involved, and then imitating them.
So the question becomes: are you trying to protect against these kinds of attack?
If yes, then client-applied DRM is not reasonable.
If no (for example, you're only concerned about people using your app, like Apple/iTunes does), then it might be.
(repeat this process for every situation you can think of. If the adig nswer is always either "client-applied DRM will protect me" or "I'm not trying to protect against this situation", then using client-applied DRM is resonable.)
Note that for the last four of my examples, while DRM would protect against those situations as a side-effect, it's not the best place to enforce those restrictions. Those kinds of restrictions are best applied on the server in the login/authorization process.
If the server serves the content without protection, it's because the encryption is per-client.
That being said, wireshark will foil your best-laid plans.
Encryption alone is usually just as good as sending a boolean telling you if you're allowed to use the content, since the bypass is usually just changing the input/output to one encryption API call...
You want to use heavy binary obfuscation on the client side if you want the protection to literally hold for more than 5 minutes. Using decryption on the client side, make sure the data cannot be replayed and that the only way to bypass the system is to reverse engineer the entire binary protection scheme. Properly done, this will stop all the kids.
On another note, if this is a product to be run on an operating system, don't use processor specific or operating system specific anomalies such as the Windows PEB/TEB/syscalls and processor bugs, those will only make the program even less portable than DRM already is.
Oh and to answer the question title: No. It's a waste of time and money, and will make your product not work on my hardened Linux system.
I have a client who wants a solution to allow delivery people to text (SMS messaging) in that they have completed a pick up at a particular location. What I'm looking for is Code to read an imbound SMS message or a SMS component if appropiate. This would allow me to create a windows service to read the message and update a SQL record accordingly.
Probably not quite what you're looking for but one approach is to use a gateway like iTagg which provides a number of interfaces for developers to send and receive SMS/MMS etc. Depending on your location, iTagg may be no use but I'm sure there'll be an equivalent for your region.
Sometime ago I implemented something similar using a GSM modem. I think most of the GSM modems offer AT commands that can be used for receiving and sending SMS messages. At the time, I used a library in Java that provided a easy to use API. The commands to read and send SMS are really easy but I bet there is something in .Net for that purpose that can make the task even easier.
I made a little search and I found this article with an example of using AT commands to interact with a GSM phone. I looked into the supplied source and it includes a library with operations related to SMS.
In my previous project I used a Siemens GSM modem with a RS232 interface. It wasn't very expensive and was able to manage all the messages sent by onboard units placed in vehicles. But if you have a unused phone it can work as well.
Thanks Luke, I am thinking more of a GSM modem which would be connected to the server. I think this would give more control rather than go through a third party, but I take your point and will investigate further.