i am looking to build a mobile messaging app firstly in android and then ios later, and am struggling with the backend architecture and need some advice on what would be best in my circumstance. Basically i am used to just developing apps through a basic web server and using mysql with php, but now i think and want to create something that not only is very reliable and fast but is also scalable and can be used by both the android and ios platforms.
I am thinking about developing it on google cloud platform using either their google app engine or google compute engine depending on what other architectures i use. Also i was going to use google cloud messaging as my main way of handling the messages, however i am now not sure of that as it is only supported by apps that run on android and not ios, also i have heard it can be unreliable in some messages getting lost.
My main problem is that i have heard so many things about different architectures like ejabberd, xmpp, socket i.o and databases like redis that all work well with messaging apps, however i am not sure which to go that will work well together.
Sorry if this seems a bit of a confused situation, but i dont want to start developing something that i am later going to have to change. Thanks for the help
Announced last week: Engage your users across Android, iOS and Chrome via Google Cloud Messaging 3.0:
https://developers.google.com/cloud-messaging/
https://www.youtube.com/watch?v=gJatfdattno
You are asking about many different things.
Storage: can be a mysql database or something like mongo db
Transport protocol: XMPP is a chat protocol with many chat features included but it is not supported in browsers. WebSocket is more low level and more general but works inside the browser
webserver software: you basically need access to the database and be able to transmit XMPP or WebSocket. I'd recommend node.js for this. PHP is more for web pages
Related
I'm using the firebase-ui-android authentication flow for my mobile app.
I would like to do the same for my desktop app, but it doesn't seem like there is an equivalent framework; the closest seems to be firebase-ui-web.
Now I'm playing with the idea of (ab?)using firebase-ui-web to run locally on the client machine for authentication.
However, since firebase-ui-web seems to be aimed at the server I'm a bit wary running it on the client side.
The desktop app is fairly simple, it pretty much only needs to read some firestore data.
What are my options here?
The only ways to connect with Firebase are by an Android, an iOS and a web app.
There is no support for desktop apps.
But, you can create a native sync service to link your desktop app with Firebase users throught a web service.
It is feasible to have a desktop app to connect to Firebase. However you should create a hybrid desktop app using electron or other platforms that is by nature use web and javascript. Here is an example of using electron to manage firebase: https://www.electronjs.org/apps/firebase-admin
You can use Google Sign-In for TVs and Devices for that case.
This is not perfect, because you need to use additional access code, but it can work with desktop applications as well
Not sure if this is the correct Stack Exchange website but here goes..
A client has asked me to look into the possibility of having a iOS or Android App for typing in information storing that in a SQLLite database and then syncing up with the main desktop application when plugged in by cable or something other syncing technology.
The desktop application is a Windows one written currently in Delphi 7.
Are there any API's to sync data from a SQLLite database on iOS/Android that Delphi can use?
If not, then would it be better if the desktop application was written in C# as its a newer language that can consume the API's easier?
For unidirectional sync (device to desktop), I would start with a simple web service (HTTP based). The new Web Sockets standard, also based on HTTP, is a little more complicated, but would allow for bidirectional communication.
The devices can HTTP POST database changes to the server, and the desktop client can pull new data (using HTTP GET) or receive push notifications, for example using a Web Sockets client.
For desktop to device you could also check out Apple Push Notifications and the corresponding Android technology.
For high availability I recommend a cloud-based solution like Amazon Elastic Compute Cloud (EC2), Google App Engine (GAE) or Azure.
This question is rather broad, there are many things you could do here. There aare so many technologies to use it's blinding.
The prevailing technique for transferring information from mobile devices is REST (over http).
You could also whip something up rather swiftly in node.js or WFC to create a service to collect information from the mobile devices.
I'm not sure about Delphi libraries available but perhaps by including REST in your search term you may have more luck. You may want to take a look at https://stackoverflow.com/questions/3959851/using-rest-with-delphi for a start.
The mobile side may be more tricky. If you are developing for multiple devices you may wish to explore the cross platform developer framework by PhoneGap as there seems to be a few projects that aim to sync local databases to the cloud. How you tie these together will be an interesting task.
Good luck!!!
How does one approach building the mobile app version of one's Rails app, with little to no mobile development experience? iOS, Android, one or the other, or both.
First, you might want to create (private) APIs for services your web app provides. The de facto standard for Android apps is REST-like endpoints that accept/return JSON. You can use whatever Ruby REST framework works best. Then you need to consider how you would authenticate Android apps, if needed. Do you use the same authentication database? Can you allow anonymous access, what parts of the app do you expose, etc.
Finally, you need to build the frontend. A few options here:
learn Android
hire someone to do it
use a framework that lets you develop using Web(-like) technologies: Thitanium, Rhodes, etc. The upside is that you get to use what you know and might also get an iOS app for free.
The downside is that you can never get the native performance, and look-and-feel might not be completely Android-like (never used Rhodes, so maybe it does this well enough, but still)
Consider using http://www.rhomobile.com/.
I'm new to Android programming. I have a website with sql 2008 db, and now i would like to give the users the ability to use their smart phones to enter data to this db.
I was wondering what is the best way to establish it. Since I'm new to it I don't want to build something that's not so professional.
Thanks for your help.
If I were you I would consider two following options:
Have a web application optimised for mobile use;
Pros:
Updates are delivered immediately, as there's no client application, everything is done on the server;
Web application can be used on many devices with a browser and not just Android: iPhone, Blackberry, PC, Mac, etc.;
Cons:
Users need to be online to work with the application;
You can not leverage from the native UI components available to native device applications;
Write Android application that will work with the database via a number of REST endpoints exposed through a web application (again);
The pros and cons are a full reverse of what you had in the first option.
The right answer for me was to use KSoap library. I'ts very easy and works very well.
Here is a tutorial that will show you how to do it step by step.
http://java.dzone.com/articles/invoke-webservices-android
I currently have a working implementation using GAE and servlets to communicate with my android application. The app will create json objects and send/receive them using the httpclient. I then was looking at the 2.4 beta plugin for using C2DM and noticed that they use GWT along with a RequestFactory for communication. I was wondering if this approach is worth the time switching? Is it easy to setup and configure? Seems like this would be a nice approach if i want to say develop a mobile site along with the app?
If you use C2DM you will need your users to use a google account. I personally don't feel 100% confortable with that.
The best thing about C2DM is that you avoid polling your GAE server. If you have an already working solution, why would you change it?
I would recommend android - appengine combination. However if you want your app to be on non google-play device, you need to think around C2DM/LVL or google wallet API(a mandatory on google play). RequestFactory is great but it is tightly coupled, imho. I would recommend Rest which is platform agnostic, very loosely coupled, thus support GWT, android, iOS, BlackBerry, WebOS, desktop ...