I need a good design to read the location from a user1 iOS and send it to user2 iOS.
How I should send this to the backend, using rest APIs?
The location data pushed to server should be at 20sec interval or more?
Once the location info is with backend how it should push that to user2, badges or a poll from the app?
Please suggest.
Of course, first step is to send the information to the backend, in that case you only need a rest api exposed with a method that can receive the POST.
Second step is send the information to the second device. Here you can implement in two ways:
Push notification, you can use tools from the iOS libraries to send the information to the second device and the application will use this information.
Read more about this here: https://medium.com/ios-os-x-development/learn-master-%EF%B8%8F-ios-remote-push-notifications-in-2018-in-under-10-minutes-825ca6bee092
Second option, it is to implement a websocket, your second device will be connected with a web protocol to receive information from the server. This is a solution for real time systems, every thing you need to send will be received by the target in milliseconds.
Related
I need to be able to consume a purchase without an Android client being connected using a backend server. Is this possible? If not, why? I am trying to make it possible to process a purchase entirely without a user being connected in the case of a disconnection.
Do I need to send a message to my client from my server requesting consumption and then provide a response to the server when the purchase is consumed? This is what I am trying to avoid.
I see various other similar questions but they are for the AIDL API which is now discontinued for google-in-app billing.
Relative API(s);
https://mvnrepository.com/artifact/com.google.apis/google-api-services-androidpublisher/v3-rev103-1.25.0
SOLUTION: To my knowledge, at this current time, July 2019, it is not possible to consume a purchase from a server. It is only possible from the android client.
This means that the flow of the purchase depends on a request to a client and an response from the client, followed by a required GET to validate the purchase has actually been consumed.
I'm new in Android BLE so my question may be uncorrect or naive in some way. If this is the case please explain me where I'm wrong and kindly show me the correct way to manage this scenario.
Scenario is the following: my Android app communicates with a BLE device sending commands and getting answers from device using BLE characteristics.
Sequence is:
Device wakes up the app (the onConnectionStateChange method is called)
My app writes a command in a characteristic (I call writeCharacteristic putting the command in value parameter).
Device sends back the answer to command to my app (the onCharacteristicChanged method is triggered and value parameter contains the answer)
After waking up the app, the device doesn't do anything until a command is sent via writeCharacteristic. The device accepts different commands.
All good so far, but recently I developed a second different app to communicate with same device.
When I run both apps on same Android phone, one app sends a command to the device and the response is received by both apps! Of course the app that didn't sent the command receives an unexpected answer and goes to an unexpected status.
Ok, knowing the problem I can modify both my apps to handle this situation, but the question is: Is this behavior normal when two apps in same device communicate with same BLE device?
Is there a way for an app to establish a communication channel with a BLE device to avoid sending answer to specific commands to any other app except the one that sent the request?
My guess is that writeCharacteristic and onNotificationChanged aren't the right functions for such kind of communication, but in this case which are the alternatives?
The Bluetooth standard itself doesn't define anything how multiple apps would behave if both have a GATT connection to the same device. In the standard there is just one "GATT client".
Now both iOS and Android have taken one step further in a way that might seem unintuitive. Instead of only allowing one app at a time to communicate, multiple apps can be connected over the same GATT client to a device. The OS "multiplexes" the communication from/to the apps. The behaviour is that responses to read and write requests can only be seen by the app that made the request. So if you do readCharacteristic only that app will get the onCharacteristicRead callback. Notifications however will be delivered to both apps to the onCharacteristicChanged callback, since it wouldn't make any sense to send the notification to only one.
When you say that the "response" to a write request is the notification, that's not correct in terms of GATT terminology. The response to a write request is always empty per specification (or an error). If your peripheral emits a notification, then in your case that might be the "answer" according to your own logic, but it's not a response or any way related to your write request per the GATT specification. That's why Android can't (and shouldn't) send the notification to only one device.
I suggest that you simply ignore notifications you are not expecting. If you want to associate an "answer" to a write request, you can change your protocol to include a transaction id in both packets so they can be matched.
When I write "app" above, I really mean BluetoothGatt objects. You can call connectGatt twice with the same remote device in the same app, which will behave the same as if you connected from two different apps.
We developed a Hotel Menu Order project in android. Now We have created the project successfully. We are using java, Jax-rs for web service, Mysql for database and Rest for communication.
Now we want to add some more features in our app. When the customer conforms their order that order should show to kitchen and admin. When we google for some example we found one way. That is Google Cloud Messaging. But this is online sevice. We can not use this service.
Because we are using in offline services. We use one centralized server in the hotel and all the devices will connect with WiFi. There is no internet connection.
In this case how to notify the user a row is updated in Database. Please let us know how to achieve this.
Via SMS, what you can do is that you can send the sms to the devices using thrid party services like twilio, on client side i.e. device end you can get the sms broadcast validate the number and the sms content, read the content and update the application DB and the UI accordingly.
Or if one device has internet then what you can do is send GCM notification to that device, and from that device you can update the other devices through wifi direct. But wifi direct has some limitation, I think using SMS is a better option.
u can use Google Cloud Messenger services, by which google provide free message service to your client. http://hmkcode.com/android-google-cloud-messaging-tutorial/ this example will help u to understand better.
I am using the Google-GCM service for pushing notifications to a mobile device & building this application in Java EE.
I'm perfectly able to push notifications to the mobile device. And from the client-end (mobile) I'm able to receive input(string).
Henceforth my conceptual question starts: When I'm receiving input from a mobile (let's say: "Hello, Server"), I'm trying to build an automated process on the server-side and in reply it will push a notification (let's say: "Hi client, I'm fine; How are you?") automatically.
I want to grab some idea to push the notification automatically whenever the mobile device is registered. How do I do it?
All realistic implementations of GCM include a stage where an app receives a RegID, and communicates the RegID back to the server, typically via an HTTP service, typically along with some other business specific data. The server would store the RegID, associating it with other data, and later use it to send messages.
Have you implemented automated the delivery of the GCM registration ID to the server yet? If so, in the same piece of code, you might as well push a notification back. If not, do put together some. Server-side implementation would depend on your server's platform, naturally.
I am trying to make an app that connect to the server.
The app is used by some devices.
If one of the devices upload something to the server, I would like other devices receive the notification about the server has something new.
My question is, how to check the server is change or not? How often we must check the server?
I wonder how the Online Messaging work, because someone send something, we receive the message ASAP
Is the concept can be use with my app?
Sounds like you want to take advantage of Google Could Messaging or GCM for short.
http://developer.android.com/guide/google/gcm/index.html
This could be a lightweight message telling the Android application that there is new data to be fetched from the server (for instance, a movie uploaded by a friend), or it could be a message containing up to 4kb of payload data (so apps like instant messaging can consume the message directly).
GCM is the standard for how your apps "talk" to your servers. Either for a message in it's entirety or just a message to go check the server because it's been updated.