I have a simple app in Android, that uses some features like Services and Broadcast Receivers. It is a simple project, that uses SignalR to make a chat. A basic chat, where the service has the signalR connection and staying listening for any new messages or contact's status's updates.
Then, I have some broadcast receivers:
to start the service,
when receive a new message to add in the chatList
when receive a new contact online to update the contactList.
So it connects to a server that uses SignalR implementation, and do all the server job that is expected from a chatWebServer.
So, I'd like to re-write this app, using MvvmCross, so i could have a WindowsPhone, iOS and Android versions. I know the broadcast receiver could be changed for the Messages Services in MvvmCross, but the Android Services/ iOS Long Tasks/ WindowsBackgroundsTasks would be implemented as what in MvvmCross? Would be possible to have it implementation in Core project, so I can reuse it in all platforms? Can anyone help how would be it archtiecture?
Thanks in regard,
Gabriel Bastos
You will still need to rely on what the platform has available for you. So on Android you would still need to have a BroadcastReceiver or at least a Service which has the SignalR connection, otherwise it will not survive if the application is closed.
iOS and Windows is a bit of a different story, there you are not allowed to have stuff running in the background. So here you would probably need to use push notifications to notify of new messages. Although on Windows Phone you can have Scheduled Tasks or also called Background Agents here I think you can do something every 60 seconds at most.
On iOS you are out of luck you simply can't do stuff in the background unless you are using the built in Location Services or something like that.
MvvmCross does not do anything magically, nor does it allow to create a service which does something the platform does not provide.
Related
We are developing an app with angular/ionic in which we use capacitor jitsi plugin for video calls. What we are now trying to do is to receive notifications (via firebase) like in whatsapp with the incoming call screen and two buttons to accept and decline. Any idea on how to do that?
Thanks
If you got the choice to change the notification service, instead or directly using firebase, you could use Onesignal which extends firebase and they already have a service named VOIP notifications which should kinda do your needs and here is the link:
https://documentation.onesignal.com/docs/voip-notifications
In case your are restricted with firebase or need to know how this could be done, bellow will be the way to achieve it..
As for android:
First as logic part, you need to add some code in the native layer since hybrid apps usually can't interact from JavaScript side to native side in case app was not launched, so in order to wake the application on a specific event like notification received or any other actions that phone system can hold..
Second, as technical part, you need to add broadcast receivers and the receivers role stand to interact as native code with system. example in the link below:
https://www.digitalocean.com/community/tutorials/android-broadcastreceiver-example-tutorial
also another video about foreground and background broadcast receiver service in the link below:
https://www.youtube.com/watch?v=rlzfcqDlovg
video code output in git:
https://github.com/borntocoderepos/callrecorder
in the Youtube video example, the user is launching a toast message on phone call if app was opened or closed (background or foreground) so you can launch your app with intent with passing data and capture the data on app start as Deep Links as capacitor (https://capacitorjs.com/docs/guides/deep-links) or Cordova (https://ionicframework.com/docs/native/deeplinks)..
And instead of listening to network or phone calls, you can listen to Notifications and for sure you need to do searches about your topic and or the notification service that you'll choose.
Now for the video and the tutorial not sure of the quality of code so make sure to do more researches about the way its done from different places (could be outdated code or bad code quality or even not complete service and will discuss about this point below).
In android there is policy about using background and foreground services so once you start a service you need to end it after your done so make sure after you receive the notification and launch your app to stop the listening since it would cost power usage and perhaps could be stopped by Playstore as harmful app.
Now considering IOS it should be the same concept so make searches about this topic, but for IOS, the listeners policy as I remember , the receivers should not be waked up for more than 15 mins, so also keep this in mind and make sure you stop the receivers directly after launching your Hybrid app.
Broadcast equivalent receiver for IOS:
http://www.andrewcbancroft.com/2014/10/08/fundamentals-of-nsnotificationcenter-in-swift/
Here is the use case:
the user launches the app and grants permission, the app connects to the server
at some point in the future, the server sends a request to the app
the app
regardless of whether it is running or not in the foreground or background, wakes up to run this code
Here are some options I have explored which I am unsure about:
server sent events
websockets
push notifications
Is there a reliable and safe way to do this on android, whether it's Kotlin or Flutter? Can you provide examples or documentation?
Thanks!
Turns out that the best way to do it is with push notifications!
Websockets and server sent events are better suited for other use cases. Persistent connections to a server are resource consuming, and both Android and iOS have mechanisms in place to terminate apps running in the background to save memory etc. So we would probably lose the connection and not be able to receive anything from the server if we minimized the app or locked our phone screen.
Push notifications are basically built for this exact use case because, even though they work differently on Android and iOS, they are built to receive messages from a server regardless of whether the app is in the foreground, background, or not even currently running.
I used Firebase Cloud Messaging to build my app since it's primarily an Android app. It worked like a charm.
I need to implement a message service into my app that works exactly like this:
users register with a nickname within the app
they can add contacts (just nicknames) and send them a message by just specifying their nickname
they can send a message whenever they want, and the message is stored on a server until when the receiver connects to internet.
when a message is received, a push notification is triggered.
So, the messages work pretty much like emails, however instead of using email addresses, we only use usernames. I'm also going to build my own back-end for it.
Which APIs should I use or which 3rd party framework can I use ?
And any tip ?
N.B. I need to make it work with iOS 3.0 as well.
and in the future I will develop an Android app, so the nicknames should be unique and I should be able to send messages from iPhone to Android devices within the same app.
thanks
I've successfully used the Three20 library and would recommend giving it a try. It's an open source spin-off originated by the author of the Facebook app. It features a bunch of additional GUI components that might be useful to your project, like a message composer that resembles the one used by Apple's email app.
Also, Three20 features a nice framework for handling navigation within your app. Currently, the biggest drawback seems to be that certain features don't play well with the iPad API.
The answer seems to be Push Notifications
Is there any good advice on uploading files to the device? I've seen many apps create a http server on 80 or 8080 to upload files. Does that mean I have to implement a server too?
Are there any 3rd-party libraries? (Preferably open-source and non-GPL)
EDIT: I am going to upgrade files in the app for specific devices in a corporate environment, so the ipad pulling files from a central server is also an alternative. But I would have to send messages to these ipads to tell them to fetch those files.
But I would have to send messages to
these ipads to tell them to fetch
those files.
Push Notification Programming Guide
Or mail with custom URL scheme for launching your application.
iOS Application Programming Guide - Implementing Custom URL Schemes
I assume what you want is a kind of automatic update. An app do something by order from server without user's manual operation.
I don't know enterprise-license specific feature of iOS. But I believe there's no such enterprise-specific APIs. And as I know, automatic update is almost impossible. Because,
There is no system-level support for automatic update. (yet?)
So messaging and fetching feature should be implemented in app.
But no app is guaranteed to run in background for long time.
And also user can turn off any app at any time.
There is no way to send message to an app which is not running.
Even you can send, there is no way to address each client form the server.
If your app is running, sending message or commanding them to fetch or do anything is just a simple work. The problem is there is no regular way to force them always keep alive. Even under situations like OS reboot or abnormal termination.
However there is an alternative. Just registering app as VOIP app like Skype. OS does not keep the app running too, but will monitor specific socket port, and will wake your app when the socket receives some message. For more details, see here: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW15
In AppStore, an app using VOIP for other purpose like automatic update will not be passed, but you have no need to concern about it.
And other way to send message to device without running app is push notification. This is a feature supported in system-level. But this is not designed to commanding app. This is designed to send textual message. So If your app is not running, the message will be displayed to user. However, you can guide the user to start the app by sending push notification.
As a final option, you can request some feature to Apple for enterprise environment. If your company is big enough to get an enterprise license, Apple will consider your feature request seriously.
If you decided to use VOIP method, I'm sorry I can't help you any more. I have no experience of implementing this kind of app. But it should not so hard.
However hard part is server. It definitely require custom server program which keeps TCP/IP connection. Regular HTTP server cannot be used. Because HTTP itself is designed as not to keep TCP/IP connection. You have to build this kind of server yourself from scratch. You'll have to handle lower level TCP/IP transmissions.
There are a few solutions(both of free/commercial) for this kind of server, but none of are popular because this kind of server regularly needs full customization. So there's nothing to re-use or share.
However I believe this is most suitable implementation for your app.
If you can satisfy automatic update only when the app is running, you can archive it by polling server status from the client periodically.
This is easy to implement because you can use regular HTTP servers for this. Client connect and download recent updates from central server periodically. If there is a new update, just fetch and do what you want. And the app is launched, just check the update at first. Prevent all operation until update applied.
This is regular way. Most of applications are built with this method. In this case, you have no need to implement server or hard thing.
However applying speed of update is depend on polling period.
(Edit)
I couldn't care about private APIs. Because your app is not for AppStore, so you can use private API's freely. (This is different thing with jail-breaking. There are so many hidden features by excluded from documentation) I don't know about private APIs, but it's possible there is some API which enable the support for keep-alive of the app.
However, this reverse engineering work is so painful unless you're born to hack.
You may try to use the following open-source in your project:
http://code.google.com/p/cocoahttpserver/
https://github.com/robin/cocoa-web-resource/wiki
Apple has some sample code on their website that details exactly what you're looking for:
http://developer.apple.com/library/mac/samplecode/CocoaHTTPServer/CocoaHTTPServer.zip
So you have a couple options:
You could distribute your app wirelessly within your organization and push new content out as app updates. Apple provides this option to their Enterprise Developers.
Wireless App Distribution
iPhone enables enterprises to securely host and wirelessly distribute in-house apps to employees over Wi-Fi and 3G. Apps can be updated without requiring users to connect to their computers. In-house apps can be hosted on any web server accessible to users. Users simply tap on a URL to install apps wirelessly without needing to connect to their computers.
The alternative is you configure the app to fetch the updated data. You describe adding an HTTP server to the iOS device, but there's no way the server can receive data when the app isn't running. Given your needs, it would probably work better to embed a web client in your app instead.
If I was in your shoes (and option #1 didn't work), I'd use ASIHTTPRequest to check with a server at launch/daily. If there are new updates, the app could then either prompt the user that there are new data files to download, or it could just silently download them in a background thread.
UPDATED: Perhaps I should have been more explicit about how to do #2. You can configure the download so it isn't interrupted when the user quits the app (you don't need to do a Voip hack). Check out the Completing a Finite Length Task in the Background section in the iOS Programming Guide.
There are http server sample codes from Apple and open source community such as cocoahttpserver TouchHTTPD.
You can upload file to the http server on iphone.
Here's a blog and screen-shots about running cocoahttpserver and upload file to iphone.
The Python CGIHTTPServer allows you to create a server in 0 lines of code:
jcomeau#intrepid:~/rentacoder/bin2txt$ python -m CGIHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Actually implementing a script to parse the input and save the file would take a little more effort.
[later]
OK, so forget about that, Apple doesn't allow it. See Local server on iPad for the iPad at least.
I'm doing research for making a chat based app for the iPhone (it's not really text chat in the regular sense, but the principles are the same).
Maximum 6 people can be logged into the same chat room at any one time, and the most basic question is how to efficiently check for new messages?
Would I need to simply poll the server periodically? Or is there a way I could trigger an event on the phone from the server whenever there is some new content to pay attention to?
If having to poll all the time, I worry about the resulting lag as each participant will have to wait longer for others before they can post their own responses to others. And, potentially it might also be too much to handle for the server to respond to lots of requests all the time. It would also waste bandwidth, which is not free for the user...
Unfortunately I will not be able to set up a socket server for this app, it has to be based around a regular LAMP configuration.
I think you can either go with push notifications, or XMPP (Jabber) server.
XMPP will allow your iphone app to receive data even when in the background using the new multitasking features (listening for a socket), and i'm pretty sure you should find ready to use servers for LAMP (or at least open source implementations).
Note that the iOS4 multitasking API doesn't support polling in the background, so your only other option should be push notifications. If you're new to push notifications, you can maybe use a service like Urban Airship that might make the process easier.
XMPP sounds good for you idea, i think this is the best technology for Chat. It alos works great in iOS apps.
Maybe this code sample will be helpful to start using XMPP in iOS app - look at this QuickBlox Chat code sample. It demonstrates how to integrate 1-1 Chat, Chat in room into your android application. Also there is guide how it works. I think there will be no problem to integrate it into your application. Otherwise - Comments system below allows to ask any question you want and get fast answer.
Also there is Demo video http://www.youtube.com/watch?feature=player_embedded&v=SncQaJBBW_0 how this Chat works.
In my opinion the best solution is socket, but you say that you can't implement the server side for this.
You could also implement it with push notifications. You can receive the push also when your app is running and send all the data you need inside the push. Usually chat messages are short...
If you don't want to mess with push notifications on the server then the only thing left, as long as I know, is the polling.